ゲートウェイの一般的な設計フレームワーク

コンセプト

ゲートウェイ、多くの場所で、ゲートウェイはドアのようなもので、問題はありませんが、ゲートウェイとブリッジの違いを区別する必要があります。

• ブリッジ: データ リンク層で動作し、異なるまたは同じタイプの LAN 間でデータ フレームを格納および転送し、必要に応じてリンク層でプロトコル変換を実行します。情報のパケットが転送される 2 つ以上のネットワークを接続できます。
• ゲートウェイ: 製品の種類を特定するものではなく、大きな概念です. 2 つの異なるネットワークを接続する限り、ゲートウェイと呼ぶことができます. 一般に、ブリッジは情報を転送するだけであり、ゲートウェイはパッケージングを実行する場合があります.

ゲートウェイとサーバー クラスター

以下の図は、ゲートウェイ (ゲートウェイ) の役割を紹介しています. ゲートウェイ モードのアーキテクチャは、サービス インスタンスごとにゲートウェイを構成するのと同じくらい細かく、またはサービスのグループに対してゲートウェイを構成するのと同じくらい粗いことがわかります。または、アーキテクチャ全体を構成するのと同じくらい粗い場合もあります. アクセス ゲートウェイを構成します。その結果、システム アーキテクチャ全体の複雑さがシンプルになり、制御可能になります。

この図は、マルチレイヤー ゲートウェイ アーキテクチャを示しています。このアーキテクチャには、すべてのトラフィックにアクセスして異なるサブシステムに分散する一般的なゲートウェイ (トラフィック ゲートウェイ) と、各サブシステム ゲートウェイ (ビジネス ゲートウェイ) にアクセスするために使用される第 2 レベルのゲートウェイがあります。ゲートウェイによって管理されるサービスの粒度は、粗い場合と細かい場合があることがわかります。ゲートウェイを介して、分散アーキテクチャをスター アーキテクチャに編成し、ネットワークがサービス リクエストをルーティングおよび分散できます。良いゲートウェイが持つべき機能、つまりゲートウェイの設計パターンについて話しましょう。

ゲートウェイ設計のアイデア

ゲートウェイには、次の機能が必要です。

リクエスト ルーティング

ゲートウェイには、リクエスト ルーティングの機能が必要です。このように、発信者にとっても非常に便利なことです。呼び出し元は、使用する必要がある他のサービスのアドレスを知る必要がないため、それらはすべて処理のためにゲートウェイに引き渡されます。

サービス登録

背後のサービスをプロキシし、要求を正しい場所にルーティングできるようにするために、ゲートウェイにはサービス登録機能が必要です。つまり、バックエンド サービス インスタンスは、提供するアドレスを登録および登録解除できます。一般的に言えば、登録とは、いくつかの API インターフェースを登録することを意味します。たとえば、HTTP Restful リクエストの場合、対応する API の URI、メソッド、および HTTP ヘッダーを登録できます。このようにして、Gateway は、受信したリクエストの情報に基づいて、ルーティングするバックエンド サービスを決定できます。

負荷分散

ゲートウェイは複数のサービス インスタンスを受信できるため、ゲートウェイは各ピア サービス インスタンスに負荷分散戦略を実装する必要もあります。単純なものは直接のラウンド ロビン ポーリングであり、より複雑なものは配布用に設定でき、より複雑なものはセッション スティッキングも実現できます。

弾性設計

ゲートウェイは、非同期、再試行、べき等、フロー制御、ヒューズ、監視などを柔軟な設計で実装することもできます。このように、サービス メッシュと同様に、アプリケーション サービスは、制御ロジック (コントロール プレーン) ではなく、独自のビジネス ロジック (またはデータ プレーン上のもの) のみを扱うことができます。

安全

SSL 暗号化と証明書の管理、セッションの検証、承認、データの検証、およびリクエスト ソースに対する悪意のある攻撃の防止。エラー処理が早ければ早いほど良い. したがって、ゲートウェイは、バックエンド サービスを保護するためのサイト全体のアクセス コンポーネントになることができます。もちろん、ゲートウェイは、グレースケール パブリッシング、API アグリゲーション、API オーケストレーションなど、ますます興味深いことも実行できます。

