consul基础理论知识

Consul是HashiCorp公司推出的开源软件，通过 GO 语言编写，提供服务注册和发现、配置、多数据中心的高可用方案等能力，分布式一致方面采用 raft 算法 实现，并且很容易和 Spring Cloud 等微服务框架集成，使用起来非常的简单，具有简单、易用、可插排等特点。简而言之，Consul 提供了一种完整的服务网格解决方案

Consul功能

●服务发现：Consul的客户端可以向Consul注册服务，例如api服务或者mysql服务，其他客户端可以使用Consul来发现服务的提供者。Consul支持使用DNS或HTTP来注册和发现服务。
●运行时健康检查：Consul客户端可以提供任意数量的运行状况检查机制，这些检查机制可以是给定服务（“是Web服务器返回200 OK”）或本地节点（“内存利用率低于90％”）相关联。这些信息可以用来监控群集的运行状况，服务发现组件可以使用这些监控信息来路由流量，可以使流量远离不健康的服务。
●KV存储：应用程序可以将Consul的键/值存储用于任何需求，包括动态配置，功能标记，协调，领导者选举等。它采用HTTP API使其易于使用。
●安全服务通信：Consul可以为服务生成和分发TLS证书，以建立相互的TLS连接。
●多数据中心：Consul支持多个数据中心。这意味着Consul的用户不必担心构建额外的抽象层以扩展到多个区域。

Consul大概执行流程与原理

每个提供服务的节点都运行了Consul的代理，运行代理不需要服务发现和获取配置的KV键值对，代理只负责监控检查。代理节点可以和一个或者多个Consul server通讯。 Consul服务器是存储和复制数据的地方。服务器本身选出了领导者。虽然Consul可以在一台服务器上运行，但建议使用3到5，以避免导致数据丢失的故障情况。建议为每个数据中心使用一组Consul服务器。

如果你的组件需要发现服务，可以查询任何Consul Server或任何Consul客户端，Consul客户端会自动将查询转发给Consul Server。

需要发现其他服务或节点的基础架构组件可以查询任何Consul服务器或任何Consul代理。代理会自动将查询转发给服务器。每个数据中心都运行Consul服务器集群。发生跨数据中心服务发现或配置请求时，本地Consul服务器会将请求转发到远程数据中心并返回结果。

术语

✓Agent agent：是一直运行在Consul集群中每个成员上的守护进程。通过运行 consul agent 来启动。agent可以运行在client或者server模式。指定节点作为client或者server是非常简单的，除非有其他agent实例。所有的agent都能运行DNS或者HTTP接口，并负责运行时检查和保持服务同步。

✓Client 一个Client是一个转发所有RPC到server的代理。这个client是相对无状态的。client唯一执行的后台活动是加入LAN gossip池。这有一个最低的资源开销并且仅消耗少量的网络带宽。

✓Server：一个server是一个有一组扩展功能的代理，这些功能包括参与Raft选举，维护集群状态，响应RPC查询，与其他数据中心交互WAN gossip和转发查询给leader或者远程数据中心。

✓DataCenter 虽然数据中心的定义是显而易见的，但是有一些细微的细节必须考虑。例如，在EC2中，多个可用区域被认为组成一个数据中心？我们定义数据中心为一个私有的，低延迟和高带宽的一个网络环境。这不包括访问公共网络，但是对于我们而言，同一个EC2中的多个可用区域可以被认为是一个数据中心的一部分。

✓Consensus：在我们的文档中，我们使用Consensus来表明就leader选举和事务的顺序达成一致。由于这些事务都被应用到有限状态机上，Consensus暗示复制状态机的一致性。

✓Gossip：Consul建立在Serf的基础之上，它提供了一个用于多播目的的完整的gossip协议。Serf提供成员关系，故障检测和事件广播。更多的信息在gossip文档中描述。这足以知道gossip使用基于UDP的随机的点到点通信。

✓LAN Gossip 它包含所有位于同一个局域网或者数据中心的所有节点。

✓WAN Gossip：它只包含Server。这些server主要分布在不同的数据中心并且通常通过因特网或者广域网通信。RPC 远程过程调用。这是一个允许client请求server的请求/响应机制。
让我们分解这张图并描述每个部分。首先，我们能看到有两个数据中心，标记为“1”和“2”。Consul对多数据中心有一流的支持并且希望这是一个常见的情况。

