关于云计算:斗鱼直播云原生实践之注册中心篇

作者

孔令圳，斗鱼首席架构师，全面负责斗鱼全站技术架构体系布局和建设，10 余年中大型互联网产品架构教训，善于高并发、高可用场景下的架构与方案设计。

于竞，斗鱼技术保障运维专家，负责斗鱼高可用基础架构建设，善于注册核心、监控体系等技术畛域，同时也是斗鱼多活根底保障负责人。

唐聪，腾讯云资深工程师，极客工夫专栏《etcd 实战课》作者，etcd 沉闷贡献者，次要负责腾讯云大规模 k8s/etcd 平台、有状态服务容器化、在离线混部等产品研发设计工作。

陈鹏，腾讯云容器服务产品架构师，多年专一云原生畛域，帮忙了大量用户云原生容器化革新和生产落地，领有丰盛的一线实践经验，也发表了海量的云原生技术文章。

业务背景和痛点

斗鱼直播作为业界当先的游戏直播平台，每天为数以亿计的互联网用户提供优质的游戏直播观看、互动和娱乐等服务。

随着近年直播市场的炽热，斗鱼直播平台作为业内口碑和体验俱佳的互联网公司，用户量也呈现井喷式增长。海量用户给平台带来的稳定性技术挑战也越发强烈，斗鱼的老架构如下图所示，无论是业务撑持还是架构设计，均存在肯定的危险和隐患。

斗鱼老架构

图一 斗鱼老架构

为了给用户带来更好的可用性体验，斗鱼急需解决繁多数据中心的问题，将老架构从单数据中心降级到多数据中心。

多数据中心挑战

在实现单活降级为多活的过程中，为了确保无故障的迁徙降级，咱们面临一系列挑战，比方：

有状态服务 etcd、zookeeper 等如何多数据中心同步？
利用彼此之间存在 1 个简单的树状或网状依赖关系，应该从哪里开始迁徙？
按什么维度来划分指标的边界，怎么防止业务焊死在一起，造成无从下手的场面？
如果迁徙后呈现问题，如何疾速复原，并且不株连已迁徙胜利的业务？
因单活降级到多活的过程中，波及零碎泛滥，本文将是斗鱼直播多活革新系列的第一篇，只聚焦于注册核心模块，因而咱们先和你介绍下注册核心背地的 etcd 和 zookeeper。

zk/etcd 承当的角色

dubbo 通过注册核心来解决大规模集群下的服务注册与发现问题，以下是注册核心架构图：

dubbo 默认反对 zookeeper 注册核心，尽管新版也有 etcd 实现，但该实现尚不足大规模投产的先例，Java 技术栈采纳 etcd 作为注册核心的案例也比拟常见。

当采纳 zookeeper 作为 dubbo 注册核心时，其注册关系为树形构造，具体构造如下图所示：

因为 zookeeper 是基于相似文件系统的树形构造来存储数据，但 etcd 却是采纳键值对存储，二者之间的差别会给注册关系同步带来较大艰难。

此外，如果从 zookeeper 迁徙到 etcd，则在整个迁徙过程中：已有的线上服务不能受损，更不能停服；如果迁徙失败，还要能回退到到 zookeeper。

同城双活与多活新架构

为了实现多活，咱们通过跨数据中心的同步服务、服务依赖梳理与边界划分、可控变更等技术手段和运维理念，胜利解决了以上挑战，设计了如下一套新的架构来实现多活，如下图所示：

图二 斗鱼多活新架构

在新的架构下，能够按域名甚至是 URL 来细粒度的调度流量，RPC 层面也具备了主动就近调用的能力，其中注册核心的部分架构图如下：

图三 斗鱼注册核心老架构

注册核心多活计划选型与指标

在注册核心多活革新过程中，咱们面临多个计划，如下表所示：

因为历史起因，咱们有 zookeeper（以下简称 zk）和 etcd 这 2 套注册核心，加上咱们有 Java、Go、C++、PHP 这 4 个技术栈，因而在注册核心畛域依然一些有余，心愿能对立到 etcd 来解决痛点问题，并达到以下指标：

升高保护老本：此前须要运维 zk+etcd 两套注册核心，更艰难的是做多活解决方案时也须要适配 zk+etcd，这导致注册核心多活研发老本翻倍。因为 etcd 是 k8s 的一部分，运维 etcd 又不可避免，这是抉择 etcd 的第 1 个起因。