グレースケール リリース
ゲートウェイは、同じサービスの異なるバージョンのインスタンスを完全に迂回させることができ、関連データを収集することもできます。これは、ソフトウェアの品質の向上だけでなく、製品の試行錯誤にも非常に役立ちます。
API Aggregation
Gateway を使用すると、複数の個別のリクエストを 1 つのリクエストに集約できます。マイクロサービス システムのアーキテクチャでは、サービスが小さくなるため、明らかな問題は、クライアントがすべてのデータを取得するために複数の要求が必要になる可能性があることです。その結果、クライアントとバックエンド間の頻繁な通信は、アプリケーションのパフォーマンスとスケールに非常に悪影響を及ぼす可能性があります。したがって、ゲートウェイは、クライアントが複数のバックエンド サービスを要求するのを支援し (シナリオによっては、同時要求を行うことができます)、バックエンド サービスの応答結果を組み立てて、クライアントに送り返すことができます (もちろん、 、このプロセスは非同期でも実行できますが、これにはクライアントの協力が必要です)。
API オーケストレーション
また、マイクロサービス アーキテクチャの下で、完全なビジネス プロセスを完了するには、Web ページを通じてオーケストレーションできる一連の API をワークフローと同様に呼び出す必要があります。DSL を介してさまざまな API を定義および調整したり、AWS Lambda サービスのような方法でさまざまな API を接続したりできます。

ゲートウェイ設計の焦点

ゲートウェイの設計には、ハイ パフォーマンス、ハイ アベイラビリティ、およびハイ エクスパンションの 3 つの主要なポイントがあります。

ハイパフォーマンス

技術的な設計に関しては、ゲートウェイがパフォーマンスのボトルネックになるべきではありません。高いパフォーマンスを得るには、C、C++、Go、Java などの高性能プログラミング言語を使用するのが最適です。バックエンドへのゲートウェイのリクエスト、およびフロントエンドへのリクエストのサービスでは、非同期のノンブロッキング I/O を使用して、バックエンドのレイテンシがアプリケーションのパフォーマンスの問題を引き起こさないようにする必要があります。C と C++ は、Linux では epoll の非同期 IO モデル、Windows では I/O Completion Port を、Java では Netty と Spring Reactor の NIO フレームワークを参照できます。

高可用性

すべてのトラフィックまたは通話がゲートウェイを通過するため、ゲートウェイは可用性の高い技術コンポーネントになる必要があり、その安定性はすべてのサービスの安定性に直接関係しています。ゲートウェイは、設計されていない場合、単一障害点になります。したがって、優れたゲートウェイは、少なくとも次のことを行う必要があります。

• クラスタリング。ゲートウェイがクラスターになるには、データを同期するサードパーティ システムに依存せずに、それ自体でクラスターを形成し、それ自体でクラスター データを同期することをお勧めします。
• サービス化。ゲートウェイも、Nginx のリロード構成のようにノンストップでサービスを実現するためと、サービス指向を実現するために、中断なく構成を変更できる必要があります。つまり、実行時に構成を変更するには、独自の管理 API が必要です。
• 持続性。たとえば、再起動とは、Nginx のように正常に再起動することです。リクエストの配布を監視するメイン プロセスがあります。再起動が必要になると、新しいリクエストが新しいプロセスに割り当てられ、処理中のリクエストの処理後に古いプロセスが終了します。

高膨張

ゲートウェイはすべてのビジネス トラフィックと要求を処理する必要があるため、多かれ少なかれビジネス ロジックが必要です。そして、ビジネス ロジックが変更可能で不確実であることは誰もが知っています。たとえば、ビジネス関連のものをゲートウェイに追加する必要があります。したがって、優れたゲートウェイは拡張性があり、二次開発が可能である必要があります。もちろん、NginxのようなModuleによる二次開発ももちろん可能です。

さらに、運用と保守の観点から、ゲートウェイは次の設計原則を持つ必要があります。

