Consul 基本概念，同类比较和内部原理

这个文章咱们主要来讲一下Consul的基本概念，以及其实现的内部原理，和Eureka的比较。

1.什么是Consul？

Consul是一种服务网格解决方案，提供具备服务发现，配置和分段功能的全功能控制平面。 这些功能中的每个均可以根据须要单独使用，也能够一块儿使用以构建全服务网格。 Consul须要数据平面并支持代理和本机集成模型。 Consul附带一个简单的内置代理，所以一切均可以开箱即用，但也支持第三方代理集成，如Envoy。
Consul 提供的关键功能：

• 服务发现：Consul的客户端能够注册服务，例如api或mysql，其余客户端可使用Consul来发现给定服务的提供者。使用DNS或HTTP，应用程序能够轻松找到它们所依赖的服务。
• 运行情况检查：Consul客户端能够提供任意数量的运行情况检查，这些检查与给定服务（“是Web服务器返回200 OK”）或本地节点（“内存利用率低于90％”）相关联。运营人员可使用此信息来监控群集运行情况，服务发现组件使用此信息将流量路由到远离不健康主机的地方。
• KV 存储：应用程序能够将Consul的层级键/值存储用于任何目的，包括动态配置，功能标记，协调，领导者选举等。简单的HTTP API使其易于使用。
• 安全服务通讯：Consul能够为服务生成和分发TLS证书，以创建相互的TLS链接。Intentions(意图）可用于定义容许哪些服务进行通讯。可使用能够实时更改的意图轻松管理服务分段，而不是使用复杂的网络拓扑和静态防火墙规则。
• 多数据中心：Consul支持多个数据中心。这意味着Consul的用户没必要担忧构建额外的抽象层以扩展到多个区域。

2. Consul 的架构

2.1 Consul 中的术语

在描述架构以前，咱们提供术语表以帮助澄清正在讨论的内容：

• 代理（agent） - 代理是Consul集群的每一个成员上长时间运行的守护程序。它是经过运行consul agent 命令来启动的。代理可以以客户端或服务器模式运行。因为全部节点都必须运行代理，所以将节点称为客户端或服务器更简单，但代理还有其余实例。全部代理均可以运行DNS或HTTP接口，并负责运行检查并保持服务同步。
• 客户端模式（client agent） - 客户端是将全部RPC调用转发到服务器的代理。客户端是相对无状态的。客户端执行的惟一后台活动是参与LAN gossip pool（局域网 Gossip池）。这会花费很是很是小的资源而且仅消耗少许的网络带宽。
• 服务器模式(server agent) - 服务器是具备扩展责任的代理，包括参与Raft仲裁，维护群集状态，响应RPC查询，与其余数据中心交换WAN Gossip（广域网Gossip）以及将查询转发给领导者或远程数据中心。
• 数据中心 （datacenter）- 虽然数据中心的定义彷佛很明显，但必须考虑细微的细节。例如，在EC2中，多个可用区域是否被视为包含单个数据中心？咱们将数据中心定义为专用，低延迟和高带宽的网络环境。这排除了经过公共互联网的通讯，但出于咱们的目的，单个EC2区域内的多个可用区域将被视为单个数据中心的一部分。
• 共识 （consensus）- 在咱们的文档中使用时，咱们使用共识来表示对当选领导者的协议以及对交易顺序的协议。因为这些事务应用于有限状态机，所以咱们对共识的定义意味着复制状态机的一致性。维基百科上更详细地描述了共识，此处描述了咱们的实现。
• Gossip - Consul创建在Serf之上，它提供了一个完整的gossip 协议（八卦协议Gossip协议），用于多种用途。 Serf提供成员维护，故障检测和事件广播。咱们对这些的使用在八卦文档中有更多描述。Gossip参与随机的节点到节点的通讯，主要是经过UDP。
• LAN Gossip - 指局域网八卦池，其中包含位于同一局域网或数据中心的节点。
• WAN Gossip - 指仅包含服务器（servers）的WAN八卦池。这些服务器主要位于不一样的数据中心，一般经过互联网或广域网进行通讯。
• RPC - 远程过程调用。这是一种容许客户端发出服务器请求的请求/响应机制。

2.2 一万英尺看Consul

让咱们分解这个图像并描述每一块。首先，咱们能够看到有两个数据中心，标记为“one”和“two”。 Consul为多个数据中心提供一流的支持，并指望这是常见的状况。

在每一个数据中心内，咱们都有客户端和服务端的混合体。预计有三到五台服务端。这在失败和性能的可用性之间取得平衡，由于随着更多机器的添加，共识逐渐变慢。可是，客户端数量没有限制，能够轻松扩展到数千或数万。

数据中心中的全部节点都参与八卦协议。这意味着有一个八卦池，其中包含给定数据中心的全部节点。这有几个目的：首先，不须要为客户端配置服务器的地址;发现是自动完成的。其次，检测节点故障的工做不是放在服务器上，而是分布式的。这使得故障检测比天真的心跳方案更具可扩展性。第三，它被用做消息传递层，用于在诸如领导者选举等重要事件发生时进行通知。

每一个数据中心中的服务器都是单个Raft对等集的一部分。这意味着他们共同选举一个leader，一个具备额外职责的选定服务器。领导者负责处理全部查询和交易。做为共识协议的一部分，还必须将事务复制到全部对等体。因为此要求，当非领导者服务器收到RPC请求时，它会将其转发给群集leader。

服务器节点做为WAN八卦池的一部分运行。此池与LAN池不一样，由于它针对较高的Internet延迟进行了优化，而且预计仅包含其余Consul服务器节点。此池的目的是容许数据中心以低触摸方式（low-touch manner)发现彼此。在线建立新的数据中心就像加入现有的WAN八卦池同样简单。因为服务器都在此池中运行，所以它还支持跨数据中心请求。当服务器收到对不一样数据中心的请求时，它会将其转发到正确数据中心的随机服务器。而后该服务器能够转发给本地领导者。

