consul学习

一、consul服务架构和核心概念

在官方提供的图中SERVER是consul服务端高可用集群，CLIENT是consul客户端。

图中存在两个数据中心：DATACENTER1、DATACENTER2。每个数据中心有3-5台server（该数量使得在故障转移和性能之间达到平衡）。

Consul利用两个不同的gossip pool。我们分别把他们称为局域网池(LAN Gossip Pool)或广域网池(WAN Gossip Pool)。每个Consul数据中心（Datacenter）都有一个包含所有成员（Server和Client）的LAN gossip pool。

LAN Pool的目的：

• 成员关系允许Client自动发现Server节点，减少所需的配置量
• 分布式故障检测允许的故障检测的工作在某几个Server几点执行，而不是集中整个集群所有节点上
• gossip允许可靠和快速的事件广播，比如Leader选举

WAN Pool是全局唯一的，无论属于哪一个数据中心，所有Server应该加入到WAN Pool。由WAN Pool提供会员信息让Server节点可以执行跨数据中心的请求。也就是说这个Pool不同于LAN Pool，它的目的是为了允许数据中心能够以low-touch的方式发现彼此。当数据中心的server收到来自不同数据中心的请求时，它可转发请求到数据中心的leader。

二、consul关键特性

服务发现：支持服务发现，可通过DNS或HTTP的方式获取服务信息。

健康检查：支持健康检查，可提供与给定服务相关联的任何数据的健康检查（如web状态码或cpu使用率）

K/V存储：键/值对存储。你可用通过 consul 存储如动态配置之类的相关信息。

多数据中心：支持多数据中心，开箱即用

WEB UI：支持WEB UI，快速了解服务现在的运行情况，一目了然，WEB UI 也是通过 consul agent 启动，只需要再启动的时候加上 -ui

三、consul术语

3.1、Agent

consul 中的核心程序，它将以守护进程的方式在各个节点运行，有 client 和 server 启动模式。每个 agent 维护一套服务和注册发现以及健康信息。

Consul Agent必须运行在在Consul集群的每个节点上。

Agente有两种运行模式：

1. Agent Server

   agent以server模式启动的节点。一个数据中心中至少包含1个server节点。一般建议是3或5个server节点组建成集群，以保证高可用且不失效率。server节点参与Raft、维护会员信息、注册服务、健康检查等功能。

2. Agent Client

   agent以client模式启动的节点。在该模式下，该节点会采集相关信息，通过RPC的方式向server发送。

3.2、数据中心

数据中心，私有的，低延迟的和高带宽的网络环境。一般的多个数据中心之间的数据是不会被复制的，但可用过 ACL replication 或使用外部工具 onsul-replicate。

3.3、Gossip

consul是建立在Serf，它提供了一个完整的gossip协议。

3.4、LAN Gossip

Lan Gossip池，包含位于同一局域网或数据中心上的节点

3.5、WAN Gossip

只包含server的WAN Gossip池，这些服务器主要位于不同的数据中心，通常通过互联网或广域网进行通信

3.6、RPC

远程过程调用。这是一个允许client请求server的请求/响应机制。

四、服务发现和治理

4.1、服务注册

consul支持两种服务注册的方式：

1、通过consul的服务注册http API，由服务自己调用API实现注册。（8500端口）

2、通过json配置文件实现注册，将需要注册的服务以json格式的配置文件给出。

consul官方建议使用第二种方式。

4.2、服务发现

consul支持两种服务发现的方式：

1、通过HTTP API方式，这种方式需要额外编程，适用于不安装consul agent的情况。

2、通过consul agent配置的方式，agent启动的时候会读取一个配置文件目录，通过配置进行服务的发现。

4.3、服务间的通信协议

Consul使用gossip协议管理成员关系、广播消息到整个集群，他有两个gossip pool（LAN pool和WAN pool），LAN pool是同一个数据中心内部通信的，WAN pool是多个数据中心通信的，LAN pool有多个，WAN pool只有一个。

4.4服务调用

