一、Consul 是什么？

Consul有多个组件，但总体而言，它是基础架构中的一款服务发现和配置的工具。 它提供了几个关键功能：

• 服务发现：Consul client 可以提供服务，例如api或mysql，也可以使用Consul client来发现指定服务的提供者。 使用DNS或HTTP，应用程序可以轻松找到他们所依赖的服务。
• 健康检查：Consul client 可以提供任何数量的健康检查，或者与给定的服务（“Web服务器是否返回200 OK”），或与本地节点（“内存利用率是否低于90％”）相关联。 可以使用此信息来监控集群运行状况，服务发现组件使用此信息将流量从有问题的主机中移除出去。
• KV Store：应用程序可以使用Consul的分层键/值存储，包括动态配置，功能标记，协调，leader选举等等。 简单的HTTP API使其易于使用。
• 多数据中心：Consul支持多个数据中心。 这意味着Consul的用户不必担心构建额外的抽象层以扩展到多个区域。
  　　Consul旨在对DevOps社区和应用程序开发人员友好，使其成为现代化，弹性基础架构的完美选择。

二、Consul 基本架构

Consul 是一个分布式，高可用的系统。 为了快速了解Consul的工作原理，本节只介绍基础知识，不会介绍详细的细节。
　　向Consul提供服务的每个节点都运行一个Consul代理。 发现其他服务或获取/设置键/值数据不需要运行代理。 代理负责健康检查节点上的服务以及节点本身。
　　代理与一个或多个Consul服务器通信。Consul 服务器是数据存储和复制的地方。 服务器自己选出一个 leader。 虽然Consul可以在一台服务器上运行，但推荐使用3到5台来避免数据丢失的情况。 每个数据中心都建议使用一组Consul服务器。
　　需要发现其他服务或节点的基础架构组件可以查询任何Consul服务器或任何Consul代理。 代理自动将查询转发到服务器。
　　每个数据中心都运行Consul服务器集群。 当跨数据中心服务发现或配置请求时，本地Consul服务器将请求转发到远程数据中心并返回结果。

三、Consul VS. 其它软件

Consul解决的问题是多种多样的，但是每个单独的特征已经被许多不同的系统解决了。 尽管没有单一的系统提供Consul的所有功能，但还有其他的选择可以解决这些问题。

1、Consul vs. ZooKeeper, doozerd, etcd

