微服务注册中心：Consul——概念与基础操作
系列文章：
微服务架构：网关概念与 zuul
微服务网关：Spring Cloud Gateway —— Zuul
微服务网关：Spring Cloud Config- 配置中心
微服务网关方案：Kong & Nacos
Nacos 实践
微服务网关：Nacos 源码实践（二）
楔子
好久不见。由于工作的原因停更了一段时间，今天开始继续更新。前面介绍过微服务相关的一些技术方案，注册中心除了Zookeeper、Nacos之外，其实Consul也可以，只不过使用比例上看并不算高。最近发现某大厂的一个部门中有对Consul的使用，正好借机做一次了解。
一 简介
1.1 官网
consul（Consul的官网地址：https://www.consul.io/）是google开源的一个使用go语言开发的服务发现、配置管理中心服务。内置了服务注册与发现框 架、分布一致性协议实现、健康检查、Key/Value存储、多数据中心方案，不再需要依赖其他工具（比如ZooKeeper等）。服务部署简单，只有一个可运行的二进制的包。每个节点都需要运行agent，有server和client两种运行模式。每个数据中心官方建议需要3或5个server节点以保证数据安全，同时保证server-leader的选举能够正确的进行。
1.2 Consul VS Eureka
在官方的方案对比文档中，列举了Consul与ZooKeeper/doozerd/etcd，Eureka，Istio等方案的对比。由于使用的技术栈是Java，Spring Cloud体系中最常用的就是Eureka，所以这里只分析Consul vc Eureka的一些对比。
1.2.1 Eureka
Eureka是一个服务发现工具，体现在client/server架构上，每个数据服务节点都是一个Eureka服务器，一般来说每个可用区域有一个。（PS：Eureka的数据分布在多个数据节点中，这也是Eureka在接下来需要面临的数据复制TTL问题）举一个典型的例子：EurekaClient使用了嵌入SDK的方式去注册和发现服务。对于客户端没有一个强一致的控制力，比如Eureka的服务发现用的是Ribbon。
1.2.2 Eureka的弱一致问题
Eureka提供了一个弱一致服务视图，因为Eureka集群的每个数据服务节点都是一个Eureka服务器，导致它需要尽最大努力去复制这些，来尽可能解决一致性问题。当一个Client注册到Server时，Server会尝试把这个一个服务复制到其他的服务上，但并不保证此次操作的可靠性。服务注册有一个短的TTL，需要客户端和服务器保持心跳，不健康的服务或节点将会被服务器KILL掉，造成超时或被从注册中心移除。服务发现的请求将会被路由至其他服务，由于这种尽力的复制，可能会导致服务过期或数据丢失的问题。正是这种简易模型，以至于更加适用于简单的集群管理和他的高扩展性。
1.2.3 Consul的功能
Consul提供了一些更加丰富的功能，包含了丰富的健康度检查，KV存储（PS：想到了WOT的咪咪5#滑稽），和多数据中心预知。Consul需要在每个数据中心都有一套服务，每个客户端都有一个代理，这一点和Ribbon相似。Consul的代理在大部分应用中和Consul没有太大关系。服务注册经过配置文件，DNS发现，或负载均衡来实现。
1.2.4 Consul优势
Consul 提供了强一致保证，是因为服务复制使用了Raft协议（Raft协议可以看我后续的文章）。Consul支持一套丰富的监看检查，包含TCP/HTTP/Nagios/Sensu的兼容脚本，或者像Eureka的TTL一样。客户端阶段参与了一些不太重要的健康度检查，比如分配了一些健康度检查的工作，和Eureka的集中式心跳不同，分布式心跳将对服务注册/发现带来更强的伸缩性和扩展性。服务发现请求会被路由到已被确定的Consul中，这样可以在默认情况下具有强一致性。同样也允许已被过时版本的客户端处理其服务，从而保证像Eureka一样线性和可伸缩性的工作。
Consul的强一致性意味着它可以用来作为服务选举和集群服务协调时的服务控制(PS：像ZK一样用来做一致性处理的)。Eureka没有相似的功能，如果需要进行协调或具有更强一致性需求服务的话需要使用ZK来达到。
二 Mac下的安装使用
2.1 brew安装命令
由于有万能的brew，所以安装比较简单，执行下面的两条命令即可：
brew tap hashicorp/tap
brew install hashicorp/tap/consul
安装时有一些输出信息，重点看使用部分：
xxx common % brew install hashicorp/tap/consul
==> Installing consul from hashicorp/tap
==> Downloading https://releases.hashicorp.com/consul/1.9.5/consul_1.9.5_darwin_amd64.zip
######################################################################## 100.0%
==> Caveats
The darwin_arm64 architecture is not supported for this product
at this time, however we do plan to support this in the future. The
darwin_amd64 binary has been installed and may work in
compatibility mode, but it is not fully supported.
To have launchd start hashicorp/tap/consul now and restart at login:
brew services start hashicorp/tap/consul
Or, if you don't want/need a background service you can just run:
consul agent -dev -bind 127.0.0.1
==> Summary
? /opt/homebrew/Cellar/consul/1.9.5: 4 files, 107MB, built in 3 seconds
2.2 启动Consul输出信息中给出了启动方式，采用brew services start hashicorp/tap/consul启动：
common % brew services start hashicorp/tap/consul
==> Successfully started `consul` (label: homebrew.mxcl.consul)
启动完毕。2.3 验证
控制台 执行consul：
common % consul
Usage: consul [--version] [--help] <command> [<args>]
Available commands are:
acl Interact with Consul's ACLs
三 基础操作
可以参考Consul官方的quick start手册。
consul的通用启动命令是 consul agent -dev。由于上面已经通过brew services启动完毕，所以这里不必再次执行。不过尝试执行报错，也可以看到consul的默认端口（8300）。
3.1 发现数据中心成员
consul member命令：
可见输出的是agent及agent的ip地址（&端口），健康状态（正常是alive），类型等等。
使用 consul members -detailed 可以查看更详细的信息：
Node Address Status Tags
xxx-Pro.local 127.0.0.1:8301 alive acls=0,build=1.9.5:3c1c2267,dc=dc1,ft_fs=1,ft_si=1,id=f47cfd55-f256-4b1e-4a42-984501993b85,port=8300,raft_vsn=3,role=consul,segment=<all>,vsn=2,vsn_max=3,vsn_min=2,wan_join_port=83023.2 HTTP API除了8300，Consul还占用了8500端口，作为HTTP的API。通过下面命令获取API信息：
curl localhost:8500/v1/catalog/nodes输出如下：
[
{
"ID": "f47cfd55-f256-4b1e-4a42-984501993b85",
"Node": "xxx-Pro.local",
"Address": "127.0.0.1",
"Datacenter": "dc1",
"TaggedAddresses": {
"lan": "127.0.0.1",
"lan_ipv4": "127.0.0.1",
"wan": "127.0.0.1",
"wan_ipv4": "127.0.0.1"
},
"Meta": {
"consul-network-segment": ""
},
"CreateIndex": 11,
"ModifyIndex": 12
}
]
3.3 DNS接口
除了HTTP API，Consul还提供了DNS接口来发现节点，Consul agent的DNS Server启动于8600端口。通过dig命令查询方式如下：
dig @127.0.0.1 -p 8600 Judiths-MBP.node.consul
; <<>> DiG 9.10.6 <<>> @127.0.0.1 -p 8600 Judiths-MBP.node.consul
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 42102
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;Judiths-MBP.node.consul. IN A
;; AUTHORITY SECTION:
consul. 0 IN SOA ns.consul. hostmaster.consul. 1621941931 3600 600 86400 0
;; Query time: 18 msec
;; SERVER: 127.0.0.1#8600(127.0.0.1)
;; WHEN: Tue May 25 19:25:31 CST 2021
;; MSG SIZE rcvd: 1028600端口详情：common % lsof -i:8600
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
consul 98048 xxx 14u IPv4 0xba7147981abf21ab 0t0 TCP localhost:asterix (LISTEN)
consul 98048 xxx 15u IPv4 0xba71479806ef4c6b 0t0 UDP *:asterix3.4 停止agent命令：consul leave，优雅退出。