• サービスは疎結合で、プロトコルは密結合です。ビジネス設計の観点から、ゲートウェイは、後続のサービスと結合するサービスを形成したり、ビジネス ロジックを持ったりするべきではありません。ゲートウェイは、ネットワーク アプリケーション層のコンポーネントである必要があり、通信プロトコルの本体を処理する必要はありませんが、通信プロトコル ヘッダーのみを解析して処理する必要があります。また、ゲートウェイは、サービス検出以外のサードパーティ サービスに依存しないようにする必要があります。
• アプリケーションの監視、分析データの提供。アプリケーション パフォーマンスの監視は、ゲートウェイで考慮する必要があります。対応するバックエンド サービスの高可用性統計に加えて、トレース ID を使用して分散リンク トラッキングを実装し、スループットとパフォーマンスをカウントすることも必要です。一定時間内の各 API の応答時間と、エラスティック デザインで対応する戦略を開始するためのリターン コード。
• 弾力性のある設計でバックエンド サービスを保護します。ヒューズ、電流制限、再試行、タイムアウトなどの柔軟な設計をゲートウェイに実装する必要があります。1 つ以上のサービス呼び出しに時間がかかりすぎる場合は、タイムアウトしてデータの一部を返すか、ゲートウェイで最後に成功した要求からデータのキャッシュを返すことが許容されます。そんなデザインが考えられます。
• DevOps . ゲートウェイ コンポーネントは非常に重要であるため、障害の可能性を最小限に抑えるために DevOps のようなものが必要です。ソフトウェアは、機能テストやパフォーマンス テスト、浸漬テストなど、十分にテストする必要があります。自動化された運用と保守のための一連の管理および制御ツールも必要です。

ゲートウェイの設計に関する考慮事項

1. 集約バックエンド サービス機能をゲートウェイのコードに組み込む代わりに、集約サービスをゲートウェイ コア コードの外に配置することを検討してください。プラグインを使用することも、ゲートウェイの背後に配置してサーバーレス サービスを形成することもできます。
2. ゲートウェイはバックエンド サービスの近くに配置し、バックエンド サービスと同じイントラネットを使用する必要があります。これにより、ゲートウェイとバックエンド サービスの呼び出しの待ち時間が短くなり、ネットワーク上の多くの問題を軽減できます。ここでもう 1 つ言うと、ゲートウェイによって処理される静的コンテンツはユーザーの近くにある必要があり (CDN に配置される必要があります)、ゲートウェイと動的サービスはこの時点でバックエンド サービスの近くにある必要があります。
3. ゲートウェイも容量拡張が必要な​​ので、フロントエンドからのトラフィックを共有するためにクラスター化する必要があります。これは、DNS ポーリング、トラフィック スケジューリング用の CDN、またはパフォーマンスの高い低レベルの負荷分散デバイスによって実現されます。
4. サービス ディスカバリの場合、短期間のキャッシュを作成できるため、リクエストするたびに関連するサービスの場所を確認する必要がありません。もちろん、システムが複雑でない場合は、サービス ディスカバリ機能をゲートウェイに直接統合することを検討できます。
5. ゲートウェイの隔壁設計アプローチを検討してください。異なるゲートウェイを使用して異なるバックエンド サービスを提供するか、異なるゲートウェイを使用して異なるフロントエンド カスタマーにサービスを提供します。

さらに、ゲートウェイはユーザー要求とバックエンド サービスのブリッジ デバイスであるため、いくつかのセキュリティ問題を考慮する必要があります。詳細は次のとおりです。

1. データを暗号化します。SSL 関連の証明書をゲートウェイに置くことができ、ゲートウェイは統一された SSL 伝送管理を実行します。
2. ユーザーのリクエストを検証します。ユーザーがログインしているかどうか、ユーザー要求のトークンが合法であるかどうかなど、いくつかの基本的なユーザー検証をゲートウェイで実行できます。ただし、ゲートウェイがユーザーの入力を検証する必要があるかどうかを検討する必要があります。このように、ゲートウェイは、プロトコル ヘッダーのみを気にすることから、プロトコル本体を気にするように変更する必要があるためです。一方では、プロトコル本体の内容はプロトコル ヘッダーほど標準的ではなく、他方では、プロトコル本体の解析に多くの実行時間がかかり、ゲートウェイのパフォーマンスが低下します。この点に関して、私が言いたいのは、特定の要件によっては、一方ではプロトコル本体が標準であれば実行できるということですが、他方では、構文解析プロトコルによって引き起こされるパフォーマンスの問題については、対応する分離を行う必要があります。
3. 異常なアクセスを検出します。ゲートウェイは、比較的短期間にリクエスト数が一定の値を超える、同じクライアントからの 4xx リクエストのエラー率が高すぎるなど、いくつかの異常なアクセスを検出する必要があります。一方、ハッキングなどの比較的深刻なセキュリティ上の問題である可能性があることを警告する必要があります。

トラフィック ゲートウェイ

トラフィック ゲートウェイは、名前が示すように、クラスタに入るトラフィックを制御するゲートウェイです. このステップでは、多くの作業を行う必要があります. サービス クラスタの場合、多くの不正または無効なリクエストが発生することは間違いありません. フロー プレッシャー.

