广义的容灾，可以认为是业务连续性计划当中的灾难恢复，即能够容忍灾难的能力，如何在灾难发生时，保证生产业务系统的不间断运行，需要我们健全快速容错 / 故障切换能力，即容灾能力，包含了常态化容灾建设以及针对能力进行的周期性演练验收。

在 QCon 北京 2024 大会上，字节跳动基础架构稳定性负责人百玥，根据自己在字节跳动的实践经历，发表了题为 《字节全球化容灾》 的演讲，她将字节当前全球化部署基本形态与各类业务特性以及容灾预期相结合，阐述字节容灾建设策略以及持续化运行情况。同时，以实际案例出发，详细说明对应容灾的实践。

本文由 InfoQ 整理，经百玥老师授权发布。以下为演讲实录。

今天，我将与大家分享字节跳动在全球化进程中的容灾议题。原因在于，许多国内互联网业务正面临一个迫切的需求——业务出海。字节跳动在出海方面起步较早，并且覆盖范围广泛，因此我希望通过今天的分享，能够为那些有出海需求的公司提供一些有益的建议。

大家对字节跳动的业务形态应该有所了解。但可能对全球化部署的具体细节不太熟悉。除了中国区外，字节的业务还包括亚太、欧洲和美洲区域。在这种多样化的全球化部署模式下，我们面临的容灾挑战是巨大的。海外业务分布比国内更广，用户差异性也更大，因此我们的海外容灾建设与国内相比有很大的不同。

今天的分享将分为四个主要部分：首先是基础演进路径，然后结合演进简单介绍下国内容灾，接着会重点基于差异性来讲一下海外容灾，最后我会简要说明我们的容灾实施情况。

字节容灾架构的演进路径

容灾整体的演进过程与大家所理解的基本一致。我们从单一机房开始，逐步发展到同城双机房，再到同城的多个机房。随着业务的快速发展以及部署需求的调整，我们进一步演进到异地多活模式。目前，业界内一些领先的大公司已经实现了相当成熟的异地多活部署模式。

目前，字节跳动在国内并没有采用双机房冷备的部署模式，而是直接从单机房演进到了同城多机房的架构。这个同城多机房的演进过程实际上分为两个阶段。起初，我们实现了双机房的部署，随后又发展到了同区域内的多机房部署。最终，我们演进到了目前的异地多活模式，这是我们国内架构的当前状态。

海外的容灾架构也经历了传统单机房模式的阶段。但由于海外业务发展的特定需求，我们的演进路径与国内有所不同。在海外，我们首先采取了跨区域的异地多活模式，随后根据区域化业务发展的需要，进一步调整为异地多活和同城容灾的结合模式。

国内容灾建设

字节国内的容灾架构主要经历了三个发展阶段：单机房、同城多机房，以及目前的异地多活模式。

单机房

在字节跳动的早期阶段，我们采用了华北区域的单机房部署方式，那时我们的业务正处于从无到有的起步阶段。到了 2018 年，随着我们内容商业化的加速，业务的快速发展带来了一个重大问题：资源瓶颈。这是因为物理机房的容量是有限的，无法满足我们业务的快速增长。这一时期，业务发展带来的资源需求促使我们引入了同城双机房模式。这个模式在一定程度上解决了资源问题和单点故障问题。我们的双机房采用的是主从模式，读请求可以通过两个机房分担，而底层存储层则通过主从同步来实现。

在 2019 年，我们经历了一次重大事故——道路施工导致我们的光缆被切断，这次事故对我们的整体业务产生了严重影响，并引起了舆论关注。这种情况在业界其他公司也有发生，但它暴露了我们容灾架构的不足，一方面是控制面没有独立部署，导致在单个机房出现问题或专线中断时，容灾指令无法正常下发。另一方面双机房模式最初只是为了解决业务发展的需求，并没有进行相应的容灾冗余部署。导致业务需要做机房切流时没有足够的资源支撑，严重暴露了容灾能力的不足。这次事故凸显了双机房模式虽然能够解决一定的资源和单点问题，但对于容灾的要求更高，也揭示了更多的容灾风险。

同城多机房

在同城多机房阶段，我们采用了 IDC 全互联的方式，这大大降低了单专线中断情况下对业务的影响。同时，我们的控制面和数据面得到了较好的分离，这样即使 IDC 出现问题，我们的指令仍然可以正常下发。由于字节跳动的业务非常多样化，我们不可能将所有业务的 master 部署在单一机房，因为这会导致压力过大。因此，我们会根据业务特性选择主机房，以降低机房压力。我们的多机房容灾复杂度非常高，我们期望综合考虑业务特性，选择性地进行多机房部署。这也会涉及到成本上的考虑和容灾策略上的调整。

在同城多机房场景下，我想重点介绍两个主要的容灾场景：专线中断和 AZ 不可用。在专线中断场景下，由于我们采用了全互联，单专线中断时，我们可以通过网络绕行来实现预期的容灾效果。而在 AZ 不可用的情况下，我们可以将单个不可用的 AZ 的流量根据一定比例和部署策略切换到其他健康的 AZ，以达成我们的容灾预期。