フィルターの原理とライフサイクル
ゲートウェイのルーティング機能とアサーション機能については以前に学習しましたが、このセクションではフィルターの原理について学習し、次に一般的に使用されるフィルターをいくつか選んで学習します。
1. フィルターの動作モード
すべてのオープン ソース フレームワークは同じフィルター モードを実装しています。責任の連鎖と同様の方法で、従来の責任の連鎖モードのイベントは、処理オブジェクトが引き継ぐまで渡されます。フィルターは従来の連鎖とは少し異なります。サッカーチームの始球式の握手に似ていますが、選手全員が整列し、最初から最後まで順番に全員と握手をしなければなりません。
ゲートウェイ内のフィルタも同じモデルであり、優先順位が付けられ、すべてのゲートウェイ通話要求は最も優先順位の高いフィルタから開始されます。最後のフィルターで処理されるまで最後まで続きます。
2. フィルターの実装
Gateway でのフィルターの実装は非常に簡単で、GatewayFilter インターフェイスのデフォルト メソッドを実装するだけです。
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
// 随意发挥
return chain.filter(exchange);
}
ここには 2 つの重要な情報があります。
ServerWebExchange:これは Spring によってカプセル化された HTTP リクエストとレスポンスの対話プロトコルであり、そこからリクエストとレスポンスのさまざまなリクエスト パラメータを取得したり、それにコンテンツを追加したりできます。
GatewayFilterChain:フィルターの呼び出しチェーンです。メソッドの最後に、交換オブジェクトを呼び出しチェーン内の次のオブジェクトに渡す必要があります。
3. フィルターの実行フェーズ
Spring Cloud の前世代のゲートウェイ コンポーネントである Zuul におけるフィルターの Pre および Post の定義とは異なり、Gateway は Filter のコードを通じて Pre および Post と同様の効果を実現します。
Pre と Post は現在のフィルタの実行フェーズを指します。Pre は次のフィルタの前に実行され、Post はフィルタの実行後に実行されます。また、ゲートウェイ フィルタで Pre と Post の実行ロジックを定義することもできます。
3.1、プレタイプ
AddResponseHeaderGatewayFilterFactoryたとえば、ヘッダー情報をレスポンスに追加できるとします。
@Override
public GatewayFilter apply(NameValueConfig config) {
return (exchange, chain) -> {
exchange.getResponse().getHeaders().add(config.getName(), config.getValue());
return chain.filter(exchange);
};
}
ここでの具体的な実行メソッドは、chain.filter()メソッドを呼び出す前、つまり下位レベルの呼び出しリンクに転送する前に実行されるように定義されているため、Pre-typeフィルタとして理解できます。
3.2、投稿タイプ
例を見てみましょうSetStatusGatewayFilterFactory。フィルタが実行されると、指定された HTTP ステータスが呼び出し元に返されます。
return chain.filter(exchange).then(Mono.fromRunnable(() -> {
// 这里是业务逻辑
}));
このフィルターの主なロジックは then メソッド内にあり、下位レベルの呼び出しリンクが完了した後に実行されるコールバック関数であるため、このタイプのフィルターはポスト フィルターとみなすことができます。
4. フィルターのシート
org.spingfamewok core.OrderedGateway では、インターフェイスを実装することでフィルターの実行順序を指定できます。次の生成では、Ordered インターフェイス メソッドを実装し、フィルターの実行順序を 0 に設定します。
@Override
public int getOrder() {
return 0;
}
Pre型フィルタの場合は数字が大きいほど優先度が高く、早く実行されますが、Post型フィルタの場合は数字が小さいほど早く実行されます。
5. フィルターの例
5.1、ヘッダーフィルター
このシリーズには多くのフィルターのセットがあり、AddRequestHeader と AddResponseHeader は、指定されたヘッダーをそれぞれリクエストとレスポンスに追加し、対応する RemoveRequestHeader と RemoveResponseHeader がそれぞれ削除操作を実行します。使用方法も非常に簡単です。
.filters(f -> f.addResponseHeader("who", "gateway-header"))
上記の例では、who 属性をヘッダーに追加し、対応する値はgateway-header です。
5.2、StripPrefixフィルター
これはより一般的に使用されるフィルターであり、その機能は URL パスの一部を削除することです。たとえば、フィルタ構成は次のとおりです。
.route(r -> r.path("/gateway-test/**")
.filters(f -> f.stripPrefix(1))
.uri("lb://FEIGN-SERVICE-PROVIDER/")
)
HTTP リクエストがアクセスされた場合、フィルター/gateway-test/sample/updateがない場合、サービスに転送されるアクセス パスは同じです。StripPrefixFEIGN-SERVICE-PROVIDER
このフィルターを追加すると、ゲートウェイはstripPrefix(1)URL 内のパスを の値に従って取得します。たとえば、ここでは 1 を設定し、プレフィックスを削除して、最後にパスをバックグラウンド サービスに送信します"sample/update"。
5.3、PrefixPathフィルター
これはStripPrefix関数のまったく逆で、リクエスト パスの前にプレフィックスを追加します。
.route(r -> r.path("/gateway-test/**")
.filters(f -> f.prefixPath("go"))
.uri("lb://FEIGN-SERVICE-PROVIDER/")
)
たとえば、 にアクセスすると“/gateway-test/sample”、上記の例で構成されたフィルタはリクエストを に送信します"go/gateway-test/sample”。
5.4、RedirectToフィルター
特定のステータス コードを受信したリクエストを指定された URL にリダイレクトできます。
.filters(f -> f.redirect(302, "https://www.study.com/"))
上記の例では、HTTP ステータス コードと URL の 2 つのパラメータを受け取ります。リクエストの結果が 404 の場合、2 番目のパラメータで指定されたページにリダイレクトされます。この関数は、ログイン ページへのリダイレクトやリクエストなど、統一された例外処理を実行することもできUnauthorizedますForbidden。
5.5、SaveSession フィルター
マイクロサービスはステートレス セッションであるため、そのほとんどはセッション メカニズムに依存しないことがわかっていますが、分散セッション要件がある場合、たとえば一部の機能が spring-session と spring-security に基づいて実装されている場合、このフィルターはおそらくサービスを呼び出す前にセッションを強制的に保存します。
.filters(f -> f.saveSession())