服务发现之Consul

consul是一个可以提供服务发现,健康检查,多数据中心,Key/Value存储等功能的分布式服务框架

用于实现分布式系统的服务发现与配置。与其他分布式服务注册与发现的方案,Consul的方案更"一站式",内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value存储、多数据中心方案,不再需要依赖其他工具(比如ZooKeeper等)。使用起来也较为简单。Consul用Golang实现,因此具有天然可移植性(支持Linux、Windows和Mac OS X);安装包仅包含一个可执行文件,方便部署,与Docker等轻量级容器可无缝配合。

Consul 的使用场景

  • docker 实例的注册与配置共享
  • coreos 实例的注册与配置共享
  • vitess 集群
  • SaaS 应用的配置共享
  • 与 confd 服务集成,动态生成 nginx 和 haproxy 配置文件

Consul 的优势

  • 使用 Raft 算法来保证一致性, 比复杂的 Paxos 算法更直接. 相比较而言, zookeeper 采用的是 Paxos, 而 etcd 使用的则是 Raft.
  • 支持多数据中心,内外网的服务采用不同的端口进行监听。 多数据中心集群可以避免单数据中心的单点故障,而其部署则需要考虑网络延迟, 分片等情况等. zookeeper 和 etcd 均不提供多数据中心功能的支持.
  • 支持健康检查. etcd 不提供此功能.
  • 支持 http 和 dns 协议接口. zookeeper 的集成较为复杂, etcd 只支持 http 协议.
  • 官方提供web管理界面, etcd 无此功能.

综合比较, Consul 作为服务注册和配置管理的新星, 比较值得关注和研究.

Consul 的角色

  • client: 客户端, 无状态, 将 HTTP 和 DNS 接口请求转发给局域网内的服务端集群.
  • server: 服务端, 保存配置信息, 高可用集群, 在局域网内与本地客户端通讯, 通过广域网与其他数据中心通讯. 每个数据中心的 server 数量推荐为 3 个或是 5 个.

Consul 基础组件

  • Agent: 在consul集群上每个节点运行的后台进程,在服务端模式和客户端模式都需要运行该进程。

  • client: 客户端是无状态的,负责把RPC请求转发给服务端, 占用资源和带宽比较少

  • server: 维持集群状态, 相应rpc请求, 选举算法

  • Datacenter:数据中心,支持多个数据中心

  • Consensus:一致性协议

  • Gossip protocol: consul是基于Serf, Serf为成员规则, 失败检测, 节点通信提供了一套协议,

  • LAN Gossip: 在同一个局域网或者数据中心中所有的节点

    Refers to the LAN gossip pool which contains nodes that are all located on the same local area network or datacenter.

  • Server和Client。客户端不存储配置数据,官方建议每个Consul Cluster至少有3个或5个运行在Server模式的Agent,Client节点不限,如下图

consul-framework.png

  1. 支持多个数据中心, 上图有两个数据中心

  2. 每个数据中心一般有3-5个服务器,服务器数目要在可用性和性能上进行平衡,客户端数量没有限制。分布在不同的物理机上

  3. 一个集群中的所有节点都添加到 gossip protocol(通过这个协议进行成员管理和信息广播)中, a客户端不用知道服务地址, b节点失败检测是分布式的, 不用只在服务端完成;c

  4. 数据中心的所有服务端节点组成一个raft集合, 他们会选举出一个leader,leader服务所有的请求和事务, 如果非leader收到请求, 会转发给leader. leader通过一致性协议(consensus protocol),把所有的改变同步(复制)给非leader.

  5. 所有数据中心的服务器组成了一个WAN gossip pool,他存在目的就是使数据中心可以相互交流,增加一个数据中心就是加入一个WAN gossip pool,

  6. 当一个服务端节点收到其他数据中心的请求, 会转发给对应数据中心的服务端。

保持一致性-Raft协议

分布式系统的Raft算法

英文动画演示Raft

Consul Agent 容错

引用内网WIKI

  1. 前提:agent 向 server 发 RPC 请求数据,以目前一个机房 5 台 servers 的部署架构,宕 2 台 servers 对集群无影响。agent 默认的 stale 模式会向任一 server 请求数据,这样只要集群中仍存在 server,而不论其角色是否为 leader 时都能工作。

  2. 重试:RPC 调用失败的话,换另一台 server 再重试一次。

  3. 快照:将缓存数据(无论其是否过期)定期 dump 到本地存储,当 servers 全部宕掉时 agent 可以从本地 snapshot 取数据,以保证尚能返回部分热点数据。

  4. 封禁:agent 给 RPC 调用失败的 servers 扣分,根据不同的分值决定将 servers 封禁一定时长。

  5. 兜底:agent 宕掉的话,客户端尝试直连同集群的其它 agent 返回数据,仍然失败的话,尝试从本地存储中的 snapshot 中取数据。

consul-agent-failover.png

consul灾备方案

引用内网WIKI

定时从consul读取要调用服务的host+port到db或者redis。如果从consul读取有问题并且重试后还有问题,说明consul出现了问题lark通知被调用服务负责人暂时先不要重启该服务以保证存储的服务host:port是最新的。

然后就是怎么从db或者redis在超低延迟以及高并发情况下获取服务的host:port了

此方案瓶颈就是怎么保证低延迟高并发从存储中读取host:port的配置,想了下加cache或者从redis读应该能满足

几种服务发现工具

zookeeper: https://zookeeper.apache.org/

etcd: https://coreos.com/etcd/

consul: https://www.consul.io/

服务发现:Zookeeper vs etcd vs Consul

服务发现之 Etcd VS Consul

参考文献

http://www.liangxiansen.cn/2017/04/06/consul/

我来评几句
登录后评论

已发表评论数()

相关站点

热门文章