Consul介绍

Consul是一个分布式的，高可用、高拓展性的，支持数据中心的服务发现和配置系统

目前比较主流的注册中心有Eureka、Consul、zookeeper、etcd等

与其它分布式服务注册与发现的方案相比，Consul 的方案更“一站式”——内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案，不再需要依赖其它工具。Consul 本身使用 go 语言开发，具有跨平台、运行高效等特点，也非常方便和 Docker 配合使用。

Consul的关键特性

服务发现(Service Discovery) Consul的客户端可用提供一个服务,比如 api 或者mysql ,另外一些客户端可用使用Consul去发现一个指定服务的提供者.通过DNS或者HTTP应用程序可用很容易的找到他所依赖的服务.
健康检查(Health Checking) Consul客户端可用提供任意数量的健康检查,指定一个服务(比如:webserver是否返回了200 OK 状态码)或者使用本地节点(比如:内存使用是否大于90%). 这个信息可由operator用来监视集群的运行状况.被服务发现组件用来避免将流量发送到不健康的主机.
Key/Value存储(KV Store) 应用程序可用根据自己的需要使用Consul的层级的Key/Value存储.比如动态配置,功能标记,协调,领袖选举等等,简单的HTTP API让他更易于使用.
多数据中心(Multi Datacenter) Consul支持支持任意数量数据中心.这意味着用户不需要担心需要建立额外的抽象层让业务扩展到多个区域.
安全服务通信(Secure Service Communication)
Consul可以为服务生成分布式的 TLS 证书，以建立相互的 TLS 连接。 可以使用 intentions 定义允许哪些服务进行通信。 可以使用 intentions 轻松管理服务隔离，而不是使用复杂的网络拓扑和静态防火墙规则。

Consul的优势对比

相较于现在比较流行的微服务发现组件,例如Eureka、zookeeper、etcd，与其他三款发现组件进行了对比

• Consul集群间使用了GOSSIP协议通信和raft一致性算法。 比复杂的 Paxos 算法更直接。
• 支持多数据中心，内外网的服务采用不同的端口进行监听。多数据中心集群可以避免单数据中心的单点故障，而其部署则需要考虑网络延迟, 分片等情况等。 zookeeper 和 etcd 均不提供多数据中心功能的支持。
• 支持健康检查。 etcd 不提供此功能。
• 支持 http 和 dns 协议接口。 zookeeper 的集成较为复杂, etcd 只支持 http 协议。
• 官方提供 Web 管理界面, etcd 无此功能。
• Consul 保持了 CAP 中的 CP，保持了强一致性和分区容错性。
• Consul 支持 Http\gRPC\DNS 多种访问方式。

基础架构

• Server :

1. 是consul服务端高可用集群
2. 保存配置信息, 持久化数据
3. 在局域网内与本地客户端通讯, 通过广域网(WAN Gossip)与其它数据中心通讯,转发请求给Server-Leader
4. 每个数据中心的 Server 数量推荐为 3 个或是 5 个。

• Client

1. 是consul客户端
2. 无状态，不持久化数据
3. 将 HTTP 和 DNS 接口请求转发给局域网内的服务端集群。

• Agent

1. 是一个守护线程
2. Agent与一个和多个Consul Server 进行交互,跟随Consul应用启动而启动
3. 负责检查、维护节点同步

• Server-Leader

1. 响应RPC请求
2. 服务列表数据同步给Server

每个数据中运行了一个Consul server集群.当一个跨数据中心的服务发现和配置请求创建时.本地Consul Server转发请求到远程的数据中心并返回结果.

服务注册及服务发现

加载配置时，Consul会以词法顺序从文件和目录中加载配置。例如，配置文件 basic_config.json将在之前处理extra_config.json。配置可以采用HCL或JSON格式。HCL支持在Consul 1.0和更高版本中可用，现在需要在所有配置文件上使用.hcl或 .json扩展名以指定其格式。

注:此项目通过构建connect-proxy (connect使用envoy,虚构服务,做请求的分发)和service-router配合来对微服务内部通信进行路由匹配,从而控制微服务间的通讯

---

---

consul版本:1.6 以一个实际运用的配置作为例子对部分参数进行解释