ZooKeeper，doozerd和etcd在他们的架构中都是相似的。 所有这三个服务器节点都需要一定数量的节点才能运行（通常是简单多数）。 它们是高度一致的，并且公开了可以通过应用程序中的客户端库来构建复杂的分布式系统的各种基元。
　　Consul 还使用单个数据中心内的服务器节点。 在每个数据中心，Consul服务器都需要一个仲裁来操作并提供强大的一致性。 不过，Consul拥有对多个数据中心的本地支持，以及连接服务器节点和客户端的功能丰富的系统。
　　所有这些系统在提供键/值存储时都具有大致相同的语义：读取具有强烈的一致性，为了在网络分区的情况下保持一致性，牺牲了可用性。 但是，当这些系统用于高级案例时，这些差异会变得更加明显。
　　这些系统提供的语义对于构建服务发现系统是有吸引力的，但重要的是要强调必须构建这些功能。 ZooKeeper等软件仅提供原始K / V存储，并要求应用程序开发人员构建自己的系统以提供服务发现。 相比之下，Consul为服务发现提供了一个可用的框架，并且消除了猜测工作和开发工作。 客户端只需注册服务，然后使用DNS或HTTP接口执行发现。 其他系统需要一个自己定制的解决方案。
　　一个引人注目的服务发现框架必须包含健康检查和失败的可能性。 知道如果节点A失败或服务崩溃，则节点A提供Foo服务是没有用的。 原生系统使用心跳检测，定期更新和TTL。 这些方案需要与节点数量成线性关系，并将需求放在固定数量的服务器上。 此外，故障检测窗口至少与TTL一样长。
　　ZooKeeper提供临时节点，这些节点是客户端断开连接时删除的K / V条目。 这些比心跳系统更复杂，但仍然存在固有的可扩展性问题，并增加了客户端的复杂性。 所有客户端必须保持与ZooKeeper服务器的活动连接并执行保持活动。 另外，这需要“厚厚的客户端”，这些客户端很难编写，经常导致调试难题。
　　Consul 使用非常不同的体系结构进行健康检查。 Consul客户端不是只有服务器节点，而是在集群中的每个节点上运行。 这些客户端是gossip pool的一部分，可以提供多种功能，包括分布式健康检查。 gossip协议实现了一个高效的故障检测器，可以扩展到任何规模的集群，而不用将任务集中在任何选定的服务器组上。 客户端还可以在本地运行更丰富的运行状况检查，而ZooKeeper临时节点对活跃性进行非常原始的检查。 通过Consul，客户端可以检查Web服务器是否返回200的状态码，内存使用情况，有足够的磁盘空间等。和ZooKeeper一样，Consul客户端公开一个简单的HTTP接口，避免将系统的复杂性暴露给客户端。
　　Consul为服务发现，运行状况检查，K / V存储和多个数据中心提供一流的支持。 为了支持比简单K / V存储更多的功能，所有这些其他系统都需要额外的工具和库。 通过使用客户端节点，Consul提供了一个简单的API，只需要瘦客户端。 另外，完全可以通过使用配置文件和DNS接口完全避免使用API，以获得完整的服务发现解决方案，而完全没有任何开发。

2、Consul vs. Chef, Puppet等

使用Chef，Puppet和其他配置管理工具的人来构建服务发现机制并不罕见。 这通常通过查询全局状态来在定期收敛运行期间在每个节点上构建配置文件来完成。
　　不幸的是，这种方法有一些陷阱。 配置信息是静态的，不能比收敛运行更频繁地更新。 一般这是在几分钟或几小时的间隔。 另外，没有机制将系统状态结合到配置中：不健康的节点可能进一步接收流量，进一步加剧问题。 使用这种方法还可以支持多个数据中心，因为中央服务器组必须管理所有数据中心。
　　Consul专门设计为服务发现工具。 因此，它对集群的状态更具有动态性和响应性。 节点可以注册和注销他们提供的服务，使得依赖的应用程序和服务能够快速发现所有提供者。 通过使用集成的健康检查，Consul可以将流量从不健康的节点发送出去，从而使系统和服务能够正常恢复。 可以通过配置管理工具提供的静态配置可以移动到动态键/值存储中。 这允许应用程序配置更新，而不会收敛缓慢。 最后，由于每个数据中心独立运行，支持多个数据中心与单个数据中心没有区别。
　　也就是说，Consul并不是配置管理工具的替代品。 这些工具对于设置应用程序（包括Consul本身）至关重要。 静态配置最好由现有工具管理，而动态状态和发现则由Consul更好地管理。 配置管理和集群管理的分离也有一些有利的副作用：Chef和Puppet在没有全局状态的情况下变得更简单，服务或配置更改不再需要定期运行，并且由于配置管理运行 不需要全局状态。

3、Consul vs. Nagios, Sensu