这致使数据中心之间的耦合很是低，但因为故障检测，链接缓存和多路复用，跨数据中心请求相对快速且可靠。

一般，不会在不一样的Consul数据中心之间复制数据。当对另外一个数据中心中的资源发出请求时，本地Consul服务器会将RPC请求转发给该资源的远程Consul服务器并返回结果。若是远程数据中心不可用，那么这些资源也将不可用，但这不会影响本地数据中心。在某些特殊状况下，能够复制有限的数据子集，例如使用Consul的内置ACL复制功能，或者像consul-replicate这样的外部工具。

在某些地方，客户端代理能够缓存来自服务器的数据，以使其在本地可用，以提升性能和可靠性。示例包括链接证书Connect certificates和意图intentions ，容许客户端代理在没有往返服务器的状况下作出有关入站链接请求的本地决策。某些API端点还支持可选的结果缓存。这有助于提升可靠性，由于本地代理能够继续响应某些查询，例如服务发现或从缓存链接受权，即便与服务器的链接中断或服务器暂时不可用。

3. Gossip协议和Raft协议

要想理解Consul的原理，你是绕不过Gossip协议和Raft协议的。

3.1 八卦协议Gossip Protocol

3.1.1 什么是Gossip 协议

Gossip算法如其名，灵感来自办公室八卦，只要一我的八卦一下，在有限的时间内全部的人都会知道该八卦的信息，这种方式也与病毒传播相似，所以Gossip有众多的别名“闲话算法”、“疫情传播算法”、“病毒感染算法”、“谣言传播算法”。更多，可参见这篇博文

3.1.2 Consul中的八卦协议

Consul使用两个不一样的八卦池。咱们将每一个池分别称为LAN或WAN池。

每一个数据中心Consul都有一个LAN八卦池，包含数据中心的全部成员，包括客户端和服务器。 LAN池用于一些目的。成员资格信息容许客户端自动发现服务器，减小所需的配置量。分布式故障检测容许整个集群共享故障检测工做，而不是集中在少数服务器上。最后，八卦池容许为领导者选举等事件提供可靠和快速的事件广播。

WAN池是全局惟一的，由于不管数据中心如何，全部服务器都应该参与WAN池。 WAN池提供的成员资格信息容许服务器执行跨数据中心请求。集成故障检测容许Consul优雅地处理丢失链接的整个数据中心，或者只处理远程数据中心中的单个服务器。

