consul-系统学习-理论

consul-系统学习-理论

---

一、Consul是什么?

1. 是微服务的插件，使用go语言开发，提供了分布式系统的服务发现与配置管理中心服务。内置了服务注册与发发现、分布式系统的一致性实现、健康检查、Key/Value存储、多数据中心、无需依赖其他工具等，部署简单

二、架构图

有两种运行模式：server 和 client；所有节点也被成为Agent

2.1、架构图分析

1. Consul支持多个数据中心，每个数据中心中，我们都有客户机(CLIENT)和服务器(SERVER)，图中有两个数据中心，分别标记为"DATACENTER 1"和"DATACENTER 2" ，每个数据中心官方建议需要3或5个server节点，用于保证数据安全以及server-leader选举能够正常进行

2. CLIENT：CLIENT表示consul的客户端模式，该模式下，所有注册到当前节点的服务都会转发到SERVER，自己本身是不会持久化保存这些信息。

3. SERVER： SERVER表示consul的服务器模式，功能和CLIENT一样，唯一不同点是，会把所有的信息持久化保存至本地，遇到故障时，这些信息可以被保留。

4. server-leader：中间SERVER下面带有LEADER，表明该节点是该数据中心的领导者，主要负责同步注册信息给其他SERVER，同时也负责各节点的健康检测，每个数据中心都有自己的一个LEADER。

5. raft：
   SERVER节点之间的数据一致性协议使用的是raft

6. LAN Gossip：指在同一局域网或数据中心的节点上的LAN Gossip池。包含给定数据中心所有的节点。

   LAN池用于以下几个目的

   1. 成员关系信息允许client自动发现server, 减少了所需要的配置量。
   2. 分布式失败检测机制使得由整个集群来做失败检测这件事， 而不是集中到几台机器上。
   3. gossip池使得类似领导人选举这样的事件变得可靠而且迅速。

7. WAN Gossip：只包含SERVER，这些服务器在不同的数据中心，通过网络进行通信。

   1. WAN池允许server跨数据中心请求
   2. 集成的故障检测功能使Consul能够优雅地处理整个datacenter失去连接或者或者仅仅是个别的数据中心的某一台失去了连接。

8. RPC：远程过程调用，允许CLIENT请求SERVER的请求响应机制

三、 服务发现和治理

3.1、服务发现协议

1.consul采用http和dns协议

3.2、服务注册

1. 当服务Producer启动时，会向consul发送一个post请求,告知Consul自己的IP和port等信息

2. 注册方式

   1. HTTP API（8500 端口)
   2. 配置文件（json格式），官方建议使用这种

3.3、服务发现

1. Consul 接收到 Producer 的注册信息后，每隔一段时间会向 Producer 发送一个健康检查的请求，检验Producer是否健康。

3.3、服务调用

1. 当Consumer发送get请求/api/address到Product时，会先从Consul中拿到一个存储服务IP和Port的临时表，从临时表中选一个Producer信息(IP和Port)， 然后根据这个IP和Port，发送访问请求。

2. 临时表(temp table)

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

四、 通信接口

4.1、 RPC功能

用于内部通讯

1. Gossip
2. 日志分发
3. 选主

4.2、HTTP API

1. 服务发现
2. 健康检查
3. KV存储等
4. 默认端口为8500

4.3、Consul Commands (CLI,命令行工具)

1. 可以与consul agent进行连接，提供部分consul的功能。
2. 本质是调用HTTP API

4.4、DNS

1. 仅用于服务查询，例如

    dig @127.0.0.1 -p 8600 web.service.consul
   
    获取当前的服务"web"对应的可用节点
   

4.5、Consul 内部端口使用汇总

五、 consul 去中心化思想实现

1. consul是基于Serf来实现的。
2. Consul使用serf提供的gossip协议来管理成员和广播消息到集群

5.1、 Serf

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

5.2、 gossip protocol

1. 基于流行病传播方式,实现节点间数据的一致性。
2. 节点间的交互方式主要以下有三种

5.2.1、Push

1. 节点 A 向节点 B 发送自己的信息，节点 B 在收到信息后，更新比自己新的数据
2. 一般拥有新信息的节点才会作为发起节点。

5.2.2、Pull

1. 节点 A 连接节点 B ，并从对方获取信息。
2. 一般无新信息的节点才会作为发起节点。

5.2.3、Push&Pull

1. 节点 A 连接节点 B ，AB节点同时从对方获取数据，用于更新自己的本地数据。

六、 consul节点交互过程

图中是一个正常的consul集群，有SERVER和LEADER。Server1/Server2/Server3分别部署了consul server ，server2为LEADER。这些服务器上只部署consul程序以便于维护consul server的稳定

在服务器Server4/Server5上通过consul client分别注册Service A/B/C，每个Service分别部署在两个服务器上，避免单点问题，Server4/Server5将注册信息转发到consul server，服务信息保存在Server1/Server2/Server3节点中，通过raft实现数据一致性

Server6 中 Program D 要访问 Service B，这时Program D 首先访问本机consul client提供的HTTP API，本机consul client将请求转发到consul server，consul server查询到Service B当前的信息返回，获取到了Service B的所有部署的 IP 和端口，根据负载均衡策略，选择Service B 的其中一个并向其发起请求。

七、共识协议(Consensus Protocol)

基于raft协议实现数据的一致性

八、Consul中的Raft

8.1、术语

8.1.1、Peer set(对等集)

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

8.1.2、Quorum（法定人数）

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

8.1.3、FSM

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

8.2、Consul中的Raft

1. 只有server节点会参与Raft算法并且作为peer set中的一部分。

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

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

3. 由leader负责接收客户端的请求，将日志复制到其他节点，当RPC到到一个非leader的server上时，请求会被转发到leader。

   1. PRC是一个只读的请求，leader会根据FSM的当前状态生成结果。
   2. RPC是一个修改状态的请求，leader会生成一个日志条目，使用raft算法进行处理，一旦日志条目提交成功，则表示大多数的服务器节点已更新相关信息。

4. 由于Raft的备份特性，它的性能对网络延迟是很敏感的。每一个数据中心会选举独立的leader并且维护自己的服务器节点信息集合。每个leader只负责处理它自己datacenter的数据。当请求被一个远程datacenter接收时，会被转发到正确的leader。

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

8.3、Consul中的Raft注意点

只要有大多数[(n/2)+1]服务器节点有效，Consensus是容错的。如果有效节点数无法达到的大多数，那么日志条目就不会被提交处理。
Consul server服务器节点基本是奇数个来保证正常选举leader

九、Consistency Modes（一致性模式）

Consul支持3种不同的读取一致性模式：default、consistent、stale

9.1、default

默认一致性模式仅依赖于领导者租赁，将客户端暴露给可能过时的值。类似于网络分区情况。

9.2、consistent

强烈一致性模式：要求领导者与法定人数确认它仍然是领导者。这为所有服务器节点引入了额外的往返。由于额外的往返，权衡总是一致读取但延迟增加。

9.3、stale

此模式允许任何服务器为读取服务，无论它是否是领导者。这意味着读取可以是任意陈旧的数据，但通常在领导者的50毫秒内。权衡是非常快速和可扩展的读取，但具有陈旧的值。

此模式允许在没有leader的情况下进行读取，这意味着无法使用的群集仍然可以响应。