作者
孔令圳,斗鱼首席架构师,全面负责斗鱼全站技术架构体系规划和建设,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 个原因。
基于以上原因,我们选择了方案四,方案四大新架构如下图所示:
图四 斗鱼注册中心新架构
注册中心多活难点与挑战
为了实