SpringCloud (統合構成サービス)

従来のモノリシック アプリケーションでは、構成ファイルを使用してすべての構成を管理することがよくあります。 たとえば、springBoot によって開発された単一のアプリケーションは、構成コンテンツを application.yml ファイルに入れることができます。 環境を切り替える必要がある場合は、複数のプロファイルを設定し、アプリケーションの起動時に spring.profiles.active={profile} を指定できます。 ただし、マイクロサービス アーキテクチャでは、マイクロサービスの構成管理には一般に次の要件があります。

a) 集中管理構成。 マイクロサービス アーキテクチャを使用するアプリケーション システムには、数百または数千のマイクロサービスが含まれる場合があるため、構成の集中管理が非常に必要です。

(b) 異なる環境、異なる構成。 たとえば、データソースの構成は環境 (開発、テスト、ステージング、本番など) によって異なります。

(c) 動作中に動的に調整できます。 たとえば、各マイクロサービスの負荷に応じて、データ ソース接続プールのサイズまたは融合しきい値を動的に調整でき、構成を調整するときにマイクロサービスが停止することはありません。

(d) 変更後、構成を自動的に更新できます。 構成の内容が変更された場合、マイクロサービスは構成を自動的に更新できます。 要約すると、マイクロサービス アーキテクチャでは、共通の構成管理メカニズムが不可欠であり、構成サーバーを使用して構成を管理するのが一般的です。 スプリング クラウド バスは、Git や SVN などの管理構成を利用し、Kafka や RabbitMQ などのメッセージ バスを使用してすべてのアプリケーションに通知し、自動構成更新を実現し、すべてのマイクロサービス インスタンスの構成を更新します。