Consul前篇----Consul系统架构简单介绍~

前言：

Consul 是一个复杂的系统，它是HashiCorp公司的一个用于实现分布式系统的服务发现于配置工具，Consul内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value存储、多数据中心方案，同时，Consul具有功能完善，部署简单，使用方便等特点~
这里顺带提一下，Consul是由Go语言开发的，因而也具备了Go语言跨平台，易安装的特点，下载地址：https://www.consul.io/downloads.html。

一、 架构

• 上架构图之前，先解释下一些术语含义，如下~：
• ① Agent ：Agent是长期运行在每个consul集群成员节点上守护进程。通过命令consul agent启动。Agent有client和server两种模式。由于每个节点都必须运行agent，所有节点要么是client要么是server。所有的Agent都可以调用DNS或HTTP API，并负责检查和维护服务同步
• ② client： 运行client模式的Agent，将所有的RPCs转发到Server。Client是相对无状态的。Client唯一所做的是在后台参与LAN gossip pool。只消耗少量的资源，少量的网络带宽。
• ③ Server： 运行Server模式的Agent，参与Raft quorum，维护集群的状态，响应RPC查询，与其他数据中心交互WAN gossip，转发查询到Leader或远程数据中心
• ④ datacenter ：数据中心，定义为：网络环境是私有，低延迟，高带宽的，排除和公网的通信。但有一些细节需要注意，比如在AWS的EC2，多个可用性区域是否被认为组成了单一的数据中心？而数据中心的定义不包括基于公共互联网环境，但是对于我们使用者而言，在同一个EC2的多个可用性区域会被认为是一个的数据中心
• ⑤ Consensus ：consensus，意味着leader election协议，以及事务的顺序。由于这些事务是基于一个有限状态机，consensus的定义意味着复制状态机的一致性。
• ⑥ Gossip ：consul是建立在Serf（去中心化服务发现和编排）之上，提供了完成的Gossip协议（下文会简单介绍此协议），用于成员维护故障检测、事件广播。
  gossip是基于UDP协议实现随机的节点到节点的通信，主要是在UDP。
• ⑦ LAN Gossip：指的是LAN gossip pool，包含位于同一个局域网或者数据中心的节点。
• ⑧ WAN Gossip：指的是WAN gossip pool，只包含server节点，这些server主要分布在不同的数据中心或者通信是基于互联网或广域网的。
• ⑨ RPC：远程过程调用。是允许client请求服务器的请求/响应机制。

1.1 架构图

以上有两个数据中心，分别为Datacenter1和Datacenter2。Consul非常好的支持多个数据中心，每个数据中心内，有客户端和服务器端，服务器一般为3~5个，这样可以在稳定和性能上达到平衡，因为更多的机器会使数据同步很慢。不过客户端是没有限制的，可以有成千上万个。

数据中心内的所有节点都会加入到Gossip协议。这就意味着有一个Gossip池，其中包含这个数据中心所有的节点。客户端不需要去配置服务器地址信息，发现工作会自动完成。检测故障节点的工作不是放在服务器端，而是分布式的；这使得失败检测相对于本地化的心跳机制而言，更具可拓展性。在选择leader这种重要的事情发生的时候，数据中心被用作消息层来做消息广播。

每个数据中心内的服务器都是单个Raft中节点集的一部分。这意味着他们一起工作，选择一个单一的领导者——一个具有额外职责的选定的服务器。leader负责处理所有查询和事物。事物也必须作为同步协议的一部分复制到节点集中的所有节点。由于这个要求，当非leader服务器接收到RPC请求时，就会将请求其转发给集群leader。

服务器端节点同时也作为WAN Gossip池的一部分，WAN池和LAN池不同的是，它针对网络高延迟做了优化，而且只包含其他Consul服务器的节点。这个池的目的是允许数据中心以最少的消耗方式发现对方。启动新的数据中心与加入现有的WAN Gossip一样简单。因为这些服务器都在这个池中运行，它还支持跨数据中心请求。当服务器收到对不同数据中心的请求时，它会将其转发到正确数据中心中的随机服务器。那个服务器可能会转发给本地的leader。

