ゲートウェイ開発ドキュメント

ゲートウェイ

2024-07-12

ゲートウェイのコア概念

1.ルート

ルーティングは、ゲートウェイの最も基本的な部分であり、ルーティング情報には、ID、宛先 URI、一連のアサーションファクトリ、および一連のフィルターが含まれます。アサーションが true の場合、要求された URL は構成されたルートと一致します。

2. 述語

アサート機能により、開発者が定義するマッチHTTPリクエストでリクエストヘッダーやパラメータなどの情報。。

3. フィルター

フィルタはゲートウェイフィルタとグローバルフィルタに分かれます。フィルターはリクエストとレスポンスを処理できます。

ゲートウェイクイックスタート

1. 依存関係を導入する

注: spring-webmvc の依存関係と競合するため、spring-webmvc を除外する必要があります。

2. yml設定ファイルを書く

サーバー.ポート = 8088 は ゲートウェイアクセスポート

spring.application.name は 現在のゲートウェイサービスのサービス名

ルーティングルールは、gateway.routes の下で定義されます。

id はこのルーティングルールの名前です。gateway.routes の下には多数のルーティングルールが存在する可能性があります。

URL: 現在のゲートウェイのサービスにアクセスし、 どの URL に転送しますか?, まず、すべてのリクエストをゲートウェイに転送することはできません。述語アサーションがこの役割を果たす必要があります。

述語:いつ リクエストは現在のゲートウェイに到達します（それで このリクエストには、現在のゲートウェイの IP + ポート番号が含まれている必要があります。 情報の後にスラッシュ / が続くため、ゲートウェイはデフォルトでこの情報が利用可能であることを示すことができます。この情報は述語で考慮する必要はありません）， ポート番号以降のURLが/order-serv/**で始まる場合、それで 上記の URL の IP + ポートに転送するだけです 。そしてスラッシュ/後続のパスはすべて削除されません、その後、アドレス http://localhost:8020/order-serv/order/add に転送されます。

(order-serv は、注文サービスが /order/add で始まるアドレスを持ち、在庫サービスも /order/add で始まるアドレスを持つことを防ぐためのサービス名です。 ゲートウェイに送信されるリクエストには、転送されるサービスの名前が含まれます。）、しかし 注文サービスが受信したリクエストには /order-serv/ がありません。, 送信されたリクエストのみ http://localhost:8020/order/add なので受信できます。 ゲートウェイに最初のレイヤーのパスを削除させます、フィルターを通じてプレフィックスをフィルターします

アサーションが満たされない場合は、404 エラーが報告されます。

ここでは、転送される URL アドレスを構成にハードコーディングしています。サーバーが移行されると、IP アドレスが変更されたり、サーバーがクラスターにデプロイされたりするため、nginx を介して負荷分散を実行する必要があります。。

ゲートウェイとnacosを統合することで、これらの問題を簡単に解決できます

ナコスを統合する

1. nacos 依存関係の導入を続ける

2. yml 設定ファイルの書き込みを続けます。

(1) nacos を統合するには、現在のゲートウェイサービスを nacos に登録し、nacos サービスアドレスとアカウントパスワードを書き込むだけです。

(2) ルーティングルールで転送するサービスのアドレスをサービス名「order-service」(url:order-service)に変更します。また、nacos付属のリボンの負荷分散戦略を使用する必要があるため、したがって、前に lb:// を追加します。lb は、loadbalance ロードバランシングを意味します。

ゲートウェイゲートウェイは、「order-service」全体をいずれかの注文サービスの IP アドレスに置き換えます (ゲートウェイは nacos に登録されているさまざまなサービスの IP アドレスリストを定期的に取得するため)。

これにより、サーバーが移行される場合、IP アドレスが変更される場合、またはサーバーがクラスターに展開される場合に、リバースプロキシとロードバランシングに nginx を使用する必要があるという問題が解決されます。

省略されたルーティングルール: 合意は設定よりも重要です

(1) nacosサービスの自動識別機能をONにすると、アサーションルールを記述する必要がなくなりました。

(2) ゲートウェイに送信されたリクエストが nacos に登録されているサービス名で始まる場合、そのサービスのサーバーに自動的に転送され、第 1 層のパスは自動的に除外されます (デメリット: ルーティングルールが柔軟ではありません)十分）

このとき、ゲートウェイアドレス/マイクロサービス/インターフェースの形式に従ってアクセスすれば成功応答を得ることができます。

アサーションファクトリー

URL に基づいてアサーションを行うことは、ゲートウェイの組み込みアサーションファクトリです。

カスタムルーティングアサーションファクトリ

ここでは、クエリリクエストパラメーターに基づいてアサーションファクトリをカスタマイズし、ソースコードの内容をコピーして、必要に応じて変更することを前提としています。

カスタマイズ クエリリクエストパラメータに基づくアサーションファクトリー、 AbstractRoutePredicateFactory クラスを継承し、apply メソッドのロジックを書き直す必要があります。 apply メソッドでは、exchange.getRequest() を通じて ServerHttpRequest オブジェクトを取得することで、リクエストパラメーター、リクエストメソッド、リクエストヘッダーなどの情報を取得できます。

1. Spring コンポーネント、つまり Bean である必要があります。

2. クラスを追加する必要がありますルート述語ファクトリ終わりとして

3. 継承する必要がある抽象ルート述語ファクトリ

4. 静的内部クラスを宣言し、構成ファイルで対応するアサーション情報を受け取る属性を宣言する必要があります。

5. 組み合わせる必要があるショートカットフィールド順序練る

6. apply を使用して、true が一致に成功したか、false が一致に失敗したかを論理的に判断します。

フィルター (最初にフィルターしてからルーティング)

(1) まずリクエストされた URL アドレスをフィルターで処理するか、リクエストヘッダーや Cookie などの一部の情報を追加、削除、変更します。

(2) 次に、nacos サービスリストを通じて対応するサーバーにルーティングします。

フィルターの役割: リクエストがゲートウェイに到着すると、ビジネスロジックでリクエストを処理できます。

例えば：

(1)フィルターを正面に通しますパスの最初の層を削除します

(2) ゲートウェイに送信されるすべてのリクエストにリクエストヘッダーを追加し、その中にコンテンツを設定できます。

(3) ゲートウェイなどに来るすべてのリクエストにCookieを設定できます。

内蔵フィルターの詳細については、公式ウェブサイトをご覧ください。

ゲートウェイフィルタファクトリー

いくつかのコード例を次に示します。

テストアドレスがゲートウェイゲートウェイに送信されます

ルートを介して次の @GetMapping アドレスにルーティングし、次のコードを使用してリクエストを受信して応答します。

例1:

例 2

例 3

以前の URL アドレスはゲートウェイに送信され、フィルタリングされ、プレフィックス /mall-order が付けられます。このとき、サーバーが応答を受信できるようにするには、送信されるすべてのリクエストに /mall-order が含まれるように設定する必要があります。このようにして、サーバーは通常、ゲートウェイによってルーティングされたリクエストを受信できます。

例 4