当 Consumer 请求Product时，会先从 Consul 中拿到存储Product服务的 IP 和 Port 的临时表(temp table)，从temp table表中任选一个· Producer 的 IP 和 Port， 然后根据这个IP和Port，发送访问请求；temp table表只包含通过了健康检查的 Producer 信息，并且每隔一段时间更新

五、通信接口

5.1、RPC功能

用于内部通讯Gossip/日志分发/选主等

5.2、HTTP API

服务发现/健康检查/KV存储等几乎所有功能, 默认端口为8500

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

consul命令行工具可以与consul agent进行连接，提供部分consul的功能。

实际上Consul CLI 默认就是调用的HTTP API来与consul集群进行通讯。

5.4、DNS

仅用于服务查询

例如: dig @127.0.0.1 -p 8600 web.service.consul

我们可以通过cosul提供的DNS接口来获取当前的服务“web”对应的可用节点

5.5、Consul内部端口使用汇总

• 服务器RPC（默认8300）。这由服务器用来处理来自其他代理的传入请求。仅限TCP。
• Serf LAN（默认8301）。这是用来处理局域网中的八卦。所有代理都需要。TCP和UDP。
• Serf WAN（默认8302）。这被服务器用来在WAN上闲聊到其他服务器。TCP和UDP。从Consul 0.8开始，建议通过端口8302在LAN接口上为TCP和UDP启用服务器之间的连接，以及WAN加入泛滥功能。
• HTTP API（默认8500）。这被客户用来与HTTP API交谈。仅限TCP。
• DNS接口（默认8600）。用于解析DNS查询。TCP和UDP。

5.6、Consul调用过程

1、当 Producer 启动的时候，会向 Consul 发送一个 post 请求，告诉 Consul 自己的 IP 和 Port；
2、Consul 接收到 Producer 的注册后，每隔 10s（默认）会向 Producer 发送一个健康检查的请求，检验 Producer 是否健康；
3、当 Consumer 发送 GET 方式请求 /api/address 到 Producer 时，会先从 Consul 中拿到一个存储服务 IP 和 Port 的临时表，从表中拿到 Producer 的 IP 和 Port 后再发送 GET 方式请求 /api/address；
4、该临时表每隔 10s 会更新，只包含有通过了健康检查的 Producer。

六、consul去中心化思想实现

consul 使用了基于gossip协议的Serf实现，gossip协议主要是基于UDP，实现任意node-to-node间的通信。Consul正是使用serf 提供的gossip协议来管理成员和广播消息到集群。

gossip 协议（gossip protocol）是基于流行病传播方式的节点或者进程之间信息交换的协议，来确保网络中所有节点的数据一样。其中节点间的交互方式主要以下有三种：

Push：发起信息的节点A随机选择联系节点B，并向B发送自己的信息，节点B在收到信息后，更新比自己新的数据，一般拥有新信息的节点才会作为发起节点。

Pull：发起信息的节点A随机选择联系节点B，并从对方获取信息。一般无新信息的节点才会作为发起节点。

Push&Pull：发起信息的节点A向选择的节点B发送信息，同时从对方获取数据，用于更新自己的本地数据

七、consul节点交互过程

首先需要有一个正常的Consul集群，有Server，有Leader。这里在服务器Server1、Server2、Server3上分别部署了Consul Server，假设他们选举了Server2上的Consul Server节点为Leader。这些服务器上最好只部署Consul程序，以尽量维护Consul Server的稳定。

然后在服务器Server4和Server5上通过Consul Client分别注册Service A、B、C，这里每个Service分别部署在了两个服务器上，这样可以避免Service的单点问题。服务注册到Consul可以通过HTTP API（8500端口）的方式，也可以通过Consul配置文件的方式。Consul Client可以认为是无状态的，它将注册信息通过RPC转发到Consul Server，服务信息保存在Server的各个节点中，并且通过Raft实现了强一致性。