全部这些功能都是经过利用Serf提供的。它用做嵌入式库以提供这些功能。从用户的角度来看，这并不重要，由于抽象应该由Consul掩盖。可是，做为开发人员，了解如何利用此库很是有用。

3.2 Raft协议

Raft 协议，主要负责leader选举和日志同步。
推荐你看一下这篇博客，
你也能够到这个网站经过动画的方式，像玩游戏同样在线体验raft协议的原理。

4.和Eureka的比较

Eureka由于是Netflix OSS套件的一部分，2.x中止维护，不过1.x仍然是活跃的。

这里重点说下consul与Eureka的区别。和其余系统的比较，可点击此网址自行查看。

Eureka是一种服务发现工具。该体系结构主要是客户端/服务器，每一个数据中心有一组Eureka服务器，一般每一个可用区域一个。一般，Eureka的客户使用嵌入式SDK来注册和发现服务。对于非本地集成的客户端，使用Ribbon等边车经过Eureka透明地发现服务。

Eureka使用尽力而为的复制提供弱一致的服务视图。当客户端向服务器注册时，该服务器将尝试复制到其余服务器但不提供保证。服务注册的生存时间（TTL)很短，要求客户端对服务器进行心跳检测。不健康的服务或节点中止心跳后，致使它们超时并从注册表中删除。发现请求能够路由到任何服务，因为尽力复制，这些服务能够提供过期或丢失的数据。这种简化的模型能够实现轻松的集群管理和高可扩展性。

Consul提供了一系列超级功能，包括更丰富的健康检查，键/值存储和多数据中心感知。 Consul须要每一个数据中心中的一组服务器，以及每一个客户端上的代理，相似于使用像Ribbon这样的边车。 Consul代理容许大多数应用程序不知道Consul，经过配置文件执行服务注册以及经过DNS或负载平衡器sidecars进行发现。

Consul提供强一致性保证，由于服务器使用Raft协议复制状态。 Consul支持丰富的运行情况检查，包括TCP，HTTP，Nagios / Sensu兼容脚本或基于Ture的Eureka。客户端节点参与基于八卦的健康检查，该检查分发健康检查的工做，而不像集中式心跳，这成为可扩展性挑战。发现请求被路由到当选的领事领导者，这容许他们默认状况下是强烈一致的。容许过期读取的客户端容许任何服务器处理其请求，从而容许像Eureka同样的线性可伸缩性。

Consul的强一致性意味着它能够用做领导者选举和集群协调的锁服务。 Eureka不提供相似的保证，而且一般须要为须要执行协调或具备更强一致性需求的服务运行ZooKeeper。

Consul提供了支持面向服务的体系结构所需的功能工具包。这包括服务发现，还包括丰富的运行情况检查，锁定，键/值，多数据中心联合，事件系统和ACL。 Consul和consul-template和envconsul等生态系统工具都试图最大限度地减小集成所需的应用程序更改，以免须要经过SDK进行本机集成。 Eureka是更大的Netflix OSS套件的一部分，该套件指望应用程序相对同质且紧密集成。所以，Eureka只解决了有限的一部分问题，指望其余工具如ZooKeeper能够同时使用。

总结一下上面的几段话：

• Consul 经过Raft协议提供强一致性，而Eureka提供的弱一致性。
• Consul 经过Gossip协议更好分发健康检查的工做，而不是Eureka集中式心跳（要客户端不停地请求服务端）
• 因为Raft提供的强一致性，Consul能够用来作领导选择，集群协议的锁服务，而Eureka只能借助于Zookeeper。

另外，Spring Cloud官方提供对Consul的支持，网址是https://spring.io/projects/sp...，后面我会写文章具体的使用。

5.参考：

https://www.consul.io/intro/i...
https://www.consul.io/intro/v...
https://www.consul.io/docs/in...
https://www.consul.io/docs/in...
https://www.consul.io/docs/in...
https://www.cnblogs.com/xingz...
https://www.cnblogs.com/xybab...

文章以后会第一时间发于微信， 欢迎关注个人微信公众号，你们一块儿交流学习