将来のプロジェクトのベスト プラクティスといくつかのパターンを見つけるために、Kubernetes を使用してサンプル マイクロサービス アプリケーションを構築しています。サービス メッシュとして Istio を使用して East-West トラフィックを処理しており、概念 (VirtualServices、DestinationRules など) について基本的な理解があります。サービス メッシュを使用すると、マイクロサービスの新しいバージョンを簡単にプッシュして、トラフィックを新しいインスタンスにリダイレクトできます (重み付けされた分散などを使用)。セマンティック バージョニングを念頭に置いている場合、理論的には既存のコントラクトを変更していないため、既存のサービスのドロップイン置換になる可能性があるため、これはPatch
および更新に非常に適しています。Minor
現在、サービスの破壊的な変更に適切に対処する方法を考えているので、Major
バージョンの更新です。
これに関する情報を見つけるのは難しいですが、入手した情報が限られているため、現在 2 つのアプローチについて考えています。
サービスの各メジャー バージョン ( など
user-service
) は独自のものを取得するVirtualService
ため、クライアントは ( などの異なるサービス名でuser-service-v1
) 正しくアドレス指定できます。次に、Istio を使用して、メジャー バージョン( など1.*
)のトラフィックをさまざまな利用可能なサービス(user-service v1.3.1
および などuser-service v1.4.0
)に正しくルーティングします。VirtualService
私は特定のマイクロサービスのために全体的に1つを使用しています(例えばuser-service
)。これには、要求を宛先に一致VirtualService
させるためにクライアントから送信されたヘッダー (例: ) などを使用するための多くのルーティング定義が含まれています。x-major-version=1
全体として、両方の方法に大きな違いはありません。クライアントは明らかに、ヘッダーを設定するか、別のサービス名を解決することによって、対話したいメジャー バージョンを指定する必要があります。一方を他方よりも優れたものにする説明された方法に制限はありますか? または、私が完全に見逃している他のオプションはありますか? どんな助けや指針も大歓迎です!