@[toc]

1、consul官方架构

  Consul支持多数据中心，在上图中有两个数据中心(DateCenter)，数据中心之间通过Internet互联，为了提高通信效率，只有Server节点才能加入跨数据中心的通信。
  在单个数据中心中，Consul分为Client和Server两种节点(所有的节点被称为Agent)。Server节点保存数据，推荐数量是3个或者5个；Client节点负责健康检查及转发数据请求到Server。
  Server节点包含一个Leader和多个Follower,Leader节点会将数据同步到Follower，在Leader挂掉的时候会启动选举机制产生一个新的Leader。
  集群内的Consul节点通过gossip协议(流言协议)维护成员关系，也就说某个节点俩了解集群内现在还有哪些节点，这些节点是Client还是Server。单个数据中心的流言协议同时使用TCP和UDP通信，并且都使用8301端口。跨数据中心的流言协议也同时使用TCP和UDP通信，端口使用8302.集群内数据的读写请求既可以直接发到Server，也可以通过Client使用RPC转发到Server，请求最终会到达Leader节点，集群内数据的读写和复制都是通过TCP的8300端口完成的。

2、Concul服务发现的完成流程

  服务器Server1、Server2、Server4部署Consul Server集群，Server2上的Consul Server节点为Leader。
  Server4和Server5上通过Consul Client分别注册Service A、B应用服务，每个应用服务分别部署在两个服务器上，这样可以避免应用服务单点问题。服务注册到Consul既可以通过HTTP API(8500端口)的方式，也可以通过Consul配置文件的方式。Consul Client是无状态的，它将注册信息通过RPC转发到Consul Server,服务信息保存在Server的各个节点中，并且通过Raft实现了强一致性。
  假设服务器Server6中的ServerD需要访问ServiceB，就先访问本机Consul Client提供的HTTP API，本机Client会将请求转发到Consul Server。Consul Server查询到Service B当前的信息，最终ServerD拿到ServiceB所有部署的IP和端口，选择ServiceB中的一个应用服务并向其发起请求。
  如果服务发现采用的是DNS方式，则ServiceD中直接使用ServiceB的服务发现域名，域名解析请求首先到达本机DNS代理，然后转发到本机Consul Client，本机Client会将请求转发到Consul Server。
  Consul Server查询到Service B当前的信息返回，最终Service D拿到Service B某个部署的IP和端口。