微服务注册和发现组件之consul

     上一篇文章提到服务发现的组件Eureka，大概介绍了他的原理和架构。除此之外还有很多提供类似服务发现和注册的技术组件，本篇重点讲述consul。

      Consul 是 HashiCorp 公司推出的开源工具，用于实现分布式系统的服务发现与配置。与其他分布式服务注册与发现的方案，Consul的方案更“一站式”，内置了服务注册与发现框 架、分布一致性协议实现、健康检查、Key/Value存储、多数据中心方案，不再需要依赖其他工具（因为内置raft协议）。

      借用官方的架构图，整体浏览一下他的架构思想。

     

有图中可知，此架构是双数据中心互备架构，也就是consul有支持多数据中心的特性，数据中心中的所有节点都遵守GOSSIP协议。首先看数据中心1，可以看出consul的集群是由N个SERVER，加上M个CLIENT组成的。而不管是SERVER还是CLIENT，都是consul的一个节点，所有的服务都可以注册到这些节点上，正是通过这些节点实现服务注册信息的共享。client负责接收客户端的服务注册请求，Server负责持久化服务元信息，同时多个server之间通过复制协议备份服务元信息。

• CLIENT

CLIENT表示consul的client模式，就是客户端模式。是consul节点的一种模式，这种模式下，所有注册到当前节点的服务会被转发到SERVER，本身是不持久化这些信息。但是客户端可以缓存服务注册信息，提高注册中心的性能和可靠性。CONNECT证书和意图允许客户端代理在不需要往返服务器的情况下对入站连接请求进行本地决策。 一些api端点还支持可选的结果缓存。 这有助于提高可靠性，因为client agent 可以继续响应外部查询请求（如服务发现）或从缓存连接授权，即使到服务器的连接中断或服务器暂时不可用也不会影响consul作为注册中心的可用性。 

• SERVER

SERVER表示consul的server模式，表明这个consul是个server，这种模式下，功能和CLIENT都一样，唯一不同的是，它会把所有的信息持久化的本地，这样遇到故障，信息是可以被保留的。

• SERVER-LEADER

server集群中有主从角色区分，图中标识的leader身份的节点是SERVER集群的主节点，它和其它SERVER不一样的一点是，它需要负责通过复制协议同步注册的服务元信息给其它的SERVER，同时也要负责各个节点的健康监测。领导负责处理所有的查询和事务，leader节点还必须将事务复制到所有对等点，作为协商一致协议的一部分。 由于这一原则要求，当非主服务器收到rpc请求时，它会将其转发给集群主节点。 

• LAN-GOSSIP

    Gossip是一个带冗余的容错算法，更进一步，Gossip是一个最终一致性算法。图中标识LAN-GOSSIP的通信所有节点位于同一局域网或数据中心。

WAN-GOSSIP

图中标识LAN-GOSSIP的通信所有节点只包含服务器节点，这些服务器主要位于不同的数据中心，通常通过因特网或广域网进行通信。将一个新的数据中心上线，就像加入现有的WAN-GOSSIP Pool一样容易。因为服务器都在WAN-GOSSIP Pool中运行，所以它还启用了跨数据中心请求。比如，当数据中心1的serverA收到对数据中心2的请求时，它会将其转发到数据中心2中的随机服务器X。然后，该服务器X可以转发给本数据中心内部的server leader节点处理请求。其实这个设计策略导致数据中心之间的耦合非常低，有利于扩容且互不影响，而且由于不同数据中心之间有故障检测、连接缓存和多路复用技术支持，跨数据中心请求相对快速和可靠。 

上述大概介绍注册中心consul的整体架构和设计思想，具体细节后续深入分析，至于如何部署使用和配置大家可以参考其他博客！