最后在服务器Server6中Program D需要访问Service B，这时候Program D首先访问本机Consul Client提供的HTTP API，本机Client会将请求转发到Consul Server，Consul Server查询到Service B当前的信息返回，最终Program D拿到了Service B的所有部署的IP和端口，然后就可以选择Service B的其中一个部署并向其发起请求了。如果服务发现采用的是DNS方式，则Program D中直接使用Service B的服务发现域名，域名解析请求首先到达本机DNS代理，然后转发到本机Consul Client，本机Client会将请求转发到Consul Server，Consul Server查询到Service B当前的信息返回，最终Program D拿到了Service B的某个部署的IP和端口。

八、共识协议(Consensus Protocol)

consul使用 Consensus Protocol（共识协议）来提供一致性（consistency），它基于Raft(In search of an Understandable Consensus Algorithm)

九、Consul中的Raft

Raft是基于Paxos的共识算法。

Raft节点的三种状态：follower(追随者)、candidate(候选者)、leader(领导者)

所有节点最初都是作为follower开始的。在这种状态下，节点可接受leader的日志条目并投票。如果一段时间内没有收到任何条目，则节点会自我提升到candidate。
在candidate状态下，节点请求来自对等节点的投票。如果候选人获得仲裁(quorum)的票数，那么它将被提升为leader。
leader必须接受新的日志条目并复制给其它所有follower。另外，如果陈旧读取不可接受，则所有查询也必须在leader上执行。

一旦集群具有leader，它就能够接受新的日志条目。Client可以请求leader添加新的日志条目。然后，leader将条目持久化，并尝试复制到仲裁的follower。一旦日志条目被认为提交(committed)，它就可以应用于有限状态机(FSM)。

允许复制日志以无限制的方式增长是不可取的。Raft提供了一种机制，可通过快照(snapshot)当前状态并压缩日志。
达成共识是容错的，直到法定人数可用。
建议为每个数据中心配置3-5台Consul Server。3个节点的Raft集群可以容忍单个节点故障，5个节点的Raft集群可以容忍2个节点故障。这可最大限制提高可用性。

只有Consul Server节点参与Raft，并且是Peer set（对等集）的一部分。所有的Client节点都将请求转发给Server。

Consul中的Raft注意点

• 如果RPC是查询(query)类型，意味着它是只读的，则leader根据FSM的当前状态生成结果
• 如果RPC是事务(transaction)类型，意味着它是可修改的，则leader生成新的日志条目并使用Raft应用它

十、Consistency Modes（一致性模式）

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

10.1、default

Raft利用领导租赁，提供领导者认为其角色稳定的时间窗口。但是，如果领导者与剩余的同伴分开，则可以在旧领导者持有租约时选出新的领导者。这意味着有2个领导节点。由于旧的领导者无法提交新的日志，因此不存在裂脑的风险。但是，如果旧的领导者为任何读取提供服务，则这些值可能过时。默认一致性模式仅依赖于领导者租赁，将客户端暴露给可能过时的值。我们做出这种权衡，因为读取速度快，通常强烈一致，并且只在难以触发的情况下过时。由于分区导致领导者下台，因此陈旧读取的时间窗口也是有限的。

10.2、consistent

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

10.3、stale

此模式允许任何服务器为读取服务，无论它是否是领导者。这意味着读取可以是任意陈旧的，但通常在领导者的50毫秒内。权衡是非常快速和可扩展的读取，但具有陈旧的值。此模式允许在没有leader的情况下进行读取，这意味着无法使用的群集仍然可以响应。

十一、Deployment Table（部署表）

下表显示了各种群集大小的仲裁大小和容错能力。 建议的部署是3或5台服务器。 由于在故障情况下数据丢失是不可避免的，因此非常不鼓励单个服务器部署。

十二、Consul中的Gossip（流言传播协议）

Consul 使用gossip协议来管理成员并向集群发送广播信息。所有这些都通过Serf Library提供。

consul使用两个不同的gossip pools：LAN pool,WAN pool

12.1、LAN池

包含本地数据中心内的所有节点，通过成员信息，客户端能够自动发现服务，减少繁琐的配置

12.2、WAN池

数据中心间网际传输，量一般比较少