グローバルで、特定のバックエンド ビジネス アプリケーションやサービスとは関係のないポリシー ゲートウェイを定義するのが、上の図に示すアーキテクチャ モデル、つまりトラフィック ゲートウェイです。トラフィック ゲートウェイは通常、グローバル トラフィック モニタリング、ロギング、グローバル トラフィック制限、ブラック リストとホワイト リストの制御、アクセス リクエストからビジネス システムへの負荷分散など、グローバルな API 管理戦略のみに焦点を当てています。これらは、ファイアウォールにいくぶん似ています。Kong は典型的なトラフィック ゲートウェイです。

以下は、kong のアーキテクチャ図です。

ここで追加する必要があるのは、ビジネス ゲートウェイは通常、トラフィック ゲートウェイの後、ビジネス システムの前に配置され、トラフィック ゲートウェイよりもビジネス システムに近いということです。通常、API ネットワークはサービス ゲートウェイを指します。場合によっては、トラフィック ゲートウェイとビジネス ゲートウェイをあいまいにし、1 つのゲートウェイにすべての作業を任せるため、2 つの間に厳密な境界はありません。

ビジネスゲートウェイ

1 つのアプリケーションが多数のマイクロサービス アプリケーションに分割されると、いくつかの問題も発生します。パーミッション制御、ログ出力、データ暗号化、ヒューズ電流制限など、ビジネスにあまり関係のない機能は、すべてのマイクロサービス アプリケーションで必要になるため、コードの実装の繰り返しが多くなります。また、システムの反復や人員の入れ替えにより、マイクロサービスごとにこれらの機能の実装内容に大きな違いが生じ、保守コストが高くなります。一方、元の単一アプリケーションの下では非常に簡単に実行できたインターフェース管理は、サービスが分割された後は集中管理する場所がなくなり、どのインターフェースが存在するか、インターフェースの定義が何であるかを数えることができず、そして、実行状況は何ですか。

上記の問題を解決するのがゲートウェイです。マイクロサービス システムのコア インフラストラクチャとして、一般に、インターフェイス管理、プロトコル適応、ヒューズ電流制限、セキュリティ保護などの機能が必要です。さまざまなオープン ソース ゲートウェイ製品 (zuul など) は、優れた拡張性の高いアーキテクチャを提供します。認証、ログ監視、回路遮断、電流制限など、必要な機能の一部を実現するのに非常に便利です。

トラフィック ゲートウェイに対応するのはビジネス ゲートウェイで、これは私たちのビジネスに近い、つまりサーバー アプリケーション レイヤーを扱うため、スレッド モデルなど、アプリケーション レイヤーがビジネス ゲートウェイに依存できるように考慮しなければならないことがたくさんあります。 、プロトコル適応、回路遮断と電流制限、サービスオーケストレーションなど。ビジネス ゲートウェイのアーキテクチャを見てみましょう。

このようにして、ビジネス ゲートウェイの主な責任とその機能を確認できます.現在、ビジネス ゲートウェイには、Zuul1、Zuul2、SpringCloud Gateway の 3 つの比較的成熟した API ゲートウェイ フレームワーク製品があり、後で比較します.

一般的なゲートウェイの比較

比較しているので、まずさまざまなゲートウェイを巨視的に理解してから、詳細な理解のために一般的に使用されている、または広く使用されているものを選択しましょう。
現在、一般的なオープン ソース ゲートウェイは、言語によって次のカテゴリに大まかに分類されます。

• Nginx+lua：OpenResty、Kong、Orange、Abtesting Gateway など
• Java：Zuul/Zuul2、Spring Cloud Gateway、Kaazing KWG、gravitee、Dromara soul 等
• Go：Janus、fagongzi、Grpc-gateway
• ドットネット：オセロット
• NodeJS：Express Gateway、Micro Gateway

使用回数、成熟度などにより、4つの主流があります。

• OpenResty
• コング
• ズール/ズール2
• Spring クラウド ゲートウェイ

OpenResty

OpenResty はトラフィック ゲートウェイです. トラフィック ゲートウェイの前の紹介によると、トラフィック ゲートウェイの告発を知ることができます。

OpenResty は、Nginx と Lua に基づく高性能 Web プラットフォームであり、多数の優れた Lua ライブラリ、サードパーティ モジュール、およびその依存関係のほとんどを統合しています。非常に高い同時実行性と高いスケーラビリティを処理できる動的 Web アプリケーション、Web サービス、および動的ゲートウェイを便利に構築するために使用されます。

