工作中用到了Consul来做服务发现,之后一段时间里,我会陆续发一些文章来讲述Consul实现原理。在前几篇文章介绍完了Consul用到的两个关键性东西Raft和Gossip之后,这篇文章会讲述Consul的整体架构。本文基于一篇别的译文,并做了一些改进和完善。
术语表
代理(agent):
代理是Consul集群上每个成员的守护进程,它是由consul agent开始运行。代理能够以客户端或服务器模式运行。由于所有节点都必须运行代理,所以将节点引用为客户端或服务器更为简单,但还有其他实例的代理。所有代理可以运行DNS或HTTP接口,并负责运行检查和保持服务同步。客户端:
客户端可以将所有RPC请求转发到服务器的代理。客户端是相对无状态的。客户端执行的唯一后台活动是LANgossip池。它消耗最小的资源开销和少量的网络带宽。服务器端:
服务器端是具有扩展的功能的代理,它主要参与维护集群状态,响应RPC查询,与其他数据中心交换WAN gossip ,以及向leader节点或远程数据中心转发查询。数据中心:
虽然数据中心的定义似乎很明显,但仍有一些细微的细节必须考虑。比如说,在EC2中,多个可用中心(EC2和AZ是AWS里的概念,不了解的话可以去看看AWS文档)是否应该被人是一个单个的数据中心呢?我们将一个数据中心定义为一个私有、低延迟和高带宽的网络环境,这不包括通过公共互联网的通信。但是为了我们的目的,单个EC2区域内的多个可用区域将被视为单个数据中心的一部分。一致性 :