consul-系统学习-理论
一、Consul是什么?
- 是微服务的插件，使用go语言开发，提供了分布式系统的服务发现与配置管理中心服务。内置了服务注册与发发现、分布式系统的一致性实现、健康检查、Key/Value存储、多数据中心、无需依赖其他工具等，部署简单
二、架构图
有两种运行模式：server 和 client；所有节点也被成为Agent
2.1、架构图分析
- Consul支持多个数据中心，每个数据中心中，我们都有客户机(CLIENT)和服务器(SERVER)，图中有两个数据中心，分别标记为"DATACENTER 1"和"DATACENTER 2" ，每个数据中心官方建议需要3或5个server节点，用于保证数据安全以及server-leader选举能够正常进行
- CLIENT：CLIENT表示consul的客户端模式，该模式下，所有注册到当前节点的服务都会转发到SERVER，自己本身是不会持久化保存这些信息。
- SERVER： SERVER表示consul的服务器模式，功能和CLIENT一样，唯一不同点是，会把所有的信息持久化保存至本地，遇到故障时，这些信息可以被保留。
- server-leader：中间SERVER下面带有LEADER，表明该节点是该数据中心的领导者，主要负责同步注册信息给其他SERVER，同时也负责各节点的健康检测，每个数据中心都有自己的一个LEADER。
- raft：
SERVER节点之间的数据一致性协议使用的是raft - LAN Gossip：指在同一局域网或数据中心的节点上的LAN Gossip池。包含给定数据中心所有的节点。
LAN池用于以下几个目的
- 成员关系信息允许client自动发现server, 减少了所需要的配置量。
- 分布式失败检测机制使得由整个集群来做失败检测这件事， 而不是集中到几台机器上。
- gossip池使得类似领导人选举这样的事件变得可靠而且迅速。
- WAN Gossip：只包含SERVER，这些服务器在不同的数据中心，通过网络进行通信。
- WAN池允许server跨数据中心请求
- 集成的故障检测功能使Consul能够优雅地处理整个datacenter失去连接或者或者仅仅是个别的数据中心的某一台失去了连接。
- RPC：远程过程调用，允许CLIENT请求SERVER的请求响应机制
三、 服务发现和治理
3.1、服务发现协议
1.consul采用http和dns协议
3.2、服务注册
- 当服务Producer启动时，会向consul发送一个post请求,告知Consul自己的IP和port等信息
- 注册方式
- HTTP API（8500 端口)
- 配置文件（json格式），官方建议使用这种
3.3、服务发现
- Consul 接收到 Producer 的注册信息后，每隔一段时间会向 Producer 发送一个健康检查的请求，检验Producer是否健康。
3.3、服务调用
- 当Consumer发送get请求/api/address到Product时，会先从Consul中拿到一个存储服务IP和Port的临时表，从临时表中选一个Producer信息(IP和Port)， 然后根据这个IP和Port，发送访问请求。
- 临时表(temp table)
- 只包含通过了健康检查的Producer信息
- IP和Port等信息
- 每隔一段时间会更新
四、 通信接口
4.1、 RPC功能
用于内部通讯
1. Gossip
2. 日志分发
3. 选主4.2、HTTP API
1. 服务发现
2. 健康检查
3. KV存储等
4. 默认端口为85004.3、Consul Commands (CLI,命令行工具)
1. 可以与consul agent进行连接，提供部分consul的功能。
2. 本质是调用HTTP API4.4、DNS
- 仅用于服务查询，例如
dig @127.0.0.1 -p 8600 web.service.consul
获取当前的服务"web"对应的可用节点4.5、Consul 内部端口使用汇总
五、 consul 去中心化思想实现
- consul是基于Serf来实现的。
- Consul使用serf提供的gossip协议来管理成员和广播消息到集群
5.1、 Serf
- 基于gossip协议来实现的
- Serf是一个服务发现，编配工具，它去中心化，不像集中式结构那样统一分配管理。
- Serf提供成员关系，纠错检查，广播等功能。
5.2、 gossip protocol
- 基于流行病传播方式,实现节点间数据的一致性。
- 节点间的交互方式主要以下有三种
5.2.1、Push
- 节点 A 向节点 B 发送自己的信息，节点 B 在收到信息后，更新比自己新的数据
- 一般拥有新信息的节点才会作为发起节点。
5.2.2、Pull
- 节点 A 连接节点 B ，并从对方获取信息。
- 一般无新信息的节点才会作为发起节点。
5.2.3、Push&Pull
- 节点 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(对等集)
- 参与日志复制的所有服务器节点的集合
- 在Consul中，所有服务器节点都位于本地数据中心的对等集。
8.1.2、Quorum（法定人数）
- Quorum是一个Peer set中的主要成员
- 对于一个大小为n的集合，Quorum要求至少有(n/2)+1个成员。
8.1.3、FSM
- 有限状态机。
- FSM是有限状态和它们之间的转换的集合。在应用新日志时，允许FSM在状态之间进行转换。相同日志序列的应用必须导致相同的状态，意味着行为必须是确定的，就是日志提交的转换请求。
8.2、Consul中的Raft
- 只有server节点会参与Raft算法并且作为peer set中的一部分。
- 当启动时，单个Consul server的模式为bootstrap。
- 这个模式允许节点选举自身作为leader。一旦leader选举成功，其他服务器可以以保持一致性和安全性的方式添加到对等集。
- 一旦添加了几个服务器，就禁用bootstrap模式。
- 由leader负责接收客户端的请求，将日志复制到其他节点，当RPC到到一个非leader的server上时，请求会被转发到leader。
- PRC是一个只读的请求，leader会根据FSM的当前状态生成结果。
- RPC是一个修改状态的请求，leader会生成一个日志条目，使用raft算法进行处理，一旦日志条目提交成功，则表示大多数的服务器节点已更新相关信息。
- 由于Raft的备份特性，它的性能对网络延迟是很敏感的。每一个数据中心会选举独立的leader并且维护自己的服务器节点信息集合。每个leader只负责处理它自己datacenter的数据。当请求被一个远程datacenter接收时，会被转发到正确的leader。
- 这种设计允许低延迟事务和高可用性，而不牺牲一致性。
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的情况下进行读取，这意味着无法使用的群集仍然可以响应。
