回答。

サービスメッシュアーキテクチャは、特定のインフラ層を介してマイクロサービス間の複雑な相互作用を管理するために設計されています。サービスメッシュは、自動的にルーティング、負荷分散、サービスの発見、安全性（例：mTLS）、ログ記録、トラッキング、リトライの要求などの機能を提供し、それらを各サービスに実装する必要なく実現します。これはすべて、各マイクロサービスの近くで実行され、全てのネットワークトラフィックを傍受する特別なプロキシ（サイドカー）によって達成されます。

従来のマイクロサービスアーキテクチャでは、これらの機能の大部分をサービス内部またはプラットフォームレベルで実装する必要があり、多くのサービスが存在する場合、プロジェクトの開発と保守が難しくなります。

Kubernetes用のIstioサービスメッシュ設定のコード例:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-service
spec:
  hosts:
    - my-service
  http:
    - route:
        - destination:
            host: my-service
            subset: v1

主な特徴:

• ネットワーク相互作用のルーティングとポリシー管理の集中化。

• 各サービスの相互作用ロジックのコード重複の最小化。

• アプリケーションのビジネスロジックを変更することなく、安全性とモニタリングの向上。

トリビアの質問。

サービスメッシュはAPIゲートウェイを完全に置き換えるのですか？

いいえ、サービスメッシュとAPIゲートウェイは相補的な関係にあります。APIゲートウェイは入口制御を提供し、サービスメッシュはサービス間のeast-west通信を管理します。

サービスメッシュを導入する際にサービスのコードを修正する必要がありますか？

通常は必要ありません。多くの場合、サービスポロキシはサイドカーとして実行され、ビジネスロジックのコードを変更する必要はありません。

サービスメッシュはマイクロサービスのパフォーマンスを悪化させますか？

サービスメッシュは確かにプロキシのトラフィック処理のためにわずかな遅延をもたらしますが、ほとんどのシナリオでは、管理性と信頼性の向上と比べてそれは無視できる程度です。