SpringBoot2.xは領事を統合し、実現の集中構成管理サービス（コンフィギュレーション・シェア）

まず、なぜあるべき領事

   

           この記事では、領事とユーレカ、etcd、ZKコントラストを議論していないWebインターフェイス、コンフィギュレーションおよびサービスの機能だけではアウトすることができて、単に領事自体から言えば、使いやすく簡単にインストールでき、それらを使用することは難しく、kのではありません/ Vキーダイナミックためのビルド構成、サーバー側のリアルタイム更新、および非常に使いやすいそれらを使用しています。

 

二、Windowsのスタンドアローンサービスの実行領事

 

（1）ダウンロード：https://pan.baidu.com/s/1P0qBS7Wg5cn-BUjN6ae5ag

              抽出コード：  wfyv 

 

（2）ダウンロードした後、解凍し、exeファイルを参照してください

 

 

（3）私たちは、cmdと入力し、領事エージェントは-dev  サービス、デフォルトのポート8500を開始します

 

 

 

どこへ行くか、ブラウザの（4）波、などのWebクライアントインタフェースのルックスを見て

 

 注：領事もサービス登録とディスカバリーセンターああ、このポストは、私たちはこの機能を持っていない、忘れてはいけません。

 

 

 

このキー/値は、後で私たちはKVのストレージ構成を組み合わせるということ（5）注、サービスが単一ノードを達成することができ、どのように単一ノードを達成するためのサービスセンター領事の動的な構成で構成されてお見せするために、クラスタが複数の単語ではありませんクラスタの下で異なるTomcatで複数のサービスを展開するが、コンフィギュレーション複数のサービスが、領事管理によって統一達成するために管理することである「マルチサービスノード構成の共有」であることであり、それが「手段どこにでも有効にするには、変更を設定します！」

 

 

 

 

三、SpringBoot-2.1.4.RELEASE統合領事

 

   注：コード倉庫、また、上記のBaiduのネットワークディスクアドレスをダウンロードすることができないので、あなたが直接クローン投影できる、windows64ビット領事を含み

 

（1）GitHubのプロジェクト住所：https://github.com/kobeyk/SpringBoot-Consul.git

 

 

 

（2）项目结构图，放出来，大家观望下

 

 

 

（3）重头配置文件bootstrap.properties放出来，配置说明已经很详细了，基本上没什么大问题

 

spring.application.name=spring-boot-consul-config
#================== consul 服务发现与注册中心配置 =======================#

# 指定consul的地址（如：http://consul.imgsky.com.cn）
spring.cloud.consul.host = 127.0.0.1
# 指定consul的端口 == 默认8500
spring.cloud.consul.port = 8500

#指定服务的实例id（唯一）
spring.cloud.consul.discovery.instance-id=${spring.application.name}-001
# 指定服务的 consul service name
spring.cloud.consul.discovery.service-name=consul-config
# 是否启用服务发现
spring.cloud.consul.discovery.enabled=true
# 是否启用服务注册
spring.cloud.consul.discovery.register=true
# 是否服务停止时s取消注册
spring.cloud.consul.discovery.deregister=true
# 在注册时使用 consul IP, 而不是 hostname
spring.cloud.consul.discovery.prefer-ip-address=true

# 健康检查url
spring.cloud.consul.discovery.health-check-url=http://localhost:8081/actuator/health
# 健康检查的频率, 默认 10 秒
spring.cloud.consul.discovery.health-check-interval=10s
# 健康检查失败多长时间后，取消注册
spring.cloud.consul.discovery.health-check-critical-timeout=5s

