Consul 介绍

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

Consul 是一个分布式，高可用的系统。 为了快速了解Consul的工作原理，本节只介绍基础知识，不会介绍详细的细节。

向Consul提供服务的每个节点都运行一个Consul代理。 发现其他服务或获取/设置键/值数据不需要运行代理。 代理负责健康检查节点上的服务以及节点本身。

代理与一个或多个Consul服务器通信。Consul 服务器是数据存储和复制的地方。 服务器自己选出一个 leader。 虽然Consul可以在一台服务器上运行，但推荐使用3到5台来避免数据丢失的情况。 每个数据中心都建议使用一组Consul服务器。

需要发现其他服务或节点的基础架构组件可以查询任何Consul服务器或任何Consul代理。 代理自动将查询转发到服务器。

每个数据中心都运行Consul服务器集群。 当跨数据中心服务发现或配置请求时，本地Consul服务器将请求转发到远程数据中心并返回结果。

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

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，以获得完整的服务发现解决方案，而完全没有任何开发。

使用Chef，Puppet和其他配置管理工具的人来构建服务发现机制并不罕见。 这通常通过查询全局状态来在定期收敛运行期间在每个节点上构建配置文件来完成。

不幸的是，这种方法有一些陷阱。 配置信息是静态的，不能比收敛运行更频繁地更新。 一般这是在几分钟或几小时的间隔。 另外，没有机制将系统状态结合到配置中：不健康的节点可能进一步接收流量，进一步加剧问题。 使用这种方法还可以支持多个数据中心，因为中央服务器组必须管理所有数据中心。

Consul专门设计为服务发现工具。 因此，它对集群的状态更具有动态性和响应性。 节点可以注册和注销他们提供的服务，使得依赖的应用程序和服务能够快速发现所有提供者。 通过使用集成的健康检查，Consul可以将流量从不健康的节点发送出去，从而使系统和服务能够正常恢复。 可以通过配置管理工具提供的静态配置可以移动到动态键/值存储中。 这允许应用程序配置更新，而不会收敛缓慢。 最后，由于每个数据中心独立运行，支持多个数据中心与单个数据中心没有区别。

也就是说，Consul并不是配置管理工具的替代品。 这些工具对于设置应用程序（包括Consul本身）至关重要。 静态配置最好由现有工具管理，而动态状态和发现则由Consul更好地管理。 配置管理和集群管理的分离也有一些有利的副作用：Chef和Puppet在没有全局状态的情况下变得更简单，服务或配置更改不再需要定期运行，并且由于配置管理运行 不需要全局状态。

Nagios和Sensu都是用于监控的工具。 当问题发生时，它们用于快速通知操作员。

Nagios使用一组配置为在远程主机上执行检查的中央服务器。 这种设计使Nagios难以规模化，因为大型船队迅速达到垂直尺度的限制，Nagios不容易水平缩放。 Nagios在现代DevOps和配置管理工具中也非常难以使用，因为在添加或删除远程服务器时必须更新本地配置。

Sensu有一个更现代化的设计，依靠当地的代理商运行支票，并推动结果AMQP经纪人。 许多服务器从代理获取并处理健康检查的结果。 这个模型比Nagios更具可扩展性，因为它允许更多的水平缩放和服务器和代理之间的较弱耦合。 但是，中央经纪人已经具有扩展限制，并且是系统中的单一故障点。

Consul提供与Nagios和Sensu相同的健康检查能力，对现代DevOps友好，并避免了其他系统固有的扩展问题。 Consul在本地运行所有检查，如Sensu，避免给中央服务器造成负担。 检查状态由Consul服务器维护，这是容错的，没有单点故障。 最后，Consul可以扩展到更多的检查，因为它依赖于边缘触发的更新。 这意味着更新仅在检查从“通过”转换为“失败”或反之亦然时才被触发。

在一个大型的船队里，大部分的支票都是通过的，连失败的少数人都是执着的。 通过仅捕获更改，Consul减少了运行状况检查所使用的网络和计算资源的数量，从而使系统具有更高的可扩展性。

一个精明的读者可能会注意到，如果一个Consul代理死亡，那么没有边缘触发更新将会发生。 从其他节点的角度来看，所有的检查都会显示为稳定状态。 不过，Consul也是这样的。 客户端和服务器之间使用的gossip协议集成了一个分布式故障检测器。 这意味着如果一个Consul代理失败，将会检测到失败，并且因此所有由该节点运行的检查都可以被假定为失败。 这个故障检测器将工作分配到整个集群中，而最重要的是使边缘触发结构能够工作。

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等其他工具可以一起使用。

仲裁盘一般要放在共享存储上，保证两个节点都能访问到。如果是自己做实验的话，可以放在某一个节点的一个分区上，但是要保证另一个节点可以访问该分区。如果是企业级应用，那么最保险的就是放在共享存储上。

仲裁是数据库镜像会话中两个或多个服务器实例彼此连接时存在的一种关系。仲裁通常包括三个互连的服务器实例。设置见证服务器时，必须具有仲裁才能使用数据库。仲裁旨在用于具有自动故障转移功能的高安全性模式，可确保一个数据库一次只属于一个伙伴。 如果特定的服务器实例与镜像会话断开连接，则该实例将失去仲裁。如果没有连接任何服务器实例，则会话将失去仲裁，并无法使用数据库。可以进行的仲裁有三种： “完全仲裁”包含伙伴双方以及见证服务器。

“见证服务器-伙伴仲裁”包含见证服务器和一个伙伴。

“伙伴-伙伴仲裁”包含伙伴双方。