適切に設計された多くの Nginx モジュールを組み合わせることにより、OpenResty は効果的に Nginx サーバーを強力な Web アプリケーション サーバーに変えます. これに基づいて、開発者は Lua プログラミング言語を使用して、Nginx コアとさまざまな既存の Nginx C モジュールをプログラムできます. 10,000 を超える同時リクエストを処理できる Web アプリケーション

OpenResty は OpenAPI の流行に合わせて最初に作られたものなので、Open は「オープン」という意味で、Resty は REST スタイルという意味です。ただし、後で ngx_openresty に基づいて、任意の形式の Web サービスまたは従来の Web アプリケーションを実装できます。

つまり、Nginx はもはや単純な静的 Web サーバーではなく、単純なリバース プロキシでもありません。第 2 世代の openresty は、一連の nginx モジュールを通じて nginx をフル機能の Web アプリケーション サーバーに拡張することに専念しています。

ngx_openresty はユーザー主導のプロジェクトであり、その後多くの国内ユーザーが参加しました.openresty.org のクリックの分布から、国内と海外のクリックは基本的に同じです.

ngx_openresty には現在 2 つのアプリケーション ターゲットがあります。

1. 汎用 Web アプリケーション サーバー。この目標の下で、既存の Web アプリケーション テクノロジは、Nodejs、PHP などの OpenResty と多かれ少なかれ類似していると見なすことができます。ngx_openresty のパフォーマンス (メモリ使用量と CPU 効率を含む) は、最大のセールス ポイントの 1 つです。
2. 柔軟な Web アプリケーション ゲートウェイと Web アプリケーション ファイアウォールを構築するための Nginx スクリプト拡張プログラミング。やや似ているのは NetScaler です。その強みは、Lua プログラミングがもたらす大きな柔軟性にあります。

コング

Kong は OpenResty に基づいて開発されたトラフィック レイヤー ゲートウェイでもあり、クラウドネイティブで高速、スケーラブルな分散型 API ゲートウェイです。OpenResty の高いパフォーマンスと簡単なスケーラビリティを継承しています。Kong は、マシン ノードを追加するだけで簡単に水平方向に拡張できます。同時に、機能はプラグインであり、その機能はプラグインを通じて拡張できます。また、あらゆるインフラストラクチャで動作します。次のプロパティがあります。

• API を保護するためのさまざまな認証レイヤーを提供します。
• 入力および出力トラフィックを規制できます。
• ビジュアル トラフィック インスペクション、モニタリング、および分析 API を提供します。
• 要求と応答をタイムリーに変換できます。
• ログソリューションを提供する
• サーバーレス関数は、API を介して呼び出すことができます。

Kong はどのような問題を解決しますか?
アプリケーションをマイクロサービスに変換することを決定すると、アプリケーション クライアントがマイクロサービスとどのように対話するかという問題も発生します. 結局、サービスの数の増加は、展開の承認、負荷分散、負荷分散に直接つながります。コミュニケーション管理、分析、変更がより困難になります。

上記の問題に対して、API GATEWAY は優れたソリューションであり、アクセス制限、セキュリティ、フロー制御、分析と監視、ロギング、リクエスト転送、合成、およびプロトコル変換機能を提供し、開発者を特定の論理コードに集中させることができます。アプリケーションと他のマイクロサービスをリンクする問題を解決する方法について考えるのに時間を費やすこと。

コングの公式ウェブサイトからの写真：

Kong が解決する問題を見ることができます。グローバル API 管理戦略、グローバル トラフィック モニタリング、ロギング、グローバル トラフィック制限、ブラック リストとホワイト リストの制御、アクセス リクエストからビジネス システムへの負荷分散などに焦点を当てます。
Kong の利点とパフォーマンス
数ある API GATEWAY フレームワークの中でも、Mashape のオープン ソースの高性能で高可用性の API ゲートウェイおよび API サービス管理レイヤーである KONG (NGINX+Lua ベース) は特に優れており、プラグインによって既存の機能を拡張できます。 . これらのプラグイン (lua で記述) は、API 要求応答ループのライフサイクル中に実行されます。同時に、KONG 自体は、HTTP 基本認証、キー認証、CORS、TCP、UDP、ファイル ログ、API 要求フロー制限、要求転送、NGINX 監視などの基本機能を提供します。現在、Kong は Mashape で 15,000 以上の API を管理し、1 か月あたり数十億のリクエストで 200,000 人の開発者をサポートしています。
Kong アーキテクチャ
Kong は一連のサービスを提供するため、内部アーキテクチャについて説明する必要があります。

