Sidecar Pattern

最新のクラウドネイティブ システムでは、マイクロサービスはビジネス ロジックを実行する以上のことを行うことが期待されています。ログの処理、SSL/TLS 証明書の管理、メトリクスの収集、再試行メカニズムの実装、および他のサービスとの安全な通信の調整を行う必要があります。 この横断的な機能をすべて各アプリケーションのコードベース内に直接埋め込むと、コードの肥大化、密結合、言語のロックインが発生します。 ここで、サイドカー パターンが登場します。このガイドでは、サイドカー パターンとは何か、それが最新のマイクロサービス アーキテクチャに不可欠である理由、および簡単な例えと Kubernetes 構成例を使用してそれがどのように機能するかを詳しく説明します。 現実世界の例え: オートバイのサイドカー このパターンを理解する最も簡単な方法は、サイドカー付きのオートバイを考えることです。 あなたが高性能のオートバイを持っていると想像してください。この車両は、1 人のライダーを迅速に輸送するという 1 つのことを非常にうまく実行するように設計されています。ここで、乗客の手荷物を運ぶ必要があるか、追加の座席を追加する必要があるとします。 オートバイのフレーム、エンジン、ホイールを完全に再設計して車に変えることができます。しかし、それには多大な労力が必要で、バイクのシンプルさが損なわれ、メンテナンスが難しくなります。 代わりに、サイドカーを接続します。 サイドカーは、オートバイに接続する独立した自己完結型ユニットです。バイクの移動を共有し、バイクの行くところならどこへでも移動し、緊密に連携して動作します。しかし、オートバイの核となるエンジンは手つかずのままです。 ソフトウェア アーキテクチャでは: Motorcycle は、主要なアプリケーション コンテナです (チェックアウトやユーザー認証などのコア ビジネス ロジックを実行します)。 サイドカーは、別個のヘルパー コンテナーです (SSL 終了、監視、ログ配布などのユーティリティ タスクを実行します)。 ジャーニー は、デプロイメント (Kubernetes ポッドなど) のライフサイクルです。 問題: 分野横断的な懸念とコードの肥大化 サイドカーが登場する前は、開発者はアプリケーション コードにヘルパー ライブラリを直接組み込む必要がありました。たとえば、ログを中央サーバーに送信する場合は、ログ ライブラリをインポートします。メトリクスが必要な場合は、メトリクス SDK を追加しました。