4

将来のプロジェクトのベスト プラクティスといくつかのパターンを見つけるために、Kubernetes を使用してサンプル マイクロサービス アプリケーションを構築しています。サービス メッシュとして Istio を使用して East-West トラフィックを処理しており、概念 (VirtualServices、DestinationRules など) について基本的な理解があります。サービス メッシュを使用すると、マイクロサービスの新しいバージョンを簡単にプッシュして、トラフィックを新しいインスタンスにリダイレクトできます (重み付けされた分散などを使用)。セマンティック バージョニングを念頭に置いている場合、理論的には既存のコントラクトを変更していないため、既存のサービスのドロップイン置換になる可能性があるため、これはPatchおよび更新に非常に適しています。Minor現在、サービスの破壊的な変更に適切に対処する方法を考えているので、Majorバージョンの更新です。

これに関する情報を見つけるのは難しいですが、入手した情報が限られているため、現在 2 つのアプローチについて考えています。

  1. サービスの各メジャー バージョン ( などuser-service) は独自のものを取得するVirtualServiceため、クライアントは ( などの異なるサービス名でuser-service-v1) 正しくアドレス指定できます。次に、Istio を使用して、メジャー バージョン( など1.*)のトラフィックをさまざまな利用可能なサービス(user-service v1.3.1および などuser-service v1.4.0)に正しくルーティングします。

  2. VirtualService私は特定のマイクロサービスのために全体的に1つを使用しています(例えばuser-service)。これには、要求を宛先に一致VirtualServiceさせるためにクライアントから送信されたヘッダー (例: ) などを使用するための多くのルーティング定義が含まれています。x-major-version=1

全体として、両方の方法に大きな違いはありません。クライアントは明らかに、ヘッダーを設定するか、別のサービス名を解決することによって、対話したいメジャー バージョンを指定する必要があります。一方を他方よりも優れたものにする説明された方法に制限はありますか? または、私が完全に見逃している他のオプションはありますか? どんな助けや指針も大歓迎です!

4

1 に答える 1