下图显示了这三种类型的仲裁。只要当前的主体服务器具有仲裁，它就拥有主体服务器的角色并可继续操作数据库，除非数据库所有者执行手动故障转移。如果主体服务器失去仲裁，它将停止操作数据库。仅当主体服务器失去仲裁时，才会发生自动故障转移，这确保它不再操作数据库。 断开连接的服务器实例将保存其在会话中的最新角色。通常，断开连接的服务器实例将在重新启动并重新获得仲裁时重新连接到会话。 重要提示： 只有在需要使用具有自动故障转移功能的高安全性模式时，才应设置见证服务器。在高性能模式下，由于从不需要见证服务器，因此极力建议将 WITNESS 属性设置为 OFF。有关见证服务器如何影响高性能模式会话中数据库可用性的信息，请参阅异步数据库镜像（高性能模式）。

高安全性模式会话中的仲裁在高安全性模式下，仲裁通过提供上下文来允许自动故障转移，在这个上下文中，具有仲裁的服务器实例可以判定哪个伙伴拥有主体服务器角色。主体服务器如果具有仲裁就可以操作数据库。如果在同步的镜像服务器和见证服务器仍具有仲裁的时候主体服务器丢失仲裁，则会发生自动故障转移。 高安全性模式的仲裁方案包括： 包含伙伴双方和见证服务器的“完全仲裁”。

所有三个服务器实例通常都参与三方仲裁，这称为“完全仲裁”。使用完全仲裁，主体服务器和镜像服务器一直执行其各自的角色（除非发生手动故障转移）。

包含见证服务器和一个伙伴的“见证服务器-伙伴仲裁”。

如果因为其中一个伙伴丢失而中断伙伴之间的网络连接，则可能发生下列两种情况：

镜像服务器丢失，主体服务器和见证服务器仍具有仲裁。

在这种情况下，主体服务器将数据库设置为 DISCONNECTED，并在镜像处于 SUSPENDED 状态的情况下运行。（因为数据库当前尚未镜像，所以这称为“公开运行”。）镜像服务器重新联接会话时，它将作为镜像服务器重新获得仲裁，并开始与其数据库副本重新同步。

主体服务器丢失，见证服务器和镜像服务器仍具有仲裁。

在这种情况下，发生自动故障转移。有关详细信息，请参阅自动故障转移。

两个伙伴与见证服务器之间保持连接时，故障转移伙伴之间的网络连接很少会断开。在这种情况下，存在两个分开的见证服务器-伙伴仲裁，见证服务器作为连接。见证服务器将通知镜像服务器：主体服务器仍在连接状态。因此，不会出现自动故障转移。而镜像服务器将保留镜像角色并等待重新连接到主体服务器。如果此时重做队列包含日志记录，镜像服务器将继续前滚镜像数据库。重新连接后，镜像服务器将与镜像数据库重新同步。

包含伙伴双方的“伙伴-伙伴仲裁”。

只要伙伴仍具有仲裁，数据库就会继续处于 SYNCHRONIZED 状态，手动故障转移就可以进行。如果没有见证服务器，则无法使用自动故障转移功能；但当见证服务器重新获得仲裁时，会话将恢复正常操作，并重新支持自动故障转移。

会话丢失仲裁。

如果所有服务器实例此间的连接断开，就称为会话“丢失仲裁”。当服务器实例恢复彼此间的连接时，它们将重新获得相互仲裁。

如果主体服务器与其他服务器实例中的任何一个重新连接，即可使用数据库。

如果主体服务器依旧断开连接，但镜像服务器和见证服务器恢复了相互之间的连接，则不能进行自动故障转移，因为可能会丢失数据。因此，在主体服务器重新加入会话之前，依旧不能使用数据库。

当三个服务器实例全部恢复连接时，将重新获得完全仲裁，会话将恢复其正常操作。

重要提示： 当会话具有伙伴-伙伴仲裁时，如果任一伙伴失去仲裁，会话将失去仲裁。因此，如果您希望见证服务器在很长一段时间内保持断开，我们建议您暂时将见证服务器从会话中删除。如果删除见证服务器，则不再需要仲裁。然后，如果镜像服务器断开连接，则主体服务器可以继续操作数据库。有关如何添加或删除见证服务器的信息，请参阅数据库镜像见证服务器。

仲裁如何影响数据库可用性下图显示的是见证服务器与伙伴如何相互作用，以确保在给定时间内，只有一个伙伴拥有主体服务器角色并且只有当前主体服务器才能使其数据库在线。两个方案都以完全仲裁（Partner_A 具有主体角色，Partner_B 具有镜像角色）为起点。方案1 显示的是：在原始主体服务器 (Partner_A) 失败后，见证服务器和镜像服务器如何同时认定主体 Partner_A 不再可用并构造仲裁。然后，镜像服务器 Partner_B 承担主体角色。出现自动故障转移时，Partner_B 使其数据库副本在线。然后 Partner_B 出现故障，数据库离线。随后，先前的主体服务器 Partner_A 重新连接到见证服务器重新获取仲裁，但是通过与见证服务器通信，Partner_A 获知不能使其数据库副本在线，因为 Partner_B 现在拥有主体角色。当 Partner_B 重新加入会话时，将使数据库恢复在线。在方案 2 中，见证服务器丢失仲裁，而伙伴 Partner_A 和Partner_B 彼此保留仲裁，数据库保持在线。然后，伙伴们也失去其仲裁，数据库处于离线状态。随后，主体服务器 Partner_A 重新连接到见证服务器以重新获取仲裁。见证服务器确认 Partner_A 仍拥有主体角色，并且 Partner_A 使数据库恢复在线。

---