# 启用配置中心
spring.cloud.consul.config.enabled=true
# 表示consul上面文件的格式 有四种 YAML PROPERTIES KEY-VALUE FILES
spring.cloud.consul.config.format=properties
#表示consul上面的KEY值(或者说文件的名字) 默认是data
spring.cloud.consul.config.data-key=data
#prefix设置配置值的基本文件夹
spring.cloud.consul.config.prefix=config
# 表示如果没有发现配置，是否抛出异常，true为是，false为否，当为false时，consul会打印warn级别的日志信息
spring.cloud.consul.config.fail-fast=false
#defaultContext设置所有应用程序使用的文件夹名称，指定consul配置的配置文件父路径
spring.cloud.consul.config.defaultContext=consul-config
#profileSeparator设置用于使用配置文件在属性源中分隔配置文件名称的分隔符的值
spring.cloud.consul.config.profileSeparator=,

#================== consul 服务发现与注册中心配置 =======================#

 

 

（4）bootstrap.properties配置有几个需要注意的地方，见下图

 

 

（5） 启动SpringBoot项目

         万事俱备，只欠东风，consul服务我们已经启了，springboot项目我们也已经集成和配置主要的参数了，come on ,run server！

 

 

（6） web端查看

 

 

（7）至此，整个集成工作已经done.

 

 

 四、实现服务配置共享

 

（1）用postman测试配置是否生效

 

 

 

postman导出的测试JSON脚本：

 

{
	"info": {
		"_postman_id": "272f7dff-279c-4321-b60c-a06f9c958513",
		"name": "配置中心",
		"schema": "https://schema.getpostman.com/json/collection/v2.1.0/collection.json"
	},
	"item": [
		{
			"name": "服务状况",
			"request": {
				"method": "GET",
				"header": [],
				"url": {
					"raw": ""
				}
			},
			"response": []
		},
		{
			"name": "获取名称",
			"request": {
				"method": "GET",
				"header": [],
				"url": {
					"raw": "{{api}}/consul/config/getName",
					"host": [
						"{{api}}"
					],
					"path": [
						"consul",
						"config",
						"getName"
					]
				}
			},
			"response": []
		},
		{
			"name": "访问配置",
			"request": {
				"method": "GET",
				"header": [],
				"url": {
					"raw": ""
				}
			},
			"response": []
		}
	],
	"protocolProfileBehavior": {}
}

 

 

（2）web端新建一个key/value，如下：

 

 

 

 

 

 

"config/config-consul,dev/data"可不是随便乱建的，不信你看bootstrap.properties配置文件中的说明（上面也提到过）

 

 

（3）不知道有没有人发现，博主上面构建kv时并没有按照配置文件中的参数值一一对应，那我们就来一遍错误的示范吧

          把服务dev的值粘贴到value里，注意不要带注释，纯净版的配置，否则会报错

 

 

 

（4）come on ，我们改一下name的值，看下，服务端的配置是否也同步修改了

 

 

 

   保存后，我们接口调用下获取name的服务，看下值是否也变化了

 

 

 

 别着急，如果值发生变化了，consul会通知服务实例的，我们去后台看下，是不是可以发现什么蛛丝马迹

 

 

 

（5）错误排查

        上面我们说过了，我故意将web端的kv值和服务端的配置没有做到一一对应，目的就是为了演示这个如果不一致，会怎么样，好了，现在我们知道后果是什么了，那就是，没反应，不管用，行不通，好了，我们改回去，使web端的文件夹consul-config与服务端配置的对应上就好了。

 

 

 

改后的新kv如下（删除原来的key，重新create）：

 

 

 

（5）重新改值，再保存一下试试效果

 

 

（6）效果立竿见影

 

 

 

（7）不信，postman走一波，再确认下配置是否"共享"成功了！

 

 

 

 

 

 

 五、小结

 

               上面已经很详细的走了一遍consul配置中心的功能闭环了，具体怎么用，在哪用，想必大家心里都有个数了，真实环境中，不可能只用一个consul节点，也不可能只用consul配置中心这一个功能，服务的实例也不可能只有一个，consul部署会是cluster，服务实例可能会N多个，总之，不管环境怎么样，本篇要告诉你的是，服务繁琐的配置是可以统一进行管理的，而且可以动态的修改，实时的分发通知到所有和该配置有关的服务实例上，如此以来，我们就再也不用为每部署一套相同的服务就要改一个配置而发愁了！