SpringCloudマイクロサービスプロジェクトCombat-zuulゲートウェイの詳細とビルド

前の記事ではサービスの呼び出しについて説明しましたが、この記事では前のトピックに続き、Spring Cloudでのzuulの使用とゲートウェイの確立について説明します。

まず、ゲートウェイとは何かを知る必要がありますか？
ゲートウェイは、システムの統合フロントエンド入口です。これは、クライアントとサーバーの間の中間層です。主に、ビジネス以外の機能を処理し、ルーティング要求、認証、監視、キャッシング、現在の制限などの機能を提供するために使用されます。クライアントによって開始された要求は、最初にビジネス機能以外の処理のためにゲートウェイを通過し、次にパスのルーティングに従って特定のサービスノードに移動します。

同時に、システムはサービスルーティングの機能を使用します。これは、サービスを外部に提供するときにゲートウェイで設定されたコールアドレスのみを公開でき、発信者はバックエンドの特定のマイクロサービスホストを知る必要はありません。実際のサービスアドレス情報を効果的に保護できます。Zuulはマイクロサービスゲートウェイであり、まずマイクロサービスです。また、ユーレカ登録センターでサービスを登録および検出します。これはゲートウェイでもあり、リクエストはZuul経由でルーティングされます。Zuulゲートウェイは必要ありません。オススメです。SpringCloud zuulの紹介

1.マイクロサービスゲートウェイを使用する理由

通常、マイクロサービスごとに異なるネットワークアドレスがあり、クライアントはビジネス要件を完了するために複数のサービスインターフェイスを呼び出す必要がある場合があります。クライアントが各マイクロサービスと直接通信する場合、次の問題が発生します。

1）クライアントは何度も異なるマイクロサービスを要求するため、クライアントの複雑さが増します。

2）クロスドメイン要求があり、処理は比較的複雑です。

3）認証は複雑であり、各サービスには独立した認証が必要です。

4）再構築が困難な場合、複数のサービスが1つにマージされるか、複数に分割される可能性があります。

2.ゲートウェイを使用するメリットとデメリットは？

利点：

すべての外部リクエストは、特定のマイクロサービスインターフェースを呼び出すことなく、最初にマイクロサービスゲートウェイを介して対話し、開発を簡素化します。
サービスゲートウェイ=ルーティング転送+フィルター

ルーティングと転送：リクエストを受信してバックエンドのマイクロサービスに転送します。
フィルター：サービスゲートウェイで一連の横断的な機能を実行できます（権限検証）

欠点：ゲートウェイを増やすと、追加の転送レイヤーがあり、サービスのパフォーマンスが低下します。

3. zuulを使用する役割は何ですか？Zuulは、動的フィルタリングメカニズムをロードすることにより、次の機能を実装できます。

検証とセキュリティ：さまざまなリソースの検証要件を特定し、要件に一致しない要求を拒否します。
レビューとモニタリング：有意義なデータと統計結果をエッジで追跡し、正確な生産状況の結論を導きます。
動的ルーティング：必要に応じて、要求を動的に異なるバックエンドクラスターにルーティングします。
ストレステスト：クラスターに送信される負荷トラフィックを徐々に増やして、パフォーマンスレベルを計算します。
負荷分散：負荷のタイプごとに対応する容量を割り当て、制限を超えるリクエストを破棄します。
静的応答処理：部分的な応答はエッジで直接確立され、内部クラスターに流れ込まないようにします。
マルチリージョンの柔軟性：AWSリージョン間のリクエストルーティングは、ELBの使用を多様化し、エッジの場所をユーザーにできるだけ近づけることを目的としています。

4.ズールはどのように機能しますか？

zuulの中核は一連のフィルターです。その役割は、サーブレットフレームワークのフィルター（AOP）と比較できます。リクエストルートをユーザー処理ロジックに挿入するプロセスでは、これらのフィルターは、認証、負荷制限などの一部のフィルタープロセスに参加します。

Zuulは、フィルターを動的にロード、コンパイル、および実行するためのフレームワークを提供します。

Zuulのフィルター間に直接の通信はなく、それらはRequestContextの静的クラスを介してデータを渡します。各Requestが渡す必要のあるデータを記録するために、RequestContextクラスにはThreadLocal変数があります。

ZuulのフィルタはGroovyによって作成されます。これらのフィルタファイルはZuul Serverの特定のディレクトリに配置されます。Zuulはこれらのディレクトリを定期的にポーリングします。変更されたフィルタは、リクエストをフィルタリングするためにZuul Serverに動的にロードされます。

いくつかの標準フィルタータイプがあります。

Zuulのほとんどの機能はフィルターを介して実装されます。Zuulでは4つの標準フィルタータイプが定義されており、これらのフィルタータイプはリクエストの一般的なライフサイクルに対応しています。

1）PRE：このフィルターは、リクエストがルーティングされる前に呼び出されます。このフィルターを使用して認証を実装し、クラスター内の要求されたマイクロサービスを選択して、デバッグ情報を記録できます。

2）ルーティング事業。このフィルターは、マイクロサービスに送信される要求を作成し、Apache HttpClientまたはNetfilxリボンを使用してマイクロサービスを要求するために使用されます。

3）POST：このフィルターは、マイクロサービスへのルーティング後に実行されます。このフィルターを使用して、標準のHTTPヘッダーを応答に追加し、統計とメトリックを収集し、マイクロサービスからクライアントに応答を送信できます。

4）ERROR：他の段階でエラーが発生すると、フィルターが実行されます。

内蔵特殊フィルター

zuulは、特殊なタイプのフィルターも提供します。つまり、StaticResponseFilterとSurgicalDebugFilterです。

StaticResponseFilter：StaticResponseFilterを使用すると、リクエストをソースに転送するのではなく、Zuul自体から応答を生成できます。
SurgicalDebugFilter：SurgicalDebugFilterを使用すると、特定のリクエストを個別のデバッグクラスタまたはホストにルーティングできます。

カスタムフィルター

デフォルトのフィルタータイプに加えて、Zuulではカスタムフィルタータイプを作成することもできます。

5. ZuulとNginxの違いは同じです。ZuulとNginxは、ロードバランシング、リバースプロキシ（実際のIPアドレスを非表示にする）、リクエストのフィルタリング、ゲートウェイの効果の実現を実現できます。