斗鱼直播云原生实践之注册中心篇

斗鱼直播在实现多活架构的过程中,面临注册中心多活的挑战。文章详细介绍了从zookeeper到etcd的迁移方案,包括zk2etcd工具的开发,以及etcd的异地容灾策略,如单集群多地部署、社区make-mirror和learner方案的评估。在保证服务稳定性和可运维性的前提下,通过zk2etcd和etcd2etcd实现数据同步,进行故障模拟和容灾测试,最终实现整体架构的升级与多活目标。
摘要由CSDN通过智能技术生成

作者

孔令圳,斗鱼首席架构师,全面负责斗鱼全站技术架构体系规划和建设,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 个原因。

基于以上原因,我们选择了方案四,方案四大新架构如下图所示:

图四 斗鱼注册中心新架构

注册中心多活难点与挑战

为了实

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值