在每个数据中心，client和server是混合的。一般建议有3-5台server。这是基于有故障情况下的可用性和性能之间的权衡结果，因为越多的机器加入达成共识越慢。然而，并不限制client的数量，它们可以很容易的扩展到数千或者数万台。

同一个数据中心的所有节点都必须加入gossip协议。这意味着gossip协议包含一个给定数据中心的所有节点。这服务于几个目的：第一，不需要在client上配置server地址。发现都是自动完成的。第二，检测节点故障的工作不是放在server上，而是分布式的。这是的故障检测相比心跳机制有更高的可扩展性。第三：它用来作为一个消息层来通知事件，比如leader选举发生时。

每个数据中心的server都是Raft节点集合的一部分。这意味着它们一起工作并选出一个leader，一个有额外工作的server。leader负责处理所有的查询和事务。作为一致性协议的一部分，事务也必须被复制到所有其他的节点。因为这一要求，当一个非leader得server收到一个RPC请求时，它将请求转发给集群leader。

server节点也作为WAN gossip Pool的一部分。这个Pool不同于LAN Pool，因为它是为了优化互联网更高的延迟，并且它只包含其他Consul server节点。这个Pool的目的是为了允许数据中心能够以low-touch的方式发现彼此。这使得一个新的数据中心可以很容易的加入现存的WAN gossip。因为server都运行在这个pool中，它也支持跨数据中心请求。当一个server收到来自另一个数据中心的请求时，它随即转发给正确数据中想一个server。该server再转发给本地leader。

这使得数据中心之间只有一个很低的耦合，但是由于故障检测，连接缓存和复用，跨数据中心的请求都是相对快速和可靠的。

服务发现和治理

●服务注册

✓当服务Producer启动时，会将自己的信息(IP 和 Port)通过发送请求告知Consul，consul保存服务Producer信息
✓注册方式

1. HTTP API（8500 端口)
2. 配置文件

●服务发现
✓Consul 接收到 Producer 的注册信息后，每隔一段时间会向 Producer 发送一个健康检查的请求，检验Producer是否健康。
●服务调用
✓ 当Consumer请求Product时，会先从Consul中拿到临时表，从临时表中选一个Producer信息(IP和Port)， 然后根据这个IP和Port，发送访问请求。

✓ 临时表(temp table)

1. 只包含通过了健康检查的Producer信息
   1. IP和Port等信息
2. 每隔一段时间会更新

consul节点交互过程

1.选举leader：服务器 Server1、Server2、Server3 上分别部署了 Consul Server, 组成了Consule集群，通过raft选举算法, server2成为leader节点。
2.服务器调用Consul Client进行注册 ：服务器 Server4 和 Server5 上通过 Consul Client 分别注册 Service A、B、C
3.Server节点信息同步：

1. Consul Client将注册信息通过 RPC 转发到 Consul Server
2. 信息保存在 Server 的各个节点中，并且通过 Raft 实现了强一致性。

4.服务调用：服务器 Server6 中 Program D 要访问 Service B
4.1HTTP API 方式：

1. Program D 先访问本机 Consul Client 提供的 HTTP API
2. Consul Client 会将请求转发到 Consul Server。
3. Consul Server 查询到 Service B 并返回给 Program D
4. Program D 拿到了 Service B 的所有部署的 IP 和端口，根据负载均衡策略，选择Service B 的其中一个并向其发起请求。

基础理论知识协议是基于Gossip协议和Raft协议

consul 去中心化思想实现：
✓consul是基于Serf来实现的。
✓Consul使用serf提供的gossip协议来管理成员和广播消息到集群

Serf

1. 基于gossip协议来实现的
2. Serf是一个服务发现，编配工具，它去中心化，不像集中式结构那样统一分配管理。
3. Serf提供成员关系，纠错检查，广播等功能。

Consul中的Gossip

1. Consul使用Gossip协议来管理成员和集群广播消息，这些都是通过使用Serf库的。
2. Serf所使用的Gossip协议基于SWIM（可伸缩的弱一致的感染模式的过程组成员协议），并做了一些细微的修改。
3. Consul用了两种不同的Gossip池。称为LAN池和WAN池。