这样会使数据中心的耦合非常低。但是由于故障检测，连接缓存和复用，跨数据中心请求相对快速可靠。

总的来说，数据不会在不同的数据中心之间做复制备份。当收到一个请求处于别的数据中心的资源时，本地的Consul服务器会发一个RPC请求到远端的Consul服务器，然后返回结果。如果远端数据中心处于不可用状态，那么这么资源也会不可用，但这不影响本地的数据中心。在一些特殊的情况下，有限的数据集会被跨数据中心复制备份，比如说Consul内置的ACL复制能力，或者像consul-replicate这样的外部工具。

• 由图可见组件相互通讯的端口不尽相同，这里也简要介绍下各个端口的作用

[root@cs1 bin]# netstat -natp | grep consul
tcp        0      0 192.168.230.130:8300    0.0.0.0:*               LISTEN      2879/consul         
tcp        0      0 192.168.230.130:8301    0.0.0.0:*               LISTEN      2879/consul         
tcp        0      0 192.168.230.130:8302    0.0.0.0:*               LISTEN      2879/consul         
tcp        0      0 127.0.0.1:8500          0.0.0.0:*               LISTEN      2879/consul         
tcp        0      0 127.0.0.1:8600          0.0.0.0:*               LISTEN      2879/consul 

以上5个端口的作用如下：
8300：集群内数据的读写和复制
8301：单个数据中心gossip协议通讯
8302：跨数据中心gossip协议通讯
8500：提供获取服务列表、注册服务、注销服务等HTTP接口；提供UI服务
8600：采用DNS协议提供服务发现功能

二、Gossip协议

• 定义：gosiip协议，顾名思义，就像流言蜚语一样，利用一种随机、带有传染性质的方式，将信息传播到整个网络中，并在一定时间内，使得系统内的所有节点数据一致。对你来说，掌握这个协议不仅能很好地理解这种最常用的，实现最终一致性的算法，也能在后续工作中得心应手地实现数据的最终一致性。
• 三大核心：
• ① 直接邮寄（Direct Mail）
• 就是直接发送更新数据，当数据发送失败时，将数据缓存下来，然后重传。从图中你可以看到，节点 A 直接将更新数据发送给了节点 B、D
• 直接邮寄虽然实现起来比较容易，数据同步也很及时，但可能会因为缓存队列满了而丢数据。也就是说，只采用直接邮寄是无法实现最终一致性的
• ② 反熵（Anti-entropy）
• 而反熵可以实现最终一致性，本质上反熵是一种通过异步修复实现最终一致性的方法。常见的最终一致性系统（比如Cassandra），都实现了反熵功能
• 反熵指的是集群中的节点，每隔段时间就随机选择某个其他节点，然后通过互相交换自己的所有数据来消除两者之间的差异，实现数据的最终一致性
• 执行反熵时，相关的节点都是已知的，而且节点数量不能太多，如果是一个动态变化或节点数比较多的分布式环境（比如在 DevOps 环境中检测节点故障，并动态维护集群节点状态），这时反熵就不适用了
• ③ 谣言传播（Rumor mongering）
• 以上问题，则可以通过“谣言传播“来解决，谣言传播，广泛地散播谣言，它指的是当一个节点有了新数据后，这个节点变成活跃状态，并周期性地联系其他节点向其发送新数据，直到所有的节点都存储了该新数据

小结

• 在实际场景中，实现数据副本的最终一致性时，一般而言，直接邮寄的方式是一定要实现的，因为不需要做一致性对比，只是通过发送更新数据或缓存重传，来修复数据的不一致，性能损耗低。在存储组件中，节点都是已知的，一般采用反熵修复数据副本的一致性。当集群节点是变化的，或者集群节点数比较多时，这时要采用谣言传播的方式，同步更新数据，实现最终一致。

三、服务发现软件

• 这里列举几个服务发现软件及特性对比
  

总结：

• 本片博客为consul 前篇~ 之后会介绍Consul部署和基本使用