拥抱更凋敝的生态：etcd 有云原生托管解决方案，有厂商通过 etcd 治理 10K node 级别的 k8s 集群，etcd 还自带 proxy、cache、mirror 等各种周边工具，java 侧 dubbo 也反对以 etcd 作为注册核心，etcd 绝对于 zk 来说发展前景更好，这是抉择 etcd 的第 2 个起因。

加强跨语言能力：etcd 可基于 http 或 grpc 协定通信，并且反对长轮询，具备较强的跨语言能力。而 zk 须要引入专用客户端，除 java 客户端之外，其它语言客户端尚不成熟。而咱们有 JAVA、Go、C++、PHP 等 4 种研发语言，这是抉择 etcd 的第 3 个起因。

基于以上起因，咱们抉择了计划四，计划四大新架构如下图所示:

图四 斗鱼注册核心新架构

注册核心多活难点与挑战

为了实现新注册核心，达到咱们冀望的设计指标，注册核心在革新过程中，面临以下难点与挑战:

如何解决 zk 的多数据中心同步问题？尤其是 zookeeper watch 机制是不牢靠的，可能呈现失落 watch 事件的问题？（正确性）
如何解决 etcd 的多数据中心同步问题？从上面计划选型中，咱们能够看到社区目前并无任何成熟、生产环境可用的解决方案。（正确性）
如何解决跨数据中心读的性能问题？（性能）
如何解决跨数据中心的服务稳定性问题？网络链路上，比方内网专线若中断了怎么办？同步服务设计上，是否会导致 etcd/zk 同步服务进入性能极慢的全同步逻辑，同步服务自身是否具备高可用等等？容灾测试上，咱们又该如何设计测试用例验证？运维上，咱们又该如何疾速发现隐患、打消潜在的故障，建设可视化、灵便的多活运维零碎？（稳定性、可运维性）

注册核心多活难点剖析

迁徙过程中如何保障新旧服务互通？

开发 zk2etcd

咱们很多 java 开发的业务应用 dubbo 框架做服务治理，注册核心是 zookeeper，咱们心愿 java 和 go 开发的业务全副都对立应用 etcd 作为注册核心，也为跨语言调用的可能性做好铺垫。

因为业务泛滥，革新和迁徙的周期会很长，预计继续 1~2 年，在此过程中咱们须要将 zookeeper 中的注册数据同步到 etcd 中，实时同步，而且要保证数据一致性以及高可用，以后市面上没有找到满足咱们需要的工具，于是咱们和腾讯云 TKE 团队合作开发了一个 zk2etcd 来同步实现 zookeeper 数据到 etcd，并且已将其开源，整体计划落地篇咱们将具体介绍。

如何实现 etcd 异地容灾?

通过 zk2etcd 同步服务，咱们胜利解决了 zookeeper 数据迁徙问题，使得新老业务的注册核心数据都应用 etcd 来存储。

因而，etcd 的重要性显而易见，它的可用性决定着咱们的整体可用性，而斗鱼直播目前的部署架构又重大依赖某外围机房，一旦外围机房呈现故障，将导致整体不可用。因而斗鱼直播下一个痛点就是晋升 etcd 的可用性，冀望实现 etcd 跨城容灾、异地容灾能力。

斗鱼直播现实中的 etcd 跨城同步服务应该具备如下个性:

etcd 跨城容灾部署后，读写性能不显著降落，能满足业务场景根本诉求。
同步组件达到生产环境可用级别，具备齐备的一致性检测、日志、metrics 监控等。
对数据一致性要求不强的业务可就近拜访同地区的 etcd 集群服务、强统一诉求业务可拜访主 etcd 集群。
主集群故障后，业务运维能依据一致性监控等，疾速将备集群晋升为主集群。
那么有哪些计划呢？各个计划又有哪些优缺点呢？最终评估了如下几种计划:

单集群多地部署计划

etcd 社区 make-mirror 计划
etcd 社区 learner 计划
腾讯云 etcd-syncer 计划
单集群多地部署计划
单集群多地部署计划图如下：

在此计划中，etcd Leader 节点通过 Raft 协定将数据复制到各个地区的 Follower 节点。

此计划它的长处如下：

各地区网络互通后，部署简略，无需运维额定组件

数据跨城强统一同步，3 节点部署场景中，可容忍任一城市故障，并且不失落任何数据

介绍完它的长处后，咱们再看看它的毛病，如下所示：

