マイクロサービスの目標は、個別にデプロイできる小さい自律的なサービスにアプリケーションを分解して、アプリケーションのリリース速度を上げることです。 マイクロサービス アーキテクチャには、いくつかの課題もあります。 ここに示す設計パターンは、それらの課題の緩和に役立ちます。
アンバサダーは、監視、ログ記録、ルーティング、セキュリティ (TLS など) といった一般的なクライアント接続のタスクを言語に関係ない方法でオフロードするのに役立ちます。 アンバサダー サービスは多くの場合、サイドカー (下記参照) としてデプロイされます。
破損対策レイヤーは、新しいアプリケーションの設計がレガシ システムへの依存によって確実に制限されないようにするため、新しいアプリケーションとレガシ アプリケーションの間にファサードを実装します。
フロントエンド用バックエンドは、デスクトップやモバイルなど、クライアントのさまざまな種類に応じて独立したバックエンド サービスを作成します。 そうすれば、さまざまな種類のクライアントの競合する要件を単一のバックエンド サービスで処理する必要がありません。 このパターンを使用すると、クライアント固有の問題を切り離すことによって、各マイクロサービスのシンプルさを維持できます。
バルクヘッドは、接続プール、メモリ、CPU などの重要なリソースをワークロードまたはサービスごとに独立させます。 バルクヘッドを使用すると、単一のワークロード (またはサービス) がすべてのリソースを消費して他のワークロードのリソースが枯渇することがなくなります。 このパターンでは、1 つのサービスによって発生した障害の連鎖を防ぐことによって、システムの回復性が向上します。
ゲートウェイ集約では、複数の個々のマイクロサービスへの要求を単一の要求に集約し、コンシューマーとサービスの間のトラフィックを削減します。
ゲートウェイ オフロードでは、SSL 証明書の使用などの共有サービス機能を各マイクロサービスから API ゲートウェイにオフロードすることができます。
ゲートウェイ ルーティングでは、単一のエンドポイントを使用して要求を複数のマイクロサービスにルーティングします。これにより、コンシューマーは多数の個別エンドポイントを管理する必要がありません。
メッセージング ブリッジは、異なるメッセージング インフラストラクチャで構築されたまったく別のシステムを統合します。
サイドカーでは、アプリケーションのヘルパー コンポーネントを別のコンテナーまたはプロセスとしてデプロイし、分離性とカプセル化を実現します。
ストラングラー フィグは、機能の特定の部分を新しいサービスに徐々に置き換えることで、アプリケーションの段階的なリファクタリングをサポートします。
Azure アーキテクチャ センターでクラウド設計パターンの完全なカタログを見るには、クラウド設計パターンに関するページを参照してください。
次のステップ
- トレーニング: モノリシック アプリケーションをマイクロサービス アーキテクチャに分解する
- マイクロサービスとは
- マイクロサービスの手法を使用してアプリケーションを構築する理由は何ですか
- マイクロサービス アーキテクチャ