まず、最下層は Nginx に基づいており、Nginx は高性能の基本層であり、優れた負荷分散、リバース プロキシ、およびこれに基づいて Lua スクリプト ライブラリを追加し、OpenResty を形成し、要求をインターセプトし、ライフ サイクルに応答します。 、Lua 書き込みスクリプトを渡すことができるため、プラグインは比較的豊富です。

Zuul1.0

Zuul は、デバイスや Web サイトから Netflix ストリーミング アプリケーションのバックエンドへのすべての要求の玄関口です。エッジ サービス アプリケーションとして、Zuul は動的ルーティング、監視、回復力、およびセキュリティをサポートするように構築されています。また、必要に応じてリクエストを複数の Amazon Autoscaling グループにルーティングすることもできます。

Zuul は、さまざまな種類のフィルターを使用して、機能をサービスに迅速かつ柔軟に適用できるようにします。
フィルタ
フィルタは、Zuul のコア機能です。アプリケーションのビジネス ロジックを担当し、さまざまなタスクを実行できます。

• Type : 通常、フィルターが適用されるステージを定義します。
• Async : フィルターが同期か非同期かを定義します
• 実行順序: 実行順序
• Criteria : フィルタ実行条件
• アクション: 条件が満たされた場合、フィルターによって実行されるアクション

Zuul は、これらのフィルターを動的に読み取り、コンパイルし、実行するためのフレームワークを提供します。フィルタは互いに直接通信しませんが、各リクエスト固有の RequestContext を通じて状態を共有します。
Zuul のフィルタの一部を次に示します。
Incoming
Incoming フィルタは、リクエストが Origin にプロキシされる前に実行されます。これは通常、ほとんどのビジネス ロジックが実行される場所です。例: 認証、動的ルーティング、レート制限、DDoS 保護、メトリック。

エンドポイント
エンドポイント フィルターは、受信フィルターの実行に基づいて要求を処理します。Zuul には、リクエストをバックエンド サーバーにプロキシするための組み込みフィルター (ProxyEndpoint) があるため、これらのフィルターの一般的な用途は静的エンドポイントです。例: ヘルスチェック応答、静的エラー応答、404 応答。

送信
送信フィルターは、バックエンドからの応答を受信した後に処理アクションを実行します。通常、それらは、重い作業よりも、応答の形成とメトリックの追加に使用されます。例: 統計の保存、標準ヘッダーの追加/削除、ライブ ストリームへのイベントの送信、応答の gzip 圧縮。
フィルタ タイプ
以下は、リクエストの一般的なライフサイクルに対応する標準のフィルタ タイプです。

• PRE : Origin へのルーティング前に実行
• ROUTING : オリジンへのルーティング中に実行
• POST : リクエストが Origin にルーティングされた後に実行されます
• ERROR : エラー発生時に実行

これらのフィルターは、次の機能を実行するのに役立ちます。

• 認証とセキュリティ: 各リソースの認証ニーズを特定し、それらを満たさないリクエストを拒否します
• モニタリング: エッジで意味のあるデータと統計を追跡して、生産の正確なビューを提供します
• 動的ルーティング: リクエストを異なるバックエンド クラスタに動的にルーティングします
• ストレス テスト: クラスタへのトラフィックを徐々に増やしてパフォーマンスを評価します
• Throttle : リクエスト タイプごとに容量を割り当て、制限を超えたリクエストを破棄します
• 静的応答処理: 内部クラスターに転送するのではなく、エッジで直接いくつかの応答を構築します

Zuul 1.0 リクエストのライフサイクル

Netflix は、汎用 API ゲートウェイである Zuul のアーキテクチャの変革を発表しました。Zuul はもともと同期ブロッキング アーキテクチャを採用していましたが、変換後は Zuul2 と呼ばれ、非同期ノンブロッキング アーキテクチャを採用しました。アーキテクチャに関する Zuul2 と Zuul1 の主な違いは、Zuul2 が Netty などの非同期ノンブロッキング フレームワークで実行されることです。Zuul1 はスループットの向上をサポートするためにマルチスレッドに依存していますが、Zuul 2 で使用される Netty フレームワークはイベント ループとコールバック関数に依存しています。