Nagios和Sensu都是用于监控的工具。 当问题发生时，它们用于快速通知操作员。
　　Nagios使用一组配置为在远程主机上执行检查的中央服务器。 这种设计使Nagios难以规模化，因为大型船队迅速达到垂直尺度的限制，Nagios不容易水平缩放。 Nagios在现代DevOps和配置管理工具中也非常难以使用，因为在添加或删除远程服务器时必须更新本地配置。
　　Sensu有一个更现代化的设计，依靠当地的代理商运行支票，并推动结果AMQP经纪人。 许多服务器从代理获取并处理健康检查的结果。 这个模型比Nagios更具可扩展性，因为它允许更多的水平缩放和服务器和代理之间的较弱耦合。 但是，中央经纪人已经具有扩展限制，并且是系统中的单一故障点。
　　Consul提供与Nagios和Sensu相同的健康检查能力，对现代DevOps友好，并避免了其他系统固有的扩展问题。 Consul在本地运行所有检查，如Sensu，避免给中央服务器造成负担。 检查状态由Consul服务器维护，这是容错的，没有单点故障。 最后，Consul可以扩展到更多的检查，因为它依赖于边缘触发的更新。 这意味着更新仅在检查从“通过”转换为“失败”或反之亦然时才被触发。
　　在一个大型的船队里，大部分的支票都是通过的，连失败的少数人都是执着的。 通过仅捕获更改，Consul减少了运行状况检查所使用的网络和计算资源的数量，从而使系统具有更高的可扩展性。
　　一个精明的读者可能会注意到，如果一个Consul代理死亡，那么没有边缘触发更新将会发生。 从其他节点的角度来看，所有的检查都会显示为稳定状态。 不过，Consul也是这样的。 客户端和服务器之间使用的gossip协议集成了一个分布式故障检测器。 这意味着如果一个Consul代理失败，将会检测到失败，并且因此所有由该节点运行的检查都可以被假定为失败。 这个故障检测器将工作分配到整个集群中，而最重要的是使边缘触发结构能够工作。

4、Consul vs. Eureka

Eureka是一个服务发现工具。 该体系结构主要是客户机/服务器，每个数据中心有一套Eureka服务器，通常每个可用性区域一个。 通常Eureka的客户端使用嵌入式SDK来注册和发现服务。 对于不是本地集成的客户端，使用Ribbon等来透明地发现通过Eureka的服务。
　　Eureka提供了一个弱一致的服务观点，使用尽力而为复制。 当客户端向服务器注册时，该服务器将尝试复制到其他服务器，但不提供保证。 服务注册有一个短的生存时间（TTL），要求客户端向服务器发送心跳。 不健康的服务或节点将停止心跳，使他们超时并从注册表中删除。 发现请求可以路由到任何服务，由于尽力而为的复制，服务可能会陈旧或丢失数据。 这个简化的模型允许简单的集群管理和高可扩展性。
　　Consul提供了一套超级功能，包括更丰富的健康检查，key/value存储以及多数据中心意识。 Consul在每个数据中心都需要一组服务器，每个客户端都有一个代理，类似于使用像Ribbon这样的。 Consul代理允许大多数应用程序成为Consul不知道的，通过配置文件执行服务注册，并通过DNS或负载平衡器sidecars发现。
　　Consul提供强大的一致性保证，因为服务器使用Raft协议复制状态。 Consul支持丰富的健康检查，包括TCP，HTTP，Nagios / Sensu兼容脚本或基于Eureka的TTL。 客户端节点参与基于gossip的健康检查，该检查分配健康检查的工作，而不像集中式心跳一样成为可扩展性挑战。 发现请求被路由到当选的Consul leader，这使得他们在默认情况下是非常一致的。 允许陈旧读取的客户端使得任何服务器能够处理他们的请求，从而允许像Eureka这样的线性可伸缩性。
　　Consul强烈的一致性意味着它可以作为领导选举和集群协调的锁定服务。 Eureka不提供类似的保证，并且通常需要运行ZooKeeper来获得需要执行协调或具有更强一致性需求的服务。
　　Consul提供了支持面向服务的体系结构所需的工具包。 这包括服务发现，还包括丰富的健康检查，锁定，key/value，多数据中心联合，事件系统和ACL。 Consul和consul-template和envconsul等工具的生态系统都尽量减少集成所需的应用程序更改，以避免需要通过SDK进行本地集成。 Eureka是一个更大的Netflix OSS套件的一部分，该套件预计应用程序相对均匀且紧密集成。 因此，Eureka只解决了一小部分问题，希望ZooKeeper等其他工具可以一起使用。