consul原理

1.什么是consul？

Consul 是 HashiCorp 公司推出的开源工具，用于实现分布式系统的服务发现与配置。与其它分布式服务注册与发现的方案，Consul 的方案更“一站式”，内置了服务注册与发现框 架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案，不再需要依赖其它工具（比如 ZooKeeper 等）。使用起来也较 为简单。Consul 使用 Go 语言编写，因此具有天然可移植性(支持Linux、windows和Mac OS X)；安装包仅包含一个可执行文件，方便部署，与 Docker 等轻量级容器可无缝配合。

2.consul 具有以下性质：

服务发现：consul通过http 方式注册服务，并且服务与服务之间相互感应。
服务健康监测
key/value 存储
多数据中心
consul可运行在mac windows linux 等机器上。

3.Consul VS Eureka

Eureka 是一个服务发现工具。该体系结构主要是客户端/服务器，每个数据中心有一组 Eureka 服务器，通常每个可用区域一个。通常 Eureka 的客户使用嵌入式 SDK 来注册和发现服务。对于非本地集成的客户，官方提供的 Eureka 一些 REST 操作 API，其它语言可以使用这些 API 来实现对 Eureka Server 的操作从而实现一个非 jvm 语言的 Eureka Client。
Eureka 提供了一个弱一致的服务视图，尽可能的提供服务可用性。当客户端向服务器注册时，该服务器将尝试复制到其它服务器，但不提供保证复制完成。服务注册的生存时间（TTL）较短，要求客户端对服务器心跳检测。不健康的服务或节点停止心跳，导致它们超时并从注册表中删除。服务发现可以路由到注册的任何服务，由于心跳检测机制有时间间隔，可能会导致部分服务不可用。这个简化的模型允许简单的群集管理和高可扩展性。
Consul 提供了一些列特性，包括更丰富的健康检查，键值对存储以及多数据中心。Consul 需要每个数据中心都有一套服务，以及每个客户端的 agent，类似于使用像 Ribbon 这样的服务。Consul agent 允许大多数应用程序成为 Consul 不知情者，通过配置文件执行服务注册并通过 DNS 或负载平衡器 sidecars 发现。
Consul 提供强大的一致性保证，因为服务器使用 Raft 协议复制状态 。Consul 支持丰富的健康检查，包括 TCP，HTTP，Nagios / Sensu 兼容脚本或基于 Eureka 的 TTL。客户端节点参与基于 Gossip 协议的健康检查，该检查分发健康检查工作，而不像集中式心跳检测那样成为可扩展性挑战。发现请求被路由到选举出来的 leader，这使他们默认情况下强一致性。允许客户端过时读取取使任何服务器处理他们的请求，从而实现像 Eureka 这样的线性可伸缩性。
Consul 强烈的一致性意味着它可以作为领导选举和集群协调的锁定服务。Eureka 不提供类似的保证，并且通常需要为需要执行协调或具有更强一致性需求的服务运行 ZooKeeper。
Consul 提供了支持面向服务的体系结构所需的一系列功能。这包括服务发现，还包括丰富的运行状况检查，锁定，密钥/值，多数据中心联合，事件系统和 ACL。Consul 和 consul-template 和 envconsul 等工具生态系统都试图尽量减少集成所需的应用程序更改，以避免需要通过 SDK 进行本地集成。Eureka 是一个更大的 Netflix OSS 套件的一部分，该套件预计应用程序相对均匀且紧密集成。因此 Eureka 只解决了一小部分问题，可以和 ZooKeeper 等其它工具可以一起使用。
Consul 强一致性©带来的是：
服务注册相比 Eureka 会稍慢一些。因为 Consul 的 raft 协议要求必须过半数的节点都写入成功才认为注册成功 Leader 挂掉时，重新选举期间整个 Consul 不可用。保证了强一致性但牺牲了可用性。
Eureka 保证高可用(A)和最终一致性：
服务注册相对要快，因为不需要等注册信息 replicate 到其它节点，也不保证注册信息是否 replicate 成功 当数据出现不一致时，虽然 A, B 上的注册信息不完全相同，但每个 Eureka 节点依然能够正常对外提供服务，这会出现查询服务信息时如果请求 A 查不到，但请求 B 就能查到。如此保证了可用性但牺牲了一致性。
其它方面，eureka 就是个 servlet 程序，跑在 servlet 容器中; Consul 则是 go 编写而成。

4. 服务发现和治理

在分布式系统结构中，往往由成百上千的业务服务组成，为了容灾(节点宕机)、扩容(增加节点)、提高运维效率(动态配置)等原因，需要服务能够实现灵活发现，避免问题节点等功能，以提高系统稳定性（更多内容，关注微信公众号：白白家族）。

1 服务发现以及注册：

当服务Producer 启动时，会将自己的Ip/host等信息通过发送请求告知 Consul，Consul 接收到 Producer 的注册信息后，每隔一段时间会向 Producer 发送一个健康检查的请求，检验Producer是否健康。

2 服务调用：

当 Consumer 请求Product时，会先从 Consul 中拿到存储Product服务的 IP 和 Port 的临时表(temp table)，从temp table表中任选一个· Producer 的 IP 和 Port， 然后根据这个IP和Port，发送访问请求；temp table表只包含通过了健康检查的 Producer 信息，并且每隔一段时间更新

5.consule 核心 agent组件

Agent是一个独立的程序，通过守护进程的方式，运行在consul集群中的每个节点上。每个Consul agent维护它自己的服务集合以及检查注册和健康信息。agent负责执行自己的健康检查和更新本地状态其中，Agent 根据节点的性质，分为： Agent Server 和 Agent Client

Agent Client:

client将 HTTP 和 DNS 接口请求转发给局域网内的服务端集群。

Agent Server:

server 保存client的注册信息，集群的配置信息, 维护集群高可用, 在局域网内与本地客户端通讯, 通过广域网与其它数据中心通讯。 每个数据中心的 server 数量推荐为 3 个或是 5 个,通过 Raft 算法来保证一致性。

6. consul 去中心化思想实现

consul 使用了基于gossip协议的Serf实现，Serf是一个服务发现，编配工具，它去中心化，不像集中式结构那样统一分配管理； Serf提供成员关系，纠错检查，广播等功能。gossip协议主要是基于UDP，实现任意node-to-node间的通信。Consul正是使用serf 提供的gossip协议来管理成员和广播消息到集群。

gossip 协议（gossip protocol）是基于流行病传播方式的节点或者进程之间信息交换的协议，来确保网络中所有节点的数据一样。其中节点间的交互方式主要以下有三种：

· Push：发起信息的节点 A 随机选择联系节点 B，并向B发送自己的信息，节点 B 在收到信息后，更新比自己新的数据，一般拥有新信息的节点才会作为发起节点。

· Pull：发起信息的节点 A 随机选择联系节点 B，并从对方获取信息。一般无新信息的节点才会作为发起节点。

· Push&Pull：发起信息的节点 A 向选择的节点 B 发送信息，同时从对方获取数据，用于更新自己的本地数据。

7. 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 - 远程过程调用。这是一种允许客户端发出服务器请求的请求/响应机制。

8.和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。