マイクロサービスの上に API ゲートウェイを使用することを検討しています。しかし、明確な答えを持っていないアーキテクチャ上の質問がいくつかあるので、コミュニティから意見を求めたいと思います。また、良い習慣と悪い習慣についてのアイデアを共有していただければ幸いです。この質問投稿を読みやすくするために、「質問」と「詳細」の 2 つの主要なセクションがあります。

質問

Api ゲートウェイは承認と要求の変換を担当する必要がありますか?

問題は主に、ゲートウェイとは何かということです。これは、API ユーザーとマイクロサービスの間の橋渡しにすぎません。それともマイクロサービスのモデレーターですか？詳細については、「戦略を実装するゲートウェイ」セクションを参照してください。

Amazon API Gateway を使用する場合、ラムダ関数の追加レイヤーを使用してリクエストの変換と承認を行うことは良い方法ですか?

Amazon API Gateway を使用することを選択した場合、前の質問に対する答えは、「ゲートウェイはマイクロサービスのモデレーターとして機能する必要があります」です。Amazon ラムダを介してリクエスト/レスポンスの変換と承認を処理する必要があるため、ゲートウェイの下に別のレイヤーが必要になります。質問は、この種のアーキテクチャを使用することは適切な方法でしょうか?

詳細

テクノロジー

• スプリング ブート 2.0
• JWT
• Spring クラウド ゲートウェイまたはAmazon Api ゲートウェイ(回答に応じて)

サービス

システムには次のマイクロサービスがあります

サービスA

エンドポイント GET /api/resources/{dataId}/admin-endpoint

ヘッダー - 承認: ベアラー トークン

このエンドポイントには、ADMIN ロールを持つユーザーのみがアクセスできます (そのロールを持たないユーザーからの要求の場合、403 http ステータスが応答と共に返されます)。

リクエストを処理する前に、AuthService によってトークンを検証する必要があることに注意してください。そして、リクエストを処理した後 (HTTP ステータスがエラーでない場合)、AuthService によってトークンを更新する必要があります (応答には更新されたトークンが含まれている必要があります)。

エンドポイント GET /api/resources/{dataId}/user-endpoint

ヘッダー - 承認: ベアラー トークン

このエンドポイントは、任意のロールを持つユーザーがアクセスできます

認証サービス

エンドポイント POST /api/auth/login

ヘッダー - 承認: ベアラー トークン

本文 - {「ユーザー名」: 文字列、「パスワード」: 文字列}

ユーザーを認証します: 成功した場合、署名された認証トークンが応答のヘッダー (ベアラー JWT トークン) として返されます。認証に失敗した場合は 401 http ステータスが返されます

エンドポイント POST /api/auth/logout

ヘッダー - 承認: ベアラー トークン

ユーザーが特定のトークンで保護された API にアクセスできないように、(適切なテーブルにトークンを格納することによって) 承認トークンを無効にします。

エンドポイント GET /api/auth/validate

ヘッダー - 承認: ベアラー トークン

指定されたトークンを検証します (ServiceA で要求を処理する前に呼び出す必要があります。検証チェックについては、付録 A を参照してください

応答本文 - {"role" : , "username" : String}

ゲートウェイ実装戦略

ゲートウェイはルーティングのみを担当

この戦略では、ServiceA と AuthService がゲートウェイにルートとして登録され、リクエストを処理する前に追加のリクエスト変換が行われることはありません。

ServiceA は、承認とトークンの検証のために AuthServer と直接対話します。

長所

• ゲートウェイのロジックは非常に単純です
• ゲートウェイとして、さまざまなフレームワークとツールを選択できます。

短所

• ServiceA と AuthService は強く結合されています
• ServiceB を追加する必要がある場合は、ServiceB と ServiceA の間の通信を確立するために何らかの二重の作業を行う必要があります。
• AuthService での失敗の処理は、ほとんど ServiceA によって行われます。

ゲートウェイは承認とリクエストの変換を担当します

この戦略では、リクエストを ServiceA に渡す前に、api-gateway が AuthServer でトークンの検証を処理します。また、ServiceA がエラー以外の応答を返す場合、トークンの更新も処理します。

長所

• ServiceA は AuthService から完全に切り離されています
• 別の ServiceB を追加する方がはるかに簡単です
• AuthService の失敗はゲートウェイによって処理されます

短所

• ゲートウェイは、マイクロサービスの橋渡しをするだけではなく、より多くの責任を負うことになります
• Amazon Api Gateway は、Amazon ラムダを使用した承認と変換の処理が非常に苦痛になる可能性があるため、おそらく適切な選択ではありません (おそらく私が間違っている可能性があります)。

付録 A: JWT トークンの検証チェック

• トークンには有効なベアラー プレフィックスがあります: "bearer "
• トークンの有効期限が切れていない (トークンには createdAt 属性があり、トークンが 10 分より古いかどうかを判断するために使用されます)
• ユーザーが存在します: トークンの作成後にユーザーが削除されていません (トークンには、ユーザーの一意の識別子を保持するサブジェクト属性があります)
• トークンの有効期間中にユーザー パスワードが変更されていない

Spring Cloud ゲートウェイ 2 スターターで netty-tcnative を使用して SSL/TLS パフォーマンスを向上させることは可能ですか? 私は検索ドキュメントと Google を持っていますが、運が悪いです。

複数の場所で説明されているように、uber jar の追加をテストしました。ここ https://github.com/reactor/reactor-netty/issues/344しかし、それが使用されていることを示すものは何も見られません。

netty docs には、SSL コンテキストの手動セットアップが必要な例が示されているため、さらに多くのことがあると考えています。Spring Cloud Gateway でこれに使用できる Auto-Config のレベルに応じて。

基本的なベンチマーク (非常にローテクを使用ab) も行いましたが、パフォーマンスにも違いは見られません。