在 3 节点部署的场景下，任意写申请至多须要两个节点应答确认，而不同节点部署在各地，ping 延时会从几毫秒回升到 30ms 左右（深圳 – 上海)，因而会导致写性能急剧下降。

etcd 默认的读申请是线性读，当 Follower 节点收到 Client 发动的读申请后，它也须要向 Leader 节点获取相干信息，确认本地数据追赶上 Leader 后能力返回数据给 client，防止读取到旧数据等，在这过程中也会导致 etcd 读延时回升、吞吐量降落。

跨城部署网络之间品质也较容易稳定，导致服务质量抖动等。

client 拜访 etcd 集群的配置，为了避免单点故障，必须配置多个 etcd 节点，而这又可能导致 client 拜访到异地的 etcd 节点，导致服务申请延时增大等。

etcd 社区 make-mirror 计划

介绍完单集群多地部署计划后，咱们再看看 etcd 社区提供的 make-mirror 计划，它的原理图如下：

在此计划中，咱们别离在不同城市部署了一套独立的 etcd 集群，通过 etcd 社区提供的 make-mirror 工具实现跨城数据复制。

make-mirror 工具原理如下：

指定数据同步的前缀后，通过 etcd Range 读接口从主集群遍历此前缀下的所有数据，写入到目标 etcd。（全量同步）
随后通过 etcd Watch 接口指定读申请返回的“版本号”，监听从此版本号后的所有变更事件。
make-mirror 收到主 etcd 集群推送的 key-value 变动事件后，通过 txn 事务接口将数据写入到热备集群。（增量同步）
此计划它的长处如下：

主 etcd 集群读写性能高，整体上不受跨地区网络延时、网络品质稳定影响
若业务可容忍短暂不统一，可就近拜访间隔最近的 etcd 集群
若业务要求强统一，可通过内网专线拜访主 etcd 集群
不依赖高版本 etcd
介绍完它的长处后，咱们再看看它的毛病，如下所示：

当写申请较大的时候，备集群可能存在肯定的数据落后，可能读到脏数据。
社区自带的 make-mirror 同步链路中断后，退出重启会再次进入全量同步模式，性能较差，无奈满足生产环境诉求。
社区自带的 make-mirror 工具短少 leader 选举、数据一致性检测、日志、metrics 等一系列个性，不具备生产环境可用性。
不反对同步非 key-value 数据，如 auth 鉴权相干数据、lease 数据等。

#### etcd 社区 learner 计划
介绍完 etcd 社区的 make-mirror 计划后，咱们再看看 etcd 社区提供的 learner 计划，它的原理图如下：

它的外围原理如下：

etcd raft 算法库在 2017 年的时候就曾经反对了 learner 节点，详情可参考 pr 8751。
etcd 社区在 2019.8 月推出的 3.4 版本中，正式反对 Learner 节点，它作为非投票 (Non-Voting) 的成员节点退出集群，不参加集群选举等投票，只进行数据复制。
Leader 收到写申请后，将日志同步给 Follower 和 Learner 节点，并在内存中应用一个名为 Progress 的数据结构，保护 Follower 和 Learner 节点的日志同步停顿信息。
当 Learner 节点的数据与 Leader 数据差距较小的时候，它就能够被晋升为可投票的成员节点退出集群。
此计划它的长处如下：

各地区网络互通后，部署简略，只需往 etcd 集群中增加一个 Learner 节点，无需运维额定组件
Learner 节点可同步任意类型数据，如 key-value、auth 鉴权数据、lease 数据
介绍完它的长处后，咱们再看看它的毛病，如下所示：

Learner 节点只容许串行读，也就是业务如果就近读，会读到旧数据。
依赖高版本 etcd，etcd 3.4 及以上版本才反对 Learner 个性，并且只容许一个 Learner 节点 .
主集群全面故障后，无奈疾速将 Learner 节点晋升为可写的独立 etcd 集群。
介绍完已有的几种计划后，咱们发现它们都无奈满足业务生产环境诉求，于是咱们自研实现了生产环境可用的 etcd 同步服务落地，在整体计划落地章节将具体介绍。

如何确保 etcd 和 zk 同步服务的稳定性、可运维性?

为了确保 etcd、zk 同步服务的稳定性，模仿 5 类常见的故障，测验服务在这些典型故障场景下的自愈能力，具体测试计划如下。

#### 故障场景
redis 闪断（zk2etcd 服务依赖），例如：redis 版本升级、非平滑扩容。

zk2etcd 离线，例如：OOM、容器驱赶、宿主机故障。

