微服务之Consul初识

        最近在研究微服务的架构，发现一个问题：Spring Cloud 基于Netflix那套基本都进入维护模式了，那未来在哪里？Spring Cloud Alibaba于2018年10月发布第一个快照版本，昨天抢在从孵化器毕业之前推出v2.1.0.RELEASE(中间有点小意外，导致v2.0.0.RELEASE间隔不到一天)。另一方面，服务网格概念声名鹊起。Istio作为标杆，早在2017年5月就发布了第一个版本，当前最新版本是Istio 1.2.2。微服务架构将何去何从？

        回到正题，鉴于Eureka进入维护模式，上一个项目用的正是Consul，于是开始琢磨起Consul。

Consul简介

一个服务网格解决方案，提供一个功能齐全的控制平面，具有服务发现、配置和分割功能。

换而言之，Consul不仅可以作为服务注册中心，还可以作为配置中心使用(基于Consul的Key-Value存储)，同时提供对ServiceMesh支持。支持多数据中心，官方示例的2个数据中心的内部集群架构如下图：

客户端Client：

客户端可以将所有RPC请求转发到服务器的代理。客户端是相对无状态的。客户端执行的唯一后台活动是LANgossip池。它消耗最小的资源开销和少量的网络带宽。

服务器端Server：

服务器端是具有扩展的功能的代理，它主要参与维护集群状态，响应RPC查询，与其他数据中心交换WAN gossip ，以及向leader节点或远程数据中心转发查询。

只有server才有可能当选leader。从上面的描述看，Client是需要的，他负责转发请求，同时也参与LANgossip和健康检查。而server不仅参与LANgossip还参与数据中心之间的WANgossip。

Consul推荐一个数据中心部署一个Consul集群。典型配置是3台/5台server。推荐的单一数据中心最大集群数量是5000个。当然，对于读负荷大的可以适当调高，写负荷大的则需要降低一些数量。因为Consul是CP设计，保证数据一致性，自然就要牺牲一些可用性。服务启动会需要与其他节点进行数据同步。(正是因为如此，Consul并不能作为大数据量的存储，集群节点间的数据复制会特别影响性能)

---

        在发生网络分区故障时，agent无法互相访问，可以使用Consul的network-segments(商业版-付费功能)在同一个集群中创建多个共享Raft服务器的租户。每个租户都有自己的gossip池，并且不会与池子外部的agent进行交流。但是，所有的租户都会分享KV存储。如果没有Consul网络分区功能权限，可以创建离散的Consul数据中心来将代理彼此隔离(手动)。

        说白了，就是将不同分区分别创建各自的集群，各个分区的agent只能访问自己所在分区的机器。

---

如下图所示：

在最初的时候，没有发生网络分区，集群中有5台server。发生如上网络分区后，server3和server5同属一个网络分区，不能与处于另一个分区的server相互访问。按照官方建议，手动创建了新的数据中心，同时为了保证集群法定数量，新增了一台server6。

注：图为笔者根据官方建议，自行绘制的，未实践过。

多个数据中心的情况下，可以通过WAN链接加入在不同数据中心中运行相同服务的Consul集群。集群独立运行，仅通过端口8302上的WAN进行通信。除非有具体配置，Consul servers将只会返回本地数据中心的结果。Consul不会在多个数据中心之间进行数据复制，但是可以通过consul-replicate工具来周期性复制KV数据。

启用TLS服务器名称检查是一个很好的实践，以避免代理的意外交叉连接。

网络连接

LAN gossip发生在单个数据中心中的所有agent之间，每个agent从其成员列表中向随机代理发送周期性探测。Client和Server都会参与gossip。初始探测每秒钟通过UDP发送一次。如果一个节点在200ms内无法确认，代理就会ping TCP。如果TCP探测失败(10秒超时)，它要求可配置数量的随机节点探测同一个节点(也称为间接探测)。如果没有来自对等节点的关于节点状态的响应，则该代理被标记为down。

代理的状态直接影响服务发现结果。如果代理关闭了，它监视的服务也将被标记为down。

在一个大型网络(3层segment)，通信需要经过防火墙/路由。必须更新ACL/防火墙设置。端口如下：

注：本文引用到的其他博客都在文中的超链接可直接跳转。另外，主要参考的是官方文档。

一篇文章了解Consul服务发现实现原理