Springboot：2.1.6.RELEASE
SpringCloud：Greenwich.SR1
特別な指示がない場合、この一連のチュートリアルはすべて
、上記のバージョンの前の2つの記事を使用します。SpringCloud Config構成センターについて説明しました。githubで構成を更新するときに、最新の構成を取得するには、手動で更新するか、Webhookを使用する必要があります。クライアントを更新するリクエストを送信するたびにコードを送信するメカニズム。クライアントをどんどん増やして、各クライアントを再度実行する必要があります。このソリューションは適していません。Spring Cloud Busを使用すると（中国の人々はメッセージバスに非常に鮮やかに翻訳されます。メッセージバスと呼びます）、この問題を完全に解決できます。
- Spring Cloud Bus
Springクラウドバスは、軽量のメッセージブローカーを介してさまざまな分散ノードを接続します。これは、ブロードキャストの状態変更（構成の変更など）またはその他のメッセージ指示に使用されます。Springバスの中心的なアイデアは、分散型スターターを介してSpring Bootアプリケーションを拡張することです。また、複数のアプリケーション間の通信チャネルを確立するために使用することもできます。現在、これを実現する唯一の方法は、AMQPメッセージブローカーをチャネルとして使用することです。同じ機能の設定（一部はチャネル設定に依存します）は、より多くのチャネルのドキュメントに記載されています。
これは、すべての分散プロジェクトでのメッセージの管理と配布として理解できます。実際の本質は、MQブロードキャストメカニズムを使用して分散システムでメッセージを拡散することです。現在、KafkaとRabbitMQが一般的に使用されています。バスメカニズムを使用すると、さまざまなことができます。その中でも、Configuration Centerクライアントの更新は、典型的なアプリケーションシナリオの1つです。画像を使用して、Configuration Centerでバスが使用するメカニズムを説明します。
この図によると、構成の更新にSpring Cloud Busを使用する手順を確認できます。
送信コード
は、クライアントAにバス/リフレッシュを送信するポストをトリガーします。クライアントAは、サーバーから構成を更新するリクエストを受信して、Spring Cloud Busに送信します
。SpringCloudバスはメッセージを受信し、他のクライアントに通知します。
他のクライアントは通知を受信してサーバーにリクエストします。
すべてのクライアントから最新の構成を取得する
- プロジェクトの例
前の記事のconfig-serverおよびconfig-clientを使用して変換し、mqは例としてrabbitmqを使用します。
2.1クライアントのconfig-client
2.1.1依存関係を追加
<dependency>
<groupId> org.springframework.cloud </ groupId>
<artifactId> spring-cloud-starter-bus-amqp </ ArtifactId>
</ Dependency>
コードをコピーする必要がありますspring-cloud-starter-bus-amqpパッケージを導入し、メッセージバスのサポートを追加します
2.1.2構成ファイルbootstrap.properties
spring.application.name = spring-cloud-config-client
server.port = 8081
spring.cloud.config.name = springcloud-config
spring.cloud.config.profile = dev
spring.cloud.config.label = master
spring.cloud.config.discovery.enabled = true
spring.cloud.config.discovery.serviceId =春のクラウド構成サーバー
eureka.client.service-url.defaultZone = http：// localhost：8761 / eureka /
management.endpoints.web.exposure.include = *
メッセージ追跡をオンにする
spring.cloud.bus.trace.enabled = true
spring.rabbitmq.host = 127.0.0.1
spring.rabbitmq.port = 5672
spring.rabbitmq.username =
spring.rabbitmq.password =
コピーコード構成ファイルでは、RebbitMq関連の構成を増やす必要があるため、クライアントコードが完成します。
2.1.3テストで
は、eureka、config-serve、config-clientを順に開始します。
config-clientスタートアップコンフィギュレーションを変更し、ポート8081および8082でサービスを開始します。
起動が完了すると、ブラウザはそれぞれ接続にアクセスします：http：// localhost：8081 / hello、http：// localhost：8082 / hello、ページに表示されるコンテンツは次のとおりです：hello dev update1クライアントが読み取ったことを示しますサーバー側のコンテンツに。
次に、Githubの構成ファイルを更新し、構成の内容をhello dev updateに変更します。最初にhttp：// localhost：8081 / helloにアクセスします。ページにはまだhello dev update1が表示されていることがわかります。
/アクチュエータ/バスリフレッシュのPOSTリクエストをポート8081のサービスに送信します。win10では、次のコマンドを使用してWebhookをシミュレートします。
curl -X POST http：// localhost：8081 /アクチュエータ/バスリフレッシュ
コードをコピーします注：springboot2.xバージョンでは、更新パスは次のとおりです：/アクチュエータ/バスリフレッシュ、springboot1.5.xバージョンでは、更新パスは/バス/更新です。
実行が完了したら、最初にhttp：// localhost：8082 / helloにアクセスします。ページ印刷コンテンツが次のようになっていることがわかります：hello dev update、これはポート8081のサービスが更新された情報をrabbitmqにプッシュしたことを示しています8082ポートサービスなので、図1の例を実現しました。
2.2
上記の改良バージョンのプロセスでは、メッセージバスを使用して更新をトリガーし、すべてのクライアント構成を更新する目的を達成しましたが、この方法は次のように適切ではありません。
マイクロサービスの単一の責任を破る。マイクロサービス自体はビジネスモジュールであり、構成更新の責任を負うべきではありません。
マイクロサービスノードの同等物が破壊されます。
クライアントIPが変更された場合、WebHook構成を変更する必要があります。
上記のプロセスを改善できます
現時点では、Spring Cloud Busの構成更新手順は次のとおりです。
コードを送信して、バスへの送信/
サーバーの更新をトリガーするコードを送信します。サーバーは要求を受信してSpring Cloud Busに送信します
。SpringCloudバスはメッセージを受信して他のクライアントに通知します。
他のクライアントは通知を受信し、サーバーに最新の構成を取得するよう要求します。
すべてのクライアント最新の構成を取得する
この場合、サーバー側のコードにいくつかの変更を加えて、/アクチュエータ/バスリフレッシュをサポートし
、上記のクライアント側の変更は基本的に同じです
2.2.1依存関係の追加
<dependency>
<groupId> org.springframework.cloud </ groupId>
<artifactId> spring-cloud-starter-bus-amqp </ ArtifactId>
</ Dependency>
メッセージバスのサポートを増やすには、より多くのspring-cloud-starter-bus-amqpパッケージを導入する必要があります
2.2.2設定ファイルapplication.yml
server：
port：8080
spring：
application：
name：spring-cloud-config-server
cloud：
config：
server：
git：
uri：https : //github.com/meteor1993/SpringCloudLearning
search-paths：chapter6 / springcloud-config
username：
パスワード：
rabbitmq：
ホスト：217.0.0。1
ポート：5672
ユーザー名：
パスワード：
管理：
エンドポイント：
web：
公開：
含む： "*"
eureka：
クライアント：
service-url：
defaultZone：http：// localhost：8761 / eureka /
構成ファイルはRebbitMq関連の構成を追加する必要があり、アクチュエーターはすべてのアクセスを開きます。
2.2.3テストで
は、eureka、config-serve、config-clientを順に開始します。
config-clientスタートアップコンフィギュレーションを変更し、ポート8081および8082でサービスを開始します。
上記のテスト方法によると、両方のクライアントテストへのアクセスは情報を正しく返すことができます。また、構成ファイルを変更し、値をhello im dev updateに変更して、ウェアハウスに送信します。次のコマンドを使用して、win10でwebhookをシミュレートします。
curl -X POST http：// localhost：8081 /アクチュエータ/バスリフレッシュ
コピーコードの実行が完了したら、2つのクライアントに順番にアクセスして、hello im dev updateを返します。これは、3つのクライアントが最新の構成ファイルの情報を取得したことを意味し、上図の例を実現しています。