etcd2etcd 离线，例如：OOM、容器驱赶、宿主机故障

网络闪断，例如：OOM、容器驱赶、宿主机故障。

弱网环境，例如：专线断掉后长期用公网顶替。

上述 5 种场景的理论触发起因有多种多样，只须要模拟出一种状况。

演练计划

redis 闪断：通过改 host 模仿 redis 不可达，此时主动勘误进行；模仿 redis 复原后，主动勘误亦主动复原。

zk2etcd 离线：通过杀容器节点模仿 zk2etcd 挂掉，15 秒内 k8s 主动拉起，拉起实现后同步失常、数据统一。

etcd2etcd 离线：通过杀容器节点模仿 zk2etcd 挂掉，15 秒内 k8s 主动拉起，拉起实现后同步失常、数据统一。

网络闪断：通过改 host 模仿 zk、etcd 不可达，此时同步中断，后去掉 host 模仿网络复原，复原后同步失常、数据统一。

弱网环境：通过切公网模仿弱网环境，切公网后同步效率升高在 4 倍以内，1 次全量同步依然可在 1 分钟内实现。

另外针对可运维性问题，无论是 etcd 还是 zk 同步服务，都提供了具体的 metrics、日志，咱们针对各个外围场景、异样场景都配置了可视化的观测视图，并配置了告警策略。

整体计划落地

整体架构

etcd 集群多活架构图如下所示:

阐明

黑实线：失常状况下的专线拜访

黑虚线：切公网形式拜访

红实线：etcd 集群产生主备切换后的专线拜访

红虚线：etcd 集群产生主备切换后的公网拜访

etcd2etcd/zk2etcd 数据同步服务图如下所示:

zk 同步服务工程化实际

zookeeper 与 etcd 存储构造不统一，加大了同步的实现难度。zookeeper 存储是树状构造，而 etcd v3 是扁平构造。zookeeper 无奈像 etcd 一样依照 prefix 来 list 所有 key；etcd 无奈像 zookeeper 一样通过 list chilren 来查问某个目录下的子节点，也加大了实现同步的难度。

如何感知 zookeeper 中的数据变动？zookeeper 的 watch 不像 etcd 一样能够简略的感知到任意 key 的新增，须要递归的 watch 所有的节点，收到 ChildrenChanged 事件后拿到该事件对应节点下的所有子节点，再与 etcd 中的数据进行比对，就能够失去新增的数据，并将其同步 put 到 etcd 中。相似的，能够用递归的办法 watch 所有节点的删除事件，并同步删除 etcd 中的数据。

另外 zookeeper 的 watch 有着先天性的缺点，watch 是一次性的，所以每次收到事件后又必须从新 watch，两次 watch 之间实践上是可能丢事件的，次要是在同一个 key 间断屡次变更的时候可能会产生。如果丢事件产生就会毁坏了数据一致性，咱们引入了主动 diff 和勘误的能力，即计算 zookeeper 和 etcd 中数据存在的差别，每次都会通过两轮 diff 计算，因为在频繁变更数据的状况下，一轮 diff 计算往往存在一些因不是强一致性同步导致的 ” 伪差别 ”，当 diff 计算出了后果就会主动 fix 掉这些差别。

如何解决与 etcd2etcd 共存？当同一个门路下，即有 etcd2etcd 同步写入的数据，又有 zk2etcd 写入的数据，在 zk2etcd 的主动勘误逻辑外面，会计算出差别并勘误差别，但咱们不心愿因而而误删 etcd2etcd 写入的数据。咱们通过为 zk2etcd 引入了 redis 来存储状态解决了这个问题，在 zk2etcd 往 etcd 中同步写入或删除数据时，也同步在 redis 中记录和删除:

而后 zk2etcd 在主动勘误计算差别的时候，只思考本工具写入过的数据，防止误删其它同步工具写入的数据。

etcd2etcd 工程化实际

为了解决 etcd 同步难题，咱们调研了如下两种计划，接下来咱们就具体介绍下它的原理：

etcd-syncer 之 mirror-plus 版

首先咱们介绍下 etcd-syncer 的 mirror-plus 计划，顾名思义，它是 etcd 社区 make-mirror 的加强版。为了解决 make-mirror 的各种缺点，它实现了以下个性、长处:

