このパターンには2つの背景があります。ひとつは、技術者がマイクロサービスアーキテクチャパターンを採用して、複数の(理想的には単一目的で、独立してデプロイ可能な)サービスで構成されるアプリケーションを開発するようになったことです。ふたつめは、企業がコンテナ(Dockerなど)、オーケストレータ(Kubernetesなど)、プロキシ/ゲートウェイ(Envoyなど)といった、クラウドネイティブなプラットフォームテクノロジを支持するようになったことです。 意図 サービスメッシュが解決しようとする問題は次のようなものです。 サービスディスカバリ、ルーティング、アプリケーションレベル(レイヤ7)の非機能通信要件を処理する言語対応の通信ライブラリを、個々のサービス用にコンパイルする必要性の排除 外部サービスのネットワークロケーション、セキュリティ認証、サービス品質(QoS)目標など、サービス通信設定の外
![サービスメッシュ必読ガイド - マイクロサービス時代のサービス間通信管理](https://cdn-ak-scissors.b.st-hatena.com/image/square/f146f126365fc4420f3904aacaae30ddf25b385c/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2Fres.infoq.com%2Farticles%2Fservice-mesh-ultimate-guide%2Fja%2Fsmallimage%2FService-Mesh-pillar-page-logo-1581414272136.jpg)