Zeul2.0

Zuul 2.0 のアーキテクチャ図

上の図は、Zuul2 のアーキテクチャを示しています。これは、Zuul1 と本質的な違いはありませんが、次の 2 つの変更があります。

1. フロントエンドは、サーブレットの代わりに Netty サーバーを使用して、フロントエンドの非同期性をサポートします。バックエンドは、Http クライアントの代わりに Netty クライアントを使用して、バックエンドの非同期性をサポートします。
2. フィルターの名前が変更され、プレルーティング フィルターがインバウンド フィルターに置き換えられ、ルーティング フィルターがエンドポイント フィルターに置き換えられ、ポストルーティング フィルターがアウトバウンド フィルターに置き換えられました。

Inbound Filters : Origin にルーティングする前に実行され、認証、ルーティング、装飾リクエストに使用できます
Endpoint Filters : 静的応答を返すために使用できます。それ以外の場合、組み込みの ProxyEndpoint フィルターが要求を Origin にルーティング
しますOrigin からの応答。ユーザー応答の測定、装飾、またはカスタム ヘッダーの追加に使用できます。

フィルターには、同期と非同期の 2 種類があります。Zuul はイベント ループで実行されるため、フィルタリングでブロックしないでください。ブロックする必要がある場合は、非同期フィルターでブロックし、別のスレッド プールで実行します。それ以外の場合は、同期フィルターを使用します。

上記のように、Zuul2は非同期モデルを採用し始めました.
利点は、非同期ノンブロッキングモードで起動されるスレッドが少ないことです.基本的に、CPUコアで起動する必要があるイベントリング処理スレッドは1つだけであり、使用するスレッドはほとんどありません.スレッド リソース コンテキスト スイッチング ( Context Switch ) のオーバーヘッドは少なくなります。ノンブロッキングモードで受け付けられる接続数が大幅に増加します. リクエストが来たら, キューに入るだけでよいことが簡単に理解できます. このキューの容量は非常に大きく設定できます.タイムアウトしない場合、キュー内のリクエストは順次処理されます。

十分ではありませんが、非同期モードはプログラミング モデルを複雑にします。一方では、Zuul2 自体のコードは Zuul1 のコードよりもはるかに複雑で、Zuul1 のコードは理解しやすいですが、Zuul2 のコードはより面倒に見えます。一方、非同期モデルはリクエスト→処理→レスポンスの実行フロー（コールフロー）が明確ではなく、イベントによってフローがトリガーされ、いつでもリクエスト処理フローが切り替わったり、切断されたりする可能性があります。実装はいくつかの関連付けを渡す必要がある ID メカニズムは、実行フロー全体を直列に接続できるため、開発、デバッグ、およびメンテナンスが非常に複雑になります. たとえば、非同期リクエスト フローをIDE。さらに、ThreadLocal メカニズムは、この非同期モードで単純に機能することはできません。イベント ループ スレッドは 1 つのみであり、各要求に対して 1 つのスレッドではなく、スレッドの局所性の概念がないためです。そのため、CAT の場合、ThreadLocal に依存する監視ツールコール チェーンを埋めるのは簡単ではありません (実際には動作しますが、特別な処理が必要です)。

一般的に言えば、非同期ノンブロッキング モードは、IO 集約型 (IO バウンド) のシナリオにより適しています. このシナリオでは、システムはほとんどの時間 IO を処理しており、CPU 計算は比較的軽く、少数のイベントループスレッドはそれを処理できます。

パフォーマンスについては、Netflix はかなりあいまいなデータを提供しました. Zuul2 のパフォーマンスは Zuul1 よりも約 20% 優れています. ここでのパフォーマンスは、主にノードごとに 1 秒あたりに処理されるリクエストの数を指します. なんで曖昧って言うの？このデータは、実際のテスト環境や交通シーン モードなどの多くの要因の影響を受けるため、このテスト データを再現することは困難です。この 20% のパフォーマンス向上が事実であるとしても、実際には、このパフォーマンス向上は大きくはなく、非同期性によって導入される複雑さと比較して、この 20% の向上が価値があるかどうかは疑問です。Netflix 自体は、ブログ記事 22 と ppt11 で少しあいまいであり、独自の疑問さえ持っています。

Spring クラウド ゲートウェイ