反对多种同步模式，全量同步、断点续传，不再担心专线、公网网络品质抖动
高可用，负责同一数据门路复制的实例反对多正本部署, 一副本故障后，其余正本将在 5 秒后取得锁，在之前实例同步的进度根底上，进行疾速复原
反对一致性查看（全量数据查看、快照查看)
反对多实例并发复制晋升性能（不同实例负责不同的门路），倡议生产环境配置多实例，每个实例负责不同门路
良好的运维能力，基于 k8s deployment 一键部署，丰盛的 metrics、日志，齐备的 e2e 测试用例笼罩外围场景（http/https 场景，服务异常中断、网络异样等）
那么它的毛病是什么呢？因为它外围原理仍然是依赖 etcd 的 mvcc+watch 个性，因而数据无奈保障强一致性和只同步 key-value 数据。

断点续传依赖 mvcc 历史版本保留工夫，最好业务能保留至多 1 个小时的历史数据。
当写申请较大的时候，备集群可能存在肯定的数据落后，可能读到脏数据。
不反对同步非 key-value 数据，如 auth 鉴权相干数据、lease 数据等。

etcd-syncer 之 Raft 版

为了解决所有类型的数据同步问题以及打消对 etcd mvcc 历史数据的依赖，腾讯云还可提供基于 Raft 日志的同步计划 etcd-syncer 之 raft 版本。

它的部署图如下所示,etcd-syncer 同步服务作为一个相似 learner 节点的身份，退出主 etcd 集群。

主 etcd 集群 Leader 将 Raft 日志数据通过 MsgApp/Snapshot 等音讯同步给 etcd-syncer, etcd-syncer 解析 Raft 日志，将 Raft 日志条目对应的 Txn/Delete/Auth 等申请利用到目标 etcd 集群。

它具备如下长处：

具备 etcd-syncer 之 mirror-plus 版本的所有个性和长处，同时不依赖 etcd mvcc 历史数据。

基于 etcd 底层的 Raft 日志同步数据，能够同步 key-value、auth、lease 等各种类型的数据。

不依赖高版本的 etcd。

齐备的容灾测试

#### grpc-proxy
此计划引入了 grpc-proxy 代理服务，也是头一次应用。为了理解此代理服务的性能状况，咱们应用 etcd 自带的 benchmark 进行了读和写的测试，另外手写了一个小工具做了一下 watch 测试。以下为局部测试内容。

写入测试

间接拜访 etcd 服务的负载平衡入口

走 grpc-proxy 代理拜访 etcd 服务的状况

grpc-proxy 代理在 endpoints 配置走专线或公网状况下，都能失常写入
写入 key 总数肯定的状况下，连接数和客户端数越大，总耗时越低
写入 key 总数越大，单次写入的均匀耗时（Average）会有所增加，但仍为毫秒级
当一次写入 key 总数为 10 万时，直连 etcdserver 会呈现 too many requests 的报错，但 grpc-proxy 没有
公网状况比专线性能有所降落
走 grpc-proxy 代理的均匀耗时相比直连有所增加，但满足需要
读取测试

间接拜访 etcd 服务的负载平衡入口

走 grpc-proxy 代理拜访 etcd 服务的状况

grpc-proxy 代理在 endpoints 配置走专线或公网状况下，都能失常读取

走 grpc-proxy 代理的均匀耗时相比直连有所增加，但在可承受范畴

watch 测试

依据咱们本人写的一个 etcdwatcher 服务对 grpc-proxy 进行 watch 测试：能够设置总 watcher 数量，更新频率，以及测试工夫，完结时打印出简报

./etcdwatch -num=100 -span=500 -duration=10 -endpoint=http://grpc-proxy-addr:23791
test done
total 100 task
0 task failed
current revision is 631490
least revision is 631490
0 task is not synced

参数阐明：

num 工作数量

span 更新距离，单位毫秒

duration 总测试工夫，单位秒

current revision：代表写入的 revision

least revision：示意 num 个工作中同步最慢的 revision

failed 为 0 阐明失常；如果过呈现 task not sync 阐明 watch 和 put 不同步

以上测试后果来看：failed 数为 0，watch 测试失常

zk2etcd

咱们应用的是 1.2.5 版本，通过 k8s 的 deployment 形式部署

模仿 zk server 失联

场景
通过将 hosts 中注入谬误解析地址

景象
期间没有发现 zk 失联的报错日志
监控指标没有发现异常
尔后执行重启，fixed 操作数没有呈现凸增状况（在 1.2.4 版本中，存在 full sync 尽管在定时执行，然而并没有感知到须要 fix 的 key 的 bug。导致重启 zk2etcd 服务实例后，可能察看到 fixed 操作凸增的景象）

