微服务注册中心：Consul——概念与基础操作
系列文章：
微服务网关：Spring Cloud Gateway —— Zuul
微服务网关：Spring Cloud Config- 配置中心
楔子
好久不见。由于工作的原因停更了一段时间，今天开始继续更新。前面介绍过微服务相关的一些技术方案，注册中心除了 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，所以安装比较简单，执行下面的两条命令即可：
安装时有一些输出信息，重点看使用部分：
2.2 启动 Consul
输出信息中给出了启动方式，采用 brew services start hashicorp/tap/consul 启动：
启动完毕。
2.3 验证
控制台 执行 consul：
三 基础操作
可以参考 Consul 官方的quick start手册。
consul 的通用启动命令是 consul agent -dev。 由于上面已经通过 brew services 启动完毕，所以这里不必再次执行。不过尝试执行报错，也可以看到 consul 的默认端口（8300）。
3.1 发现数据中心成员
consul member 命令：
可见输出的是 agent 及 agent 的 ip 地址（&端口），健康状态（正常是 alive），类型等等。
使用 consul members -detailed 可以查看更详细的信息：
3.2 HTTP API
除了 8300，Consul 还占用了 8500 端口，作为 HTTP 的 API。通过下面命令获取 API 信息：
输出如下：
3.3 DNS 接口
除了 HTTP API，Consul 还提供了 DNS 接口来发现节点，Consul agent 的 DNS Server 启动于 8600 端口。通过 dig 命令查询方式如下：
8600 端口详情：
3.4 停止 agent
命令：consul leave，优雅退出。
版权声明: 本文为 InfoQ 作者【程序员架构进阶】的原创文章。
原文链接:【http://xie.infoq.cn/article/61b260b61df452bd6fa47cbbb】。文章转载请联系作者。
磨炼中成长，痛苦中前行 2017.10.22 加入
微信公众号【程序员架构进阶】。多年项目实践，架构设计经验。曲折中向前，分享经验和教训
评论