私はSpring Cloud Configurationで遊んでいます。ソリューションのシンプルさと、デフォルトの構成ストアとして git を使用するという事実が気に入っています。
一元化された構成管理のソリューションとしてプッシュする前に、把握する必要がある 2 つの側面があります。側面は次のとおりです。
高可用性
構成の変更を段階的にロールアウトする方法 (カナリア リリースをサポートするため)
これをデータセンターにすでに実装している場合、または単に試している場合は、アイデアを共有してください! また、単一/クロス データセンター環境で推奨される展開をどのように考えているか、作成者から聞きたいです。
1404 次
1 に答える
5
構成サーバー自体はステートレスであるため、これらを必要な数だけスピンアップして、eureka 経由で見つけることができます。サーバー自体の下で、指し示す git 実装も高可用性である必要があります。したがって、github (プライベートまたはパブリック) を指定すると、git は github と同じように利用できます。構成サーバーが git に到達できない場合、たとえそれが古くても、チェックアウトしたものを提供し続けます。
段階的な構成の変更に関する限り、別のブランチを使用して、そのブランチを使用するようにカナリアを構成し、ブランチをspring.cloud.config.labelマージすることができます。プロファイル (例: application-<profilename>.properties) を使用して、指定したプロファイルを使用するようにカナリアを構成することもできます。
カナリア以外のノードを毎回新しいプロファイルを使用するように再構成する必要はなく、ブランチを使用するようにカナリアを構成するだけなので、ブランチはもう少し理にかなっていると思います。
いずれにせよ、アプリが構成の変更を確認するのは (Spring Cloud 構成クライアントを使用している場合)、起動時または各ノードで行うときだけPOSTです/refresh。Spring Cloud Bus を使用して、サービスのすべてのインスタンスを一度に更新するPOSTこともできます。/bus/refresh?destination=<servicename>
于 2014-12-01T18:14:56.273 に答える