SpringBoot2.x集成Consul，实现服务的配置中心化管理（配置共享）

一、为什么要用consul

   

           本文不讨论consul和eureka、etcd、zk的对比，单纯从consul本身来说，就是简单易用，安装方便，带web界面，而且服务配置功能可以拿出来单用，用起来也不难，k/v键值对动态构建配置，服务端实时更新，用起来很使用且方便。

二、Windows单机版跑consul服务

（1） 下载地址：https://pan.baidu.com/s/1P0qBS7Wg5cn-BUjN6ae5ag

              提取码:  wfyv 

（2）下载后解压，看到exe

（3）我们cmd输入，consul agent -dev 启动服务，默认端口8500

（4）浏览器走一波，看下web端界面长什么样子

 备注：别忘了，consul也是服务注册和发现中心噢，本篇博文，我们暂时不用这个功能；

（5）注意这个key/value,后面我们会结合kv存储配置，来演示一下单节点的服务是如何通过consul服务中心实现配置的动态配置的，单节点都能实现的话，那集群就更不在话下了，集群就是多个服务部署在不同的tomcat上，但是多个服务的配置却统一交由consul进行管理，管理要实现的就是要做到"多服务节点配置共享"，说白了就是，"配置一处修改，处处生效！"

 

 

三、SpringBoot-2.1.4.RELEASE集成Consul

   备注：代码仓库里，也包含了windows64位的consul，所以上面提供的百度网盘地址无法下载的话，可以直接clone项目

（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多个，总之，不管环境怎么样，本篇要告诉你的是，服务繁琐的配置是可以统一进行管理的，而且可以动态的修改，实时的分发通知到所有和该配置有关的服务实例上，如此以来，我们就再也不用为每部署一套相同的服务就要改一个配置而发愁了！