Consul中文文档—Consul作为注册中心场景下的高可用分析

转载请注明🙂，喜欢请一键三连哦 😊

系列文章目录

Consul专栏—Consul工作原理及落地实践

文章目录

• 系列文章目录
• 前言
• 一、Consul故障场景
• • 1.1 单Follower Server节点故障
  • 1.2 Leader Server节点故障
  • 1.3 超过法定节点（Quorum： n/2 + 1) 故障
• 二、Consul压力分析
• • 2.1 JSF应用（京东商城内部RPC框架,类似Dubbo）
  • 2.2 SpringCloud应用
• 三、如何保持Consul作为注册中心场景地高可用？
• • 3.1 Consul集群高可用
  • 3.2 客户端容灾

前言

使用Consul作为注册中心场景下， 在高可用方面需要做哪些考虑，本篇将Consul节点故障场景和压力来源场景做一个分析， 并给出一些自己的见解和建议。

一、Consul故障场景

1.1 单Follower Server节点故障

含有Client Node架构中，这种场景是不受影响的

1.2 Leader Server节点故障

Leader节点不可用的话， 重新选主， 集群写功能短暂不可用。 选主期间，读能力取决于Consul一致性模型设置。

1.3 超过法定节点（Quorum： n/2 + 1) 故障

集群不可用

二、Consul压力分析

Consul压力来源主要三个放面， 写能力，读能力，服务数支持能力（健康检查压力， 同步压力），下面分析几个框架的从压力情况。

场景：

应用情况： 3000个应用，三个实例，依赖对外3个服务;

Consul集群情况： 3节点, 2C2g

2.1 JSF应用（京东商城内部RPC框架,类似Dubbo）

• 查询压力： 3000应用 ， 3服务实例 ， 依赖 3个其他服务，自身暴露 3个服务， 30S 查询一次； 总共Watch压力为： 1800 qps, 查询依赖压力为： 3000 * 3 * 3/ 30s = 900 qps，自身注册情况查询 3000 * 3 *3/30s = 900 qps；
• 写压力： 同时注册能力
• 健康检查压力： 3000 * 3/10s = 9000；
• 同步压力： 9000服务实例

2.2 SpringCloud应用

场景： 默认参数， 保持2s长轮询 ， 1s 延迟， 假设 3000， 3个实例的话 。

• 查询压力： 3000 * 3 = 9000， 但是一个应用一个周期，仅查询1次， watch catalog service index 是否变更。
• 写能力： 同时注册能力
• 健康检查压力： 9000/10s = 900
• 同步压力： 9000服务实例

三、如何保持Consul作为注册中心场景地高可用？

那有以下建议。

3.1 Consul集群高可用

• 多节点、多AZ部署
• 完善监控（健康检查）
• 自动重启、拉起能力
• 数据持久化（挂载云盘）
• 压测（保证适合的规格）

3.2 客户端容灾

• 做一定容灾、缓存、文件备份
• 缺失Client的架构，需要扩展以下 自动切换Server节点、数据丢失自动注册功能