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

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