模仿 redis 失联

模仿操作
09:56:49 将 hosts 中注入 redis 谬误解析地址
10:07:34 复原 redis
10:16:00 重启同步服务 pod（操作重启是为了察看 full sync 是否失常）

景象
期间 fixed operation 数量没有增长，其余监控指标未发现显著异样
实例重启后没有呈现 fixed 数凸增的状况

模仿 etcd 失联

模仿操作
16:15:10 etcd server 失联

16:30 复原

16:45 重启 pod

景象
期间 fixed operation 数量没有增长，其余监控指标未发现显著异样

尔后重启，fixed operation 数量有所增涨（不能确定是 full sync 未失效，还是重启后刚好有更新修复导致）

总结

只有 full sync 机制工作失常，各异样场景产生后，都能在下一个 full sync 触发后被复原

复原的最小工夫距离取决于设置的 full sync 定时执行间隔时间（默认为 5m），业务对此间隔时间容忍状况自行调整参数

此外，为了防止异样产生后，full sync 机制定时运行但也没能感知到状况产生，保险起见预先能够第一工夫重启一下 zk2etcd 服务

对于追加的 etcd 公网测试，full sync completed 和 zk、etcd 操作耗时，相比内网状况有肯定（秒级）增长

etcd2etcd

etcd2etcd 的同步服务，我采纳 deployment 双正本部署

多正本 backup 能力

冀望
⼯作节点故障后备⽤节点会在 5s 后接管同步工作

测试计划
etcd syncer 双实例部署

杀掉正在运行的工作节点进行察看

论断
不论是增量同步还是全量同步过程中，主备切换都能失常工作（须要留神的是，当全量同步中产生主备切换后会变为增量同步，从而可能导致比对较慢）

断点续传能力

冀望
故障复原后能从断点持续开始同步

其实在第 1 局部，备节点切换为主后接管同步工作，fast_path 变为 1 也证实了断点续传能力，咱们还额定补充几个验证场景：

(a) 短时间故障

故障场景

核心 etcd 集群到热备集群的同步过程中，因作为源的核心 etcd 集群中也存在 -etcd-syncer-meta- 的 key，触发了同步服务报错（同 txn 中不能蕴含雷同的 key），呈现了数据差别

景象

将同步服务运行参数增加对 -etcd-syncer-meta- 的过滤，而后察看进过一段时间追赶数据后，最终 miss 数降去达到统一

(b) 长时间故障

故障场景

进行同步服务的部署 deployment

期待两边 etcd 集群产生数据差别，并产生一次 compact 后再启动同步服务

景象

等产生数据差别，并产生 compact 后，重新启动同步服务，其日志如下：因 compacted 产生，触发全量同步

同步服务监控指标：(a) dst miss key 很快降下去；(b) src miss key 有所增加，并继续不降

剖析

同步服务进行当前，源 etcd 的 key 数量产生不少变动，监控图看出期间有降落，阐明产生过 key 的删除

这里也暴露出一个小问题，当呈现 src miss key 的时候，目前不能主动修复，须要人工接入清理多余的 key

3. reset 触发全量同步

当同步产生重大差别（如，产生 dst miss）进行紧急修复的时候，通过配置 –reset-last-synced-rev 参数删除断点续传信息，来触发全量同步修复差别

景象
因某种异样，同步呈现 dst miss（图中黄线实例）的状况。为了进行修复，新实例增加 –reset-last-synced-rev 参数后运行

剖析

slow_path 为 1，阐明触发全量同步（图中绿线实例）

绿线实例的 dst miss 值没有增长起来，阐明曾经达到统一

4. 网络故障
   两 etcd 集群之间专线中断

增量同步中

全量同步中

测试计划

当专线中断切换公网时，须要批改运行参数中的 etcd 集群拜访地址，即：必会产生重启（重启场景测试后面曾经涵盖，这里不再反复）

总结

etcd-syncer 同步服务有较好的主备机制，可能及时无效的进行切换

短时间故障后的断点续传体现合乎预期；对于长时间故障，同时产生 compact 的简单状况时，复原同步后呈现 src miss 的状况，可能须要人工接入

通过配置 –reset-last-synced-rev 参数对 src miss 的异样修复有较好的成果

对于咱们

更多对于云原生的案例和常识，可关注同名【腾讯云原生】公众号~

福利：公众号后盾回复【手册】，可取得《腾讯云原生路线图手册》&《腾讯云原生最佳实际》~