SpringCloud Gateway は、Spring Cloud の新しいプロジェクトです.このプロジェクトは、Spring 5.0、Spring Boot 2.0、Project Reactor などのテクノロジに基づいて開発されたゲートウェイであり、マイクロサービス アーキテクチャ向けのシンプルで効果的な統合 API ルーティング管理方法を提供することを目的としています.

Spring Cloud エコシステムのゲートウェイとして、SpringCloud Gateway は Zuul を置き換えることを目指しています.Spring Cloud 2.0 以降では、Zuul 2.0 以降の最新の高性能バージョンを統合せず、Zuul 2.0 より前の非 Reactor モードを引き続き使用しますの古いバージョン。ゲートウェイのパフォーマンスを向上させるために、SpringCloud Gateway は WebFlux フレームワークに基づいて実装され、WebFlux フレームワークの最下層には高性能な Reactor モード通信フレームワーク Netty が使用されます。

Spring Cloud Gateway の目標は、統一されたルーティング方法を提供することだけでなく、セキュリティ、監視/インジケーター、電流制限など、フィルター チェーンに基づいてゲートウェイの基本機能を提供することでもあります。
Spring Cloud Gateway の最下層は、高性能通信フレームワークである Netty を使用します。
SpringCloud ゲートウェイの機能
SpringCloud 公式では、SpringCloud ゲートウェイの機能は次のように紹介されています。
(1) Spring Framework 5、Project Reactor、および Spring Boot 2.0 に基づく
(2) 統合された Hystrix サーキット ブレーカー
(3) 統合された Spring Cloud DiscoveryClient
(4) 述語とフィルター特定のルーティングに作用し、書きやすい Predicate と Filter
(5) にはゲートウェイの高度な機能がいくつかあります: 動的ルーティング、現在の制限、パスの書き換え
上記の特性から、Zuul の特性と大差ありません。SpringCloud Gateway と Zuul の主な違いは、基礎となる通信フレームワークにあります。
上記の 3 つの用語を簡単に説明します。
フィルター(フィルター)
は概念的には Zuul のフィルターに似ており、要求を傍受して変更し、上流の応答に対して二次処理を実行するために使用できます。フィルターは org.springframework.cloud.gateway.filter.GatewayFilter クラスのインスタンスです。
ルート(ルーティング)
ゲートウェイ構成の基本コンポーネント モジュールは、Zuul のルーティング構成モジュールに似ています。一Route モジュールは、ID、ターゲット URI、一連のアサーション、および一連のフィルターによって定義されます。アサーションが true の場合、ルートが一致し、ターゲット URI にアクセスします。
Predicate :
これは、ヘッダーやパラメーターなど、HTTP 要求のあらゆるものと一致させるために使用できる Java 8 Predicate です。アサートされた入力タイプは ServerWebExchange です。

複数のゲートウェイの比較

ゲートウェイ	制限する	認証	モニター	使いやすさ	保守性	成熟
Spring クラウド ゲートウェイ	IP、ユーザー、およびクラスターの現在の制限によって拡張でき、対応するインターフェイスを提供します	共通認証、auth2.0	ゲートウェイ メトリック フィルタ	使いやすい	スプリング シリーズは拡張性が高く、設定と保守が容易です。	春のコミュニティは成熟していますが、ゲートウェイのリソースは少ないです
ズール 2	クラスター電流制限と単一サーバー電流制限は構成ファイルで構成でき、電流制限拡張はフィルターで実現できます	フィルタに実装	フィルタに実装	参照が少ない	保守性が悪い	すぐにオープンソース、情報が少ない
OpenResty	lua 開発が必要	lua 開発が必要	開発する必要がある	使いやすいが、多くの lua 開発が必要	メンテナンス性が悪く、将来大量の lua スクリプトのメンテナンスが必要になる	非常に成熟しており、多くの情報
コング	秒、分、時、日、月、年に応じて、ユーザーに応じてフローが制限されます。オリジナルコードをベースに開発可能	共通認証、Key Auth認証、HMAC、auth2.0	Datadog は、リクエストの数、リクエストされたデータの量、応答データの量、送受信間の時間間隔、ステータス コードの数、および Kong での実行時間を記録するために報告できます。	使いやすく、API 転送は管理者インターフェースを介して構成され、開発には lua スクリプトが必要です	「メンテナンス性が悪く、今後大量のluaライブラリのメンテナンスが必要になる」	比較的成熟している、ユーザーの問題のまとめ、コミュニティ、プラグインのオープン ソース