1. springcloudゲートウェイとは何ですか？
Spring Cloud Gatewayは、マイクロサービスアーキテクチャにシンプルで効果的な統合APIルーティング管理方法を提供することを目的としています。
Spring Cloudエコシステムのゲートウェイとして、Spring Cloud Gatewayは統合されたルーティング方法を提供するだけでなく、フィルターチェーンに基づいて、セキュリティ、監視/購入ポイント、現在の制限などの基本的なゲートウェイ機能も提供します。
Spring Cloud Gatewayは、Spring BootとSpring WebFluxに依存し、Nettyで実行されます。従来のサーブレットコンテナでは機能せず、warパッケージに組み込むこともできません。
Spring Cloud Gatewayには、理解する必要があるいくつかのコアコンセプトがあります。
1）ルート
ルートはゲートウェイの基本要素であり、ID、ターゲットURI、アサーション、およびフィルターで構成されています。リクエストがゲートウェイに到達すると、ゲートウェイハンドラマッピングはアサーションを通じてルートマッチングを実行し、アサーションがtrueの場合、ルートがマッチングされます。
2）述語
述語は、Java 8で提供される関数です。入力タイプはSpring Framework ServerWebExchangeです。開発者は、リクエストヘッダーやリクエストパラメータなど、HTTPからのリクエストを照合できます。簡単に言えば、マッチング条件です。
3）フィルター
フィルターはゲートウェイのフィルターであり、要求が発行される前後にいくつかのビジネス処理を実行できます。
Spring Cloud Gatewayの仕組み
Gatewayのクライアントは、Spring Cloud Gatewayにリクエストを送信します。リクエストは、最初にHttpWebHandlerAdapterによって抽出され、ゲートウェイのコンテキストにアセンブルされてから、ゲートウェイのコンテキストがDispatcherHandlerに渡されます。DispatcherHandlerはすべてのリクエストのディスパッチプロセッサです。DispatcherHandlerは主に、リクエストを対応するRoutePredicateHandlerMapping（ルートアサーションプロセッサマッパー）にディスパッチするなど、リクエストに対応するプロセッサのディスパッチを担当します。ルートアサーション処理マッパーは、主にルートを見つけ、ルートを見つけた後に対応するFilteringWebHandlerを返すために使用されます。FilteringWebHandlerは、主にFilterリンクリストを組み立て、一連のFilter処理を実行するためにFilterを呼び出し、リクエストをバックエンドの対応するプロキシサービス処理に転送します。処理後、レスポンスはゲートウェイクライアントに返されます。
フィルターチェーンで、フィルターを点線で分割するのは、要求を転送する前、またはプロキシサービスの戻り結果を受信した後にフィルターを処理できるためです。すべてのプレタイプフィルターが実行された後、リクエストはプロキシサービスに転送されて処理されます。プロキシサービスがすべてのリクエストを完了すると、Postタイプのフィルタが実行されます。
ブログ「Redefined Spring Cloud Combat」からの抜粋。
SpringCloud Gatewayの機能
SpringCloudの関係者は、SpringCloud Gatewayの特徴を次のように紹介しました。
（1）Spring Framework 5、Project Reactor、Spring Boot 2.0に基づく
（2）統合されたHystrix回路ブレーカー
（3）集成Spring Cloud DiscoveryClient
（4）述語とフィルターは特定のルートで動作するため、簡単に記述できます。
（5）ゲートウェイのいくつかの高度な機能：動的ルーティング、電流制限、パス書き換え
上記の特徴から、ズールの特徴と大差ありません。SpringCloudゲートウェイとZuulの主な違いは、基盤となる通信フレームワークにまだあります。
上記の3つの用語について簡単に説明します。
（ 1 ）フィルター（フィルター） ：
Zuulのフィルターの概念と同様に、Zuulのフィルターを使用して、要求をインターセプトおよび変更し、上流の応答で2次処理を実行できます。フィルターはorg.springframework.cloud.gateway.filter.GatewayFilterクラスのインスタンスです。
（2）ルート：
ゲートウェイ構成の基本コンポーネントは、Zuulのルーティング構成モジュールに似ています。A ルートモジュール、URIターゲット、アサーションの集合とフィルタのセットは、IDにより定義されます。アサーションがtrueの場合、ルートは一致し、ターゲットURIにアクセスします。
（ 3 ）述語（アサーション） ：
これは、ヘッダーやパラメーターなど、HTTP要求からのあらゆるものに一致させるために使用できるJava 8述語です。アサーションの入力タイプはServerWebExchangeです。
SpringCloudゲートウェイとアーキテクチャ
2017年後半に、SpringはWebfluxを先導しました。Webfluxの出現により、Springの反応型プログラミングのギャップが埋められました。Webfluxの反応型プログラミングは、プログラミングスタイルの変化だけでなく、一連の有名なフレームワークへの対応も提供します。 Netty、Redisなどの開発キット
SpringCloud Gatewayで使用されるWebfluxのReactor-nettyレスポンシブプログラミングコンポーネントは、下部にあるNetty通信フレームワークを使用します。
- SpringCloud ZuulのIOモデル
Springcloudに統合されたZuulバージョンは、Tomcatコンテナーを使用し、従来のサーブレットIO処理モデルを使用します。
ご存知のように、サーブレットはライフサイクルのサーブレットコンテナによって管理されます。コンテナが起動したら、サーブレットオブジェクトを作成し、サーブレットのinit（）を呼び出して初期化します。コンテナが閉じたら、サーブレットのdestory（）を呼び出してサーブレットを破棄します。コンテナの実行中にリクエストを受け入れ、各リクエストにスレッドを割り当てます（通常、スレッドプールからアイドルスレッドを取得します）。次にservice（）を呼び出します。
短所：サーブレットは単純なネットワークIOモデルであり、リクエストがサーブレットコンテナーに入ると、サーブレットコンテナーはそのスレッドをバインドします。このモデルは、同時実行性の低いシナリオに適用できますが、同時実行性が上昇すると、スレッドの数が増えます。それは上昇し、スレッドリソースのコストは高くなります（オンラインテキストの切り替え、大量のメモリ消費）が、要求の処理時間に深刻な影響を与えます。いくつかの単純なビジネスシナリオでは、各要求にスレッドを割り当てたくない場合があります。非常に並行した要求を処理するために必要なスレッドは1つまたは数個だけです。このビジネスシナリオでは、サーブレットモデルには利点がありません。
したがって、Springcloud Zuulはサーブレットに基づくブロッキング処理モデルです。つまり、Springはすべてのリクエストリクエストを処理するサーブレット（DispatcherServlet）を実装し、サーブレットは処理をブロックします。したがって、Springcloud Zuulは、サーブレットモデルの欠点を取り除くことはできません。Zuul 2.0が開始されましたが、Nettyが使用されており、大規模なZuul 2.0クラスターデプロイメントの成熟したケースがありますが、Springcloudの担当者は、バージョンを統合して変更する計画はありません。
1.3.2 Webfluxモデル
Webfluxモードは、古いサーブレットスレッドモデルを置き換えます。少数のスレッドが要求と応答のio操作の処理に使用されます。これらのスレッドはループスレッドと呼ばれ、ビジネスはレスポンシブプログラミングフレームワークに渡されます。レスポンシブプログラミングは非常に柔軟です。ユーザーはビジネスでブロックされた操作をレスポンシブフレームワークに送信できますブロックせずに作業スレッドで実行された操作は引き続きループスレッドで処理できるため、ループスレッドの使用率が大幅に向上します。公式構造図：
Webfluxは複数の低レベルの通信フレームワークと互換性がありますが、通常の状況では、最下層は引き続きNettyを使用します。結局のところ、Nettyは業界で認められている最高のパフォーマンスの通信フレームワークです。Webflux Loopスレッドは、有名なReactorモードのIO処理モデルのReactorスレッドですが、高性能通信フレームワークNettyを使用している場合、これはNettyのEventLoopスレッドです。
ReactorスレッドモデルとNetty通信フレームワークに関する知識は、Javaプログラマーにとって重要かつ必要な内部スキルです。原則については、Nionの著書「Netty、Zookeeper、Redis High Concurrency in Action」を参照してください。繰り返しすぎないでください。
Spring Cloud Gatewayの処理フロー
クライアントがSpring Cloud Gatewayにリクエストを行います。次に、ゲートウェイハンドラーマッピングで要求に一致するルートを見つけ、それをゲートウェイWebハンドラーに送信します。ハンドラーは、指定されたフィルターチェーンを介して実際のサービスにリクエストを送信し、ビジネスロジックを実行してから戻ります。フィルター間の点線は、フィルターがプロキシー要求が送信される前（「前」）または後（「後」）にビジネス・ロジックを実行する可能性があるためです。
Spring Cloud Gatewayルーティング構成
基本URIルーティング構成メソッド
spring：
application：
name：cloud-gateway
cloud：
gateway：
discovery：
locator：
enabled：true
＃ルーティング
ルートにマイクロサービス名を使用して、登録センターから動的にルートを作成する機能を有効にします：-id：payment_routh #payment_route＃ルーティングID、固定ルールはありませんが、要件は一意です。サービス名
uri と連携することをお勧めします：http：// localhost：8001＃
述語が一致した後のサービスのルーティングアドレス：-Path
= / payment / get / **＃パスがルートに一致することをアサートします
コードベースのルーティング構成
/ * * *编式式路由 * @author L * * / @Configuration public class GateWayConfig { @Bean public RouteLocator customRouteLocator（RouteLocatorBuilder routeLocatorBuilder） { RouteLocatorBuilder.Builder routes = routeLocatorBuilder.routes（）; routes.route（" path_route_atguigu " 、 r- > r.path（" / guonei " ）. uri（" http://news.baidu.com/guonei " ））。build（）; 帰るroute.build（）; } }
登録センターと組み合わせたルーティング構成方法
uriのスキーマプロトコル部分はカスタマイズされたlb：タイプです。これは、サービスがマイクロサービス登録センター（Eurekaなど）からサブスクライブされ、サービスがルーティングされることを意味します。
典型的な例は次のとおりです。
spring：
application：
name：cloud-gateway
cloud：
gateway：
discovery：
locator：
enabled：true
＃ルーティング
ルートにマイクロサービス名を使用して、登録センターから動的にルートを作成する機能を有効にします：-id：payment_routh #payment_route＃ルーティングID、固定ルールはありませんが、要件は一意です。サービス名と連携することをお勧めします
#uri：http：// localhost：8001 #uriに一致した後のサービスのルーティングアドレス
：lb：// cloud-payment-service ＃
述語に一致した後のサービスのルーティングアドレス：
-Path = / payment / get / **＃アサーション、一致するパスによるルーティング
登録センターと組み合わせたルーティング構成方法は、単一のURIのルーティング構成と非常に小さな違いがありますが、URIのスキームプロトコルが異なるだけです。単一のURIアドレスのスキーマプロトコルは、通常、httpまたはhttpsプロトコルです。
詳細な説明：SpringCloud Gatewayマッチングルール
Spring Cloud Gatewayの機能は非常に強力であり、述部の設計からのみ確認できます。前面では、単純な条件照合にのみ述部を使用しました。実際、Spring Cloud Gatawayは、多くの述部機能を構築するのに役立ちます。
Spring Cloud Gatewayは、Spring WebFluxのHandlerMappingを、転送ルートを照合するための基本的なサポートとして使用します。SpringCloud Gatewayには、多くの組み込みPredicatesファクトリがあります。これらのPredicatesファクトリは、異なるHTTPリクエストパラメータによって照合されます。複数のPredictatesファクトリを組み合わせて使用できます。
述語の紹介
述語はJava 8に由来し、Java 8で導入された関数です。述語は入力パラメーターを受け入れ、ブール結果を返します。このインターフェースには、述語を他の複雑なロジック（AND、OR、NOTなど）にグループ化するための複数のデフォルトメソッドが含まれています。これは、インターフェース要求パラメーターの検証、および更新が必要な新旧のデータに変更があるかどうかの判別に使用できます。
Spring Cloud Gatewayでは、SpringはPredicateの特性を使用して、さまざまなルーティングマッチングルールを実装します。ヘッダーやリクエストパラメーターなど、さまざまな条件があり、対応するルートを条件として照合します。Spring Cloudに組み込まれたいくつかの述語の実装を要約した画像がインターネット上にあります。
[
率直に言って、Predicateは、対応するルートを見つけて処理するリクエストを容易にするために、一連のマッチングルールを実装することです。次に、Spring Cloud GateWayのいくつかの組み込みPredicateの使用を引き継ぎます。
リクエストパラメータマッチングにより、リクエストパラメータは上の図にあります。属性を変更するだけです。
春： クラウド： ゲートウェイ： ルート： - ID：method_route URIます。http：// www.google.com 述語： -メソッド= GET
GatewayFilterファクトリの概要
ルートフィルターは、HTTPリクエストの入力と出力をいくつかの方法で変更できます。SpringCloud Gatewayには、さまざまな機能を持つ組み込みのGatewayFilterファクトリがあります。
以下では、これらのGatewayFilterファクトリについて、例を使用して1つずつ説明します。
1. AddRequestHeader GatewayFilterファクトリ
AddRequestHeader GatewayFilterファクトリは、名前と値を設定することでリクエストヘッダーを増やすことができます
spring：
application：
name：cloud-gateway
cloud：
gateway：
discovery：
locator：
enabled：true
＃ルーティング
ルートにマイクロサービス名を使用して、登録センターから動的にルートを作成する機能を有効にします：-id：payment_routh #payment_route＃ルーティングID、固定ルールはありませんが、要件は一意です。サービス名と連携することをお勧めします
#uri：http：// localhost：8001 #uriに一致した後のサービスのルーティングアドレス
：lb：// cloud-payment-service ＃
述語に一致した後のサービスのルーティングアドレス：
-Path = / payment / get / **＃アサーション、ルートマッチングルーティング
フィルター：
-AddRequestHeader = foo、aaa
-AddRequestParameter = foo、bbbccc
-name：Hystrix＃Hystrixフィルター名、デフォルトに設定
args：構成パラメーター
name：fallbackcmd＃HystrixCommand name
fallbackUri：forward：/ fallbackA＃uriのフォールバックペア
2. HttpServletRequest.getHeader（ "foo"）;マルチサービスマイクロサービスの対応する値を取得する
カスタムフィルター：GlobalFilter、Orderedインターフェイスを実装する必要があります
@Component
@ Slf4j
public class MyLogGateWayFilter implements GlobalFilter、Ordered
{
@Override
public Mono <Void> filter（ServerWebExchange exchange、GatewayFilterChain chain）
{
log.info（ "*********** come in MyLogGateWayFilter：" +新しい日付（））;
文字列uname = exchange.getRequest（）。getQueryParams（）。getFirst（ "uname"）;
if（uname == null）
{
log.info（ "*******用户名是null"）;
exchange.getResponse（）。setStatusCode（HttpStatus.NOT_ACCEPTABLE）;
return exchange.getResponse（）。setComplete（）;
}
return chain.filter（exchange）;
public int getOrder（）
{
return 0;
}
}
ヒューズの劣化
なぜヒューズの劣化を達成する必要があるのですか？
分散システムでは、ゲートウェイがトラフィックの入り口として機能するため、多数の要求がゲートウェイに入り、他のサービスへの呼び出しを開始します。必然的に、他のサービスには呼び出しの失敗（タイムアウト、例外）があります。失敗すると、要求をゲートウェイに蓄積できませんすぐに失敗してクライアントに戻る必要があるこの要件を達成するには、ゲートウェイで操作を融合およびダウングレードする必要があります。
ゲートウェイで要求が失敗したのはなぜクライアントに迅速に返される必要があるのですか？
クライアント要求が失敗すると、この要求は常にゲートウェイに蓄積されます。もちろん、そのような要求は1つだけであり、ゲートウェイは問題になりません（要求によってシステム全体が麻痺する可能性がある場合、システムを停止できます）。ただし、ゲートウェイに過度の蓄積があると、ゲートウェイとサービス全体に多大な圧力がかかり、サービス全体でさえ失敗します。したがって、一部のサービスとページを戦略的にダウングレードして、サーバーリソースへの圧力を軽減し、コアビジネスの正常な動作を確保すると同時に、顧客とほとんどの顧客間の正しい対応を維持する必要があるため、ゲートウェイで要求する必要があります。障害はクライアントに迅速に返される必要があります。
ファイル構成：
spring：
application：
name：cloud-gateway
cloud：
gateway：
discovery：
locator：
enabled：true
＃ルーティング
ルートにマイクロサービス名を使用して、登録センターから動的にルートを作成する機能を有効にします：-id：payment_routh #payment_route＃ルーティングID、固定ルールはありませんが、要件は一意です。サービス名と連携することをお勧めします
#uri：http：// localhost：8001 #uriに一致した後のサービスのルーティングアドレス
：lb：// cloud-payment-service ＃
述語に一致した後のサービスのルーティングアドレス：
-Path = / payment / get / **＃アサーション、ルーティングマッチングルーティング
フィルター：
-AddRequestHeader = foo、yinjihuan
引数＃Hystrix 構成パラメーター
-AddRequestParameter = foo、yinjihuanAddRequestParameter
-name
：Hystrix＃Hystrix Filter name、デフォルト名に設定：fallbackcmd＃HystrixCommand name
fallbackUri：forward：/ fallbackA＃uriのフォールバックペア＃Hystrix
設定
hystrix：
fallbackcmd：
実行：
分離：
スレッド：
timeoutInMilliseconds：1000＃ Hystrixのfallbackcmd時間
融合フォールバックA
@RestController
public class FallbackController {
@GetMapping（ "/ fallbackA"）
public CommonResult fallbackA（）{
return new CommonResult（100、 "service temporary unavailable"）;
}
}
Hystrixをフィルタリングします。機能は、Hystrixを介してダウングレードを融合します。
アップストリーム要求がHystrixヒューズダウングレードメカニズムに入ると、fallbackUriによって構成されたダウングレードアドレスを呼び出します。HystrixのcommandKeyのタイムアウト期間も個別に設定する必要があることに注意してください