Consul实现原理系列文章3: Consul的整体架构

工作中用到了Consul来做服务发现，之后一段时间里，我会陆续发一些文章来讲述Consul实现原理。在前几篇文章介绍完了Consul用到的两个关键性东西Raft和Gossip之后，这篇文章会讲述Consul的整体架构。本文基于一篇别的译文，并做了一些改进和完善。

术语表

1. 代理(agent)：
   代理是Consul集群上每个成员的守护进程，它是由consul agent开始运行。代理能够以客户端或服务器模式运行。由于所有节点都必须运行代理，所以将节点引用为客户端或服务器更为简单，但还有其他实例的代理。所有代理可以运行DNS或HTTP接口，并负责运行检查和保持服务同步。

2. 客户端：
   客户端可以将所有RPC请求转发到服务器的代理。客户端是相对无状态的。客户端执行的唯一后台活动是LANgossip池。它消耗最小的资源开销和少量的网络带宽。

3. 服务器端：
   服务器端是具有扩展的功能的代理，它主要参与维护集群状态，响应RPC查询，与其他数据中心交换WAN gossip ，以及向leader节点或远程数据中心转发查询。

4. 数据中心：
   虽然数据中心的定义似乎很明显，但仍有一些细微的细节必须考虑。比如说，在EC2中，多个可用中心（EC2和AZ是AWS里的概念，不了解的话可以去看看AWS文档）是否应该被人是一个单个的数据中心呢？我们将一个数据中心定义为一个私有、低延迟和高带宽的网络环境,这不包括通过公共互联网的通信。但是为了我们的目的，单个EC2区域内的多个可用区域将被视为单个数据中心的一部分。

5. 一致性 ：