- server ： 定义agent是否为server节点
- bind_addr: 内部集群的通讯,集群内的所有节点到地址都必须是可达的，默认是0.0.0.0
- bootstrap: 是否为bootstrap模式,此模式下一个数据中心只允许一个server处于bootstrap模式,单节点模式为true
- bootstrap-expect ：在一个datacenter中期望提供的server节点数目，要么不提供此值，要么该值必须与集群中的其他服务器一致。如果提供，Consul将等待直到指定数量的服务器可用为止，然后引导集群。该标记不能和bootstrap共用,需要server模式
- datacenter:数据中心
- log_level:设置日志级别，默认是"info",可以是 "trace", "debug", "info", "warn", and "err"
- retry_interval :加入集群时间间隔默认30s
- client_addr :consul将客户端接口绑定地址，这个地址提供HTTP、DNS、RPC等服务，默认是127.0.0.1所以不对外提供服务，如果你要对外提供服务改成0.0.0.0
- ui :是否开启内置的web管理界面
- ui-dir： 提供存放web ui资源的路径，该目录必须是可读的
- connect :允许使用connect功能
- ports:允许keys绑定端口,此处设置grpc,默认disable(使用envoy代理必须设置true)
- enable_central_service_config :这允许集中定义服务协议或代理设置,并由任何影响的服务注册继承,使用config_entries设置true
- node：节点在集群中的名称，在一个集群中必须是唯一的，默认是该节点的主机名
- config-dir：配置文件目录，里面所有以.json结尾的文件都会被加载
- Service :服务定义
		 		name :应用服务名称(随意,便于区分最好取应用名称)
				port :服务端口(若sidecar未指定port, 则该端口需要指定应用端口)
				kind :服务类型(这里用的是代理服务Envoy,必须配置为connect-proxy其余不配置)
		connect :connect配置
				sidecar_service
							proxy
								upstreams
									destination_name :目标服务的名称(对应想发到的服务名称,这里配置envoy-proxy代表请求发到虚构的服务envoy-proxy中)
									local_bind_port :代理服务端口(可随意指定,应用发送该端口)
									local_bind_address :代理服务地址,默认是127.0.0.1
									destination_type :目标服务类型(service or prepare_query)
									datacenter :数据中心,默认本地数据中心
									config:对代理服务的超时及重试等的设置
config_entries:入口配置
			bootstrap :
				kind :service-router [类型(service-router,service-resolver,service-splitter,service-defaults,proxy-defaults,其中proxy-defaults只能配置一个)]  
				name :被配置的服务名称(这里配置了envoy-proxy服务名,代表该proxy的路由规则)
				protocol:协议配置(http,grpc,udp,tcp,https)
				routes:路由匹配规则
					match:
						http:
							PathExact:精确路径匹配
							PathPrefix:	匹配前缀(配置内部请求路径,即代码里的.do)
							PathRegex:	正则表达式匹配
							Header:
								...
							QueryParam:
								...
					 Destination:
					 		...								

更多参数配置具体参考:service-router配置
这里对于实例不做过多介绍

整套下来实现了两个重点：

实现了中心服务注册查询
平台中其他节点的查询服务和配置文件自动更新

健康检查

consul对注册的服务都支持健康检查。方法是在service下面再嵌套一个check配置即可。

{
  "service": {
    "name": "service_name",
    "check": {

    }
  }
}

具体配置请参照:Check配置

consul支持5种check方式:

• Script + Interval: 周期性运行某个可执行程序，根据程序退出码确定服务是否存活
• HTTP + Interval: 周期性访问某个http地址，根据返回码是否为2xx确定服务是否存活。
• TCP + Interval: 周期性发起TCP请求，根据是否成功建立连接TCP连接确定服务是否存活
• Time to Live (TTL): 类似于心跳检测。服务状态是用过周期性向HTTP接口发起PUT请求确定的。超期没有更新数据就判断服务挂了
• Docker + Interval: 通过docker的api检测docker内服务的状态

总结

此次介绍了Consul的几个要点:
1.实现了中心服务注册查询
2.平台中其他节点的查询服务和配置文件自动更新
3.对Service里的节点进行健康检查

Consul将代码的业务和微服务的框架两者进行脱离，Consul的运行不需要对代码本身进行任何的相关修改，只需要获取到集群的IP和port即可，可便于集群功能的拓展性和可用性

consul除了可以用作服务治理的工具，还可以利用其KV存储能力，实现分布式服务配置或分布式锁等功能。具体参照官方文档
(以后可能更新K/V功能 以及 ACL 控制功能)

参考资料

https://www.consul.io/
https://www.jianshu.com/p/32dc52f28a14
https://blog.csdn.net/liuzhuchen/article/details/81913562