consul学习0415

一、架构图

 

• Consul支持多个数据中心，在每个数据中心中，都有客户机(CLIENT)和服务器(SERVER)。（图中两个数据中心，分别标记为"DATACENTER 1"和"DATACENTER 2"）

               服务区端一般为3~5个（因为更多的机器会使数据同步很慢，一致性会很慢）
              客户端是没有限制的，可以有成千上万个。

• 数据中心到所有节点都使用的时候Gossip协议。这就意味着有一个Gossip池，其中包含给定数据中心所有的节点。
• 每个数据中心都是都是单个Raft对等设备的一部分。它们一起工作来选举单个leader
• leader额外的职责 ：负责处理所有查询和事物。
• 服务器端节点作为WANGossip池的一部分运行，WAN池和LAN池不同的是，针对网络高延迟做了优化，而且只包含其他Consul服务器的节点。

               WANGossip池的目的是允许数据中心以最少的消耗方式发现对方。在线启动新的数据中心与加入现有的WAN Gossip一样简单。

               因为这些服务器都在这个池中运行，它还支持跨数据中心请求。
               当服务器收到对不同数据中心的请求时，它会将其转发到正确数据中心中的随机服务器。那个服务器可能会转发给本地的leader。

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

 

二、使用场景

• 服务发现场景

    consul作为注册中心，服务地址被注册到consul以后，可以使用consul提供的dns、http接口查询
    consul支持health check。

• 服务隔离场景

    consul支持以服务为单位设置访问策略，能同时支持经典的平台和新兴的平台
    支持tls证书分发
    支持service-to-service加密。

• 服务配置场景

    consul提供key-value数据存储功能，并且能将变动迅速地通知出去。
    Consul可以实现配置共享，从Consul中读取配置信息。
 

 三、服务发现和治理

• 服务注册

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

    注册方式
        HTTP API（8500 端口)
        配置文件

• 服务发现

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

• 服务调用

    当Consumer请求Product时，会先从Consul中拿到临时表，从临时表中选一个Producer信息(IP和Port)， 然后根据这个IP和Port，发送访问请求。

    临时表(temp table)
        只包含通过了健康检查的Producer信息
            IP和Port等信息
        每隔一段时间会更新

四、 通信接口

 

•  RPC功能。用于内部通讯，如下：1. Gossip2. 日志分发3. 选主
• HTTP API。场景：服务发现、健康检查、KV存储等，默认端口为8500
• Consul Commands (CLI,命令行工具)。场景：1. 可以与consul agent进行连接，提供部分consul的功能。2. 本质是调用HTTP API
• DNS。仅用于服务查询，例如：dig @127.0.0.1 -p 8600 web.service.consul，获取当前的服务"web"对应的可用节点      
• 3.5、Consul 内部端口使用汇总

• Consul 请求调用链路（看架构图）

五、 consul 去中心化思想实现

•     consul是基于Serf来实现的。

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

 

•     Consul使用serf提供的gossip协议来管理成员和广播消息到集群

     gossip protocol基于流行病传播方式,实现节点间信息交换，来确保网络中所有节点的数据一样。

     节点间的交互方式主要以下有三种（Push、Pull、Push&Pull）

 

六、 consul节点交互过程

1.服务器 Server1、Server2、Server3 上分别部署了 Consul Server, 组成了Consule集群，选举leader（通过raft选举算法, server2成为leader节点）。

2.服务器 Server4 和 Server5 上通过 Consul Client 分别注册 Service A、B、C

3.Server节点信息同步，  Consul Client将注册信息通过 RPC 转发到 Consul Server，信息保存在 Server 的各个节点中（通过 Raft 实现了强一致性）。

4.服务调用，服务器 Server6 中 Program D 要访问 （HTTP API 方式）Service B，按以下过程：

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

七、共识协议(Consensus Protocol)

基于raft协议

raft协议是分布式系统开发首选的共识算法
Raft算法是经过一切以领导者为准的方式，实现一系列值的共识和各节点日志的一致。
用于管理日志一致性的协议。
将分布式一致性分解为多个子问题：

    Leader选举(Leader election)
    日志复制(Log replication)
    安全性(Safety)
    日志压缩(Log compaction)
 

八、Consul中的Raft

    Consul中只有server节点会参与Raft算法并且作为peer set中的一部分。所有的client节点会转发请求道server节点。这个设计的部分原因如下
        随着更多的成员被添加到对等集，quorum的大小也会增加。这将带来性能问题，因为您可能需要等待数百台机器对条目达成一致，而不是等待少数机器。

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

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

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

• Consul中的Raft注意点

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

九、Consistency Modes（一致性模式）

 

Consul支持3种不同的读取一致性模式。分别如下

三种读取模式是：

• default

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

由于分区导致领导者下台，因此陈旧读取的时间窗口也是有限的。

• consistent

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

• stale

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

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

十、Deployment Table（部署表）

 

3个节点的Raft集群可以容忍1个节点故障，5节点的集群可以容忍2个节点的故障。因此，Consul推荐部署包含3或5个Server节点的数据中心。这样可以最大限度地提高可用性，而不会大大牺牲性能。下面的表格总结了集群节点数目与容忍的故障节点数目：

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

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

• LAN池

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

• WAN池

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