HTTP ヘッダールーティングパターン

ヘッダーベースのルーティングでは、HTTP リクエストの HTTP ヘッダーを指定することで、リクエストごとに正しいサービスをターゲットにすることができます。例えば、ヘッダー x-service-a-action: get-thing を送信すると、Service A からの get thing が可能になります。リクエストのパスは、作業しようとしているリソースのガイダンスを提供するため依然として重要です。

HTTP ヘッダールーティングをアクションに使用するだけでなく、バージョンルーティングのメカニズムとしても使用できるため、機能フラグや A/B テストなどのニーズに対応できます。実際には、ヘッダールーティングを他のルーティング方式のいずれかと併用して、堅牢な API を作成する可能性が高くなります。

HTTP ヘッダールーティングのアーキテクチャでは通常、次の図に示すように、正しいサービスにルーティングして応答を返すマイクロサービスの前に薄いルーティング層が存在します。このルーティング層は、すべてのサービスを対象とすることも、バージョンベースのルーティングなどの操作を可能にする一部のサービスだけを対象とすることもできます。

メリット

設定変更の労力は最小限で済み、簡単に自動化できます。この方式は柔軟性も高く、サービスに求める特定の操作だけを公開するクリエイティブな方法をサポートしています。

デメリット

ホスト名ルーティング方式と同様に、HTTP ヘッダールーティングでは、ユーザーがクライアントを完全に制御でき、カスタム HTTP ヘッダーを操作できることを前提としています。プロキシ、コンテンツ配信ネットワーク (CDN)、およびロードバランサーによって、ヘッダーサイズが制限される場合があります。これが問題になる可能性は低いですが、追加するヘッダーと Cookie の数によっては問題になる可能性があります。