●LAN池

1. Consul中的每个数据中心有一个LAN池，它包含了这个数据中心的所有成员，包括clients和servers。
2. LAN池用于以下几个目的
   1. 成员关系信息允许client自动发现server, 减少了所需要的配置量。
   2. 分布式失败检测机制使得由整个集群来做失败检测这件事， 而不是集中到几台机器上。
   3. gossip池使得类似领导人选举这样的事件变得可靠而且迅速。

●WAN池

1. WAN池是全局唯一的，所有的server都应该在WAN池中，无论它位于哪个数据中心。
   1. WAN池允许server跨datacenter请求
   2. 集成的故障检测功能使Consul能够优雅地处理整个datacenter失去连接或者或者仅仅是个别的数据中心的某一台失去了连接。
2. 这些特性都是由Serf提供的，用户无需感知。

Consul中的Raft

术语

●Peer set(对等集)

1. 是参与日志复制的所有成员的集合
2. 在Consul中，所有服务器节点都位于本地数据中心的对等集。

● 7.1.2、Quorum（法定人数）

1. Quorum是一个Peer set中的主要成员
2. 对于一个大小为n的集合，Quorum要求至少有(n/2)+1个成员。

●7.1.3、FSM

1. 有限状态机。
2. FSM是有限状态和它们之间的转换的集合。在应用新日志时，允许FSM在状态之间进行转换。相同日志序列的应用必须导致相同的状态，意味着行为必须是确定的。

●7.1.4、log entry

1. Raft系统中的主要工作单元
2. 一致性的问题可以分解为日志备份。
3. log是一个有序的条目序列。如果所有的成员对条目内容和顺序意见一致，那我们就认为日志是一致的。

● 7.1.5、Committed Entry

1. 当一个条目被持久地存储在节点的Quorum中时，它被认为是已经提交的。一旦提交了条目，就可以使用它。

● 7.1.6、Leader

1. 在任何时刻，Peer set都会选举出一个节点来作为leader。
2. leader负责获取新的日志条目，复制到追随者。

Consul中的Raft

✓. Consul中只有server节点会参与Raft算法并且作为peer set中的一部分。所有的client节点会转发请求道server节点。这个设计的部分原因如下

1. 随着更多的成员被添加到对等集，quorum的大小也会增加。这将带来性能问题，因为您可能需要等待数百台机器对条目达成一致，而不是等待少数机器。

2. 当启动时，单个Consul server的模式为bootstrap。

   1. 这个模式允许节点选举自身作为leader。一旦leader选举成功，其他服务器可以以保持一致性和安全性的方式添加到对等集。
   2. 一旦添加了几个服务器，就禁用bootstrap模式。

✓. 由于所有的server都处于对等集合中，它们都知道当前的leader是谁。当RPC到到一个非leader的server上时，请求会被转发到leader。如果PRC是一个只读的请求，leader会根据FSM的当前状态生成结果。如果RPC是一个修改状态的请求，leader会生成一个新的日志条目并使用Raft算法对它进行应用。一旦日志条目提交并且应用于FSM了，转换请求就完成了。

✓. 由于Raft的备份特性，它的性能对网络延迟是很敏感的。出于这个原因，每一个datacenter会选举独立的leader并且维护自己的不相交的对等集合。数据被datacenter进行分区，所以每个leader只负责处理它自己datacenter的数据。当请求被一个远程datacenter接收时，会被转发到正确的leader。

1. 这种设计允许低延迟事务和高可用性，而不牺牲一致性。

●只要有quorum个节点有效，Consensus是容错的。如果有效节点数无法达到的quorum，那么不可能处理log entry或维护成员关系。例如，假设只有2个peer：A和B。quorum也是2，这意味着这两个节点必须同意提交日志条目。如果A或B有一个失败，现在是不可能满足quorum个节点有效的条件。这意味着群集无法添加或删除节点或提交任何额外的日志条目。这样的结果就是集群不可用。这时，需要手动干预，删除A或B，然后以引导模式重新启动剩余节点。

与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。