SpringBoot2.x integrated Consul, realized centralized configuration management services (configuration share)

First, why should consul

   

           This article does not discuss the consul and eureka, etcd, zk contrast, simply speaking from the consul itself is easy to use, easy to install, with a web interface, configuration and service functions can be out alone, using them is not difficult, k / v key build configuration for dynamic, server-side real-time updates, and use them very easy to use.

 

Two, Windows stand-alone service run consul

 

(1) Download: https://pan.baidu.com/s/1P0qBS7Wg5cn-BUjN6ae5ag

              Extraction code:  wfyv 

 

(2) After the download, unzip, see exe

 

 

(3) We enter cmd, Consul Agent -dev  start the service, the default port 8500

 

 

 

(4) wave of the browser to go, look at web client interface looks like

 

 Note: Do not forget, consul also service registration and discovery center oh, this post, we do not have this feature;

 

 

 

(5) Note that this key / value, later we will combine kv storage configuration, service to show you how to achieve single-node is configured by the service center consul dynamic configuration, can achieve single-node, then the cluster is not more words under the cluster is to deploy multiple services on different tomcat, but a plurality of configuration services but unified by the consul management, manage to achieve is to be "multi-service node configuration sharing", it means " Configuring a modification, to take effect everywhere! "

 

 

 

 

Three, SpringBoot-2.1.4.RELEASE integrated Consul

 

   Note: The code warehouse, also includes windows64 bit consul, so Baidu network disk address provided above can not be downloaded, you can directly clone project

 

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