領事Cluster Serverの+クライアントモード
アーキテクチャ図
次の二つの質問の唯一の領事を使用してサーバーモード：
- 数コンサルサーバーがそのように制御されるので、受圧（スケーラビリティ）が問題です。
- サーバーめったにServerノードマイクロサービスの下で登録されたサーバーハング、無効と見なされると、次のサーバーは、マイクロサービスの多くを登録しますつながりません。
私たちは、使用WANを担当するサーバーモード、アーキテクチャ領事クライアントモードでは上記の問題を追加し、クライアントによるそのネットワーク（高速ローカル・エリア・ネットワーク）の追加LANのゴシッププロトコルには、サーバーノードの障害を識別することができますし、実際には、作業を続ける可能なサーバノードを見つけますクロスWAN同期からなるゴシッププロトコル・データ・ネットワーク（複数のデータセンター）、これは不可能Clientモードで、クライアント・モードはまた、登録および照会サービスを提供するが、クライアント・モード・ノード・データが格納されていない、クライアントが要求を転送処理のためにサーバに、サーバ側の登録データノードが永続的に保存され、数は、クライアントの無制限の数、サーバ量を制御することができます。要するに：クライアントモード+ LANのゴシップ契約は各ノードにデータセンターを構成し、リーダーのデータセンターの同期における投票データを担当するサーバーは、リーダーはまた、WANの同期を介して他のデータセンターWANのゴシッププロトコルで使用するために責任があります。
PS：クライアントの責任をチェックするために、ハートビートモニターに登録クライアントサービス。
内蔵環境
名前から注意を払っていないので（bluersw /春-クラウド領事-消費者は、春・クラウド・領事・クライアントを実行している内部のミラーと呼ばれる消費者向けサービスプログラムプロジェクトですドッカーミラーを取得し、混乱につながった、春・クラウド・領事、クライアントない領事クライアント）：
docker pull consul
docker pull bluersw/spring-cloud-consul-consumer:cc
docker pull bluersw/spring-cloud-provider:cc
docker pull bluersw/spring-cloud-provider:cc
docker pull bluersw/spring-cloud-provider-second:cc（：-client =「0.0.0.0」IPアドレスパラメータは、例えば、「IPアドレス」を使用するWindowsドッカーのバージョンを実行するためのコマンド）領事Serverを起動します。
docker run -i -t -p 8500:8500 --name=ConsulServer-C consul agent -server -ui -node=Server-C -bootstrap-expect=3 -client=0.0.0.0
docker run -i -t -p 8501:8500 --name=ConsulServer-A consul agent -server -ui -node=Server-A -bootstrap-expect=3 -client=0.0.0.0 -join=172.17.0.2
docker run -i -t -p 8502:8500 --name=ConsulServer-B consul agent -server -ui -node=Server-B -bootstrap-expect=3 -client=0.0.0.0 -join=172.17.0.2
春・クラウド・プロバイダーを起動します。
docker run --name=spring-cloud-provider -d -p 9001:9001 bluersw/spring-cloud-provider:cc /opt/consul/./consul agent -data-dir=/opt/consul/data -config-dir=/opt/consul/config -node=privider-cc -join 172.17.0.3実行と同時に、ドッカーの領事クライアントモードを起動し、領事サーバA（領事サーバーを追加することができます）に入社、CCのイメージファイルへのTAGはすでに領事プログラムが含まれています。
春・クラウド・プロバイダーの構成ファイルの内容：
spring.application.name=spring-cloud-provider-01
server.port=9001
spring.cloud.consul.host=127.0.0.1
spring.cloud.consul.port=8500
#注册到consul的服务名称
spring.cloud.consul.discovery.serviceName=service-provider
#以下两项如果不配置健康检查一定失败
spring.cloud.consul.discovery.prefer-ip-address=true
spring.cloud.consul.discovery.health-check-path=/actuator/health設定登録されたサービスのアドレスは、他のサービスの設定ファイルは本機に登録領事クライアントを変更して、127.0.0.1に変更されました。
サービスを開始します。
docker exec spring-cloud-provider /usr/local/java/bin/java -jar /opt/spring-cloud-provider-0.0.1-SNAPSHOT.jarサービスプロバイダーサービスprivider-CCノードが正常に登録されています。
同じように、ばねのクラウド・プロバイダー秒と春-クラウド領事消費者を起動します。
docker run --name=spring-cloud-provider-second -d -p 9002:9002 bluersw/spring-cloud-provider-second:cc /opt/consul/./consul agent -data-dir=/opt/consul/data -config-dir=/opt/consul/config -node=provider-second-cc -join 172.17.0.4
docker exec spring-cloud-provider-second /usr/local/java/bin/java -jar /opt/spring-cloud-provider-second-0.0.1-SNAPSHOT.jar
docker run --name=spring-cloud-consul-consumer -d -p 9003:9003 bluersw/spring-cloud-consul-consumer:cc /opt/consul/./consul agent -data-dir=/opt/consul/data -config-dir=/opt/consul/config -node=consumer-cc -join 172.17.0.2
docker exec spring-cloud-consul-consumer /usr/local/java/bin/java -jar /opt/spring-cloud-consul-client-0.0.1-SNAPSHOT.jar
シミュレーションサーバ障害
閉じる領事サーバーB：
クライアントまたはサービス自体とがハングアップした場合、サービスプロバイダーは、マシンの領事クライアントに登録され、クライアントが使用可能なサーバーを見つけるために、LANのゴシッププロトコルを使用することができ、とても近く領事サーバーBは影響しないため、これはサーバーを終了しますノードや故障のサービスマーク、もはや使用中は、依頼者は、この要求ノードの障害を満たしていない、とすべて同じサービスの後、これまで障害が発生したノードの機能回復を修復します。
ソース
Githubのリポジトリます。https：//github.com/sunweisheng/spring-cloud-example