同城容灾+异地多活是全球化容灾处理的最好模式吗？

整理｜Penny

编辑｜褚杏娟、傅宇琪、Kitty

策划 | QCon 全球软件开发大会

“容灾建设中，关注三个关键词：资源、流量和数据。容灾建设强依赖于资源评估。无论是专线中断还是 AZ 不可用的情况下，我们的首要任务是评估资源容量是否充足。容灾实施方面，关注做好容灾架构设计，并结合常态化建设，逐步完善容灾能力。此外，周期性的常态化演练是确保容灾预案持续可用的关键。” 稳定性问题不仅给用户带来不便，还可能导致企业声誉和经济损失。如果线上可靠性工程出现问题，那么前期在应用产品设计、研发测试、发布变更等环节的所有投入都可能变得毫无意义。我们在即将于 10 月 18 -19 日召开的 QCon 上海站策划了【线上可靠性工程】专场，将邀请不同公司的稳定性技术专家，分享他们在各自的业务场景中的可靠性 / 稳定性保障的实践经验，共同探讨线上可靠性工程的问题的解决思路。目前是 8 折购票最后优惠期，感兴趣的同学请点击文末【阅读原文】链接了解详情。

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

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

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

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

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

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

字节容灾架构的演进路径

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

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

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

国内容灾建设

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

单机房

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

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

同城多机房

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

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

需要特别注意的是整个容灾建设需要提前规划，包括是否选择全互联的专线建设，以及在切流前所需的各类基础组件，业务维度的分层降级能力，尤其是分层建设，要提前做好全面的评估，按时间节奏进行落地实践。

接下来，我会详细讨论专线中断和 AZ 不可用的两个场景下的容灾策略。如果 a 和 c 两个 AZ 之间的专线不可用，我们会选择绕行，绕行基本上是两跳，比如 a 到 n 再到 c，或者 a 到 b 再到 c，这样即使 a 和 c 之间的专线中断，我们的在线服务请求仍然可以触达到目标机房。我们的策略会考虑两个点：分层降级和绕行。我们会先降低离线业务，再是近线业务，然后是部分在线业务，这基于我们的整体优先级；同时，由于降级会带来一定的业务损失，建议在降级前分阶段进行流量观测。绕行时，我们需要提前评估所需的带宽，并考虑绕行后对健康专线容量的影响，以避免对业务造成二次损伤。

对于 AZ 不可用的场景，我们的三大步骤如下：首先，业务在 AZ 之间进行了差异性部署，比如 AZ a 可能部署了抖音的核心业务，而 AZ b 可能部署了广告相关业务，这样可以减少单个 AZ 的流量压力，同时在单个 AZ 不可用时，只影响部分业务。其次，我们采用单业务多 AZ 部署，这样在单个 AZ 不可用时，可以快速进行业务流量切换，保证业务的持续性。最后，控制面必须独立部署，这样即使在 AZ 不可用的情况下，也不会影响控制面的容灾指令下发。

异地多活

在字节跳动的异地建设模式中，我们经过测算发现，华东到华北之间的网络往返时间（RTT）大于 30 毫秒。这就意味着，对于那些对数据强一致性要求高或请求响应时间要求高的业务来说，这是不可接受的。因此，这些业务必须进行单元化建设，这与许多电商类业务的做法类似。不过，字节跳动确实有一些特殊的业务需求。

以今日头条和我们的内容类业务为例，这些业务的特点通常是写入操作少、读取操作多。对于这种读取密集型场景，我们会基于读取场景进行异地多活的建设。这就是基于业务的差异性灵活调整的特殊异地多活模式了。对于电商类业务，我们的解决方案与业界的基本解决方案相似，我在这里就不详细展开了。这也说明了，公司在选择异地部署时，可以根据自身的业务需求选择不同的部署模式，存在多样性。

异地情况下，如果专线中断我们该采取什么样的策略？在异地多活模式下，我们的专线流量与同城模式有所不同，特别是在长距离传输场景下，我们不会有离线数据的同步。如果华北的专线中断，我们首先会降级离线业务，因为离线业务可以接受较长时间的延迟。但在华东到华北的长距离传输情况下，我们没有离线的这部分数据，因此在面对长距离专线中断的容灾时，我们无法降级离线。这时，我们只能通过在线部分的分层降级来支持绕行。由于成本问题，华东到华北的专线建设不会像华北那样实现全互联。因此，在这种情况下的策略是，如果分层降级后可以绕行，我们就进行绕行；如果不能绕行，我们需要执行区域间的流量切换，即将华东的整体流量回切到华北，当然，回切前需要做一些资源上的评估以及针对场景进行的降级操作。

当 AZ 不可用时，我们会损失一定的资源。在这种情况下，我们当然会考虑如何从其他 AZ 腾挪资源来支持流量的切换。这个场景下的操作分为两步：首先，我们会判断同城的 AZ 资源是否足够支持受损 AZ 的流量切换。如果资源不足，我们依旧会选择进行区域间的切换，这与刚才提到的专线中断的情况类似。与同城容灾不同，异地容灾会有一个选择过程：先判断同城资源，如果同城资源不够，再考虑区域间的容灾策略。同时，我还要强调一点，由于单元化部署可能存在较大差异性，如果在单元化场景下选择进行整个区域间的切换，我们必须先对相应的单元化策略进行调整，以避免由于区域间切换导致的一些数据不一致问题，这需要业务侧制定一些预案，例如说禁写。

字节海外容灾

由于海外业务的特殊性，我们的容灾架构首先采用了异地模式，然后发展成为异地加同城的双重容灾模式。由于海外一些本地差异化问题，尤其是基础设施类问题较多，导致海外的重大事故频发，其频率远高于国内。因此，在海外容灾这部分，我主要会和大家分享我们经历的两个演进阶段，以及对这些重大事故根本原因的分析。

异地多活

2017 年 TikTok 在谷歌商城正式上线，是我们出海战略的一个重要里程碑。随后，我们收购了 Musical.ly，到了 2018 年，TikTok 和 Musical.ly 从独立服务于不同市场，转变为深度融合。这一融合过程之后，我们在 2019 年开始实施异地多活以及多区域的异地容灾模式。

我们的演进可以大致分为两个阶段。在第一阶段，TikTok 主要服务于亚太地区，而 Musical.ly 则面向北美市场，两者在数据层面完全隔离，没有任何同步或打通。融合之后，我们转向了一种新模式，即在亚太、美洲以及云上区域之间进行数据的全量同步。这种模式在初期是一种极简的异地部署模式，其中亚太区域拥有全量数据，而美洲和云上区域也拥有全量数据，但针对不同区域的用户，我们提供业务读取服务，并在本区域内进行写入操作。在海外，我们选择单元化的策略与国内有所不同。国内可能基于相同的用户群体进行单元化，而在海外，我们通常以国家为单位进行单元化。因此，我们的策略是基于国家就近调度读写流量，尽可能在单元内闭环，即在区域内完成。

在异地多活的场景下，我们面临的第一个挑战是长传，区别于国内的异地长传，海外会涉及跨洋专线，通常是海底光缆，其建设周期长，不确定风险因素高，稳定性差。此外，由于初期是区域单点部署，单个 AZ 不可用时，我们只能选择跨区域切换，这对我们来说是一个巨大的挑战。

在跨洋专线受损的情况下，我们的容灾策略与国内有很大差异。国内可能存在可绕行的专线，但在海外，我们只能基于降级来保障核心流量的正常运行。除了分层降级和分批降级，我们还需要考虑没有可绕行专线的情况，只能通过有损降级来保障核心在线服务。

当我们面临区域不可用的情况时，由于初期建设时区域是单 AZ 的，单 AZ 不可用时，我们会选择进行区域间的切换。在资源紧缺的情况下，我们只能选择部分切换。我们会优先选择切换核心国家的对应核心链路，并在切换过程中密切观察目标区域的容量是否足够。

同城多机房

在海外同城多机房的场景下，如果遇到 AZ 不可用的情况，我们会采取以下措施：

我们根据不同地区的业务高峰和低谷，以及不同地区的时差，来灵活地调整容灾策略。例如，因为美洲和亚太地区存在 8 个小时的时差。这个时差实际上为我们的容灾策略提供了一个天然的窗口。具体来说，当亚太地区处于高峰期时，美洲地区正好是低峰期。因此，如果亚太地区的高峰期容量不足，我们可以考虑优先将流量切换到美洲区域，因为那里此时正处于低峰期。同时，我们也可以选择将一部分流量保留在亚太地区的内部，但我们会相应调整流量的比例。

因此，在海外，先同城后异地不一定是最佳默认策略，我们可以考虑利用海外的天然特点，例如时区来做容灾的第一判断依据，根据事故发生时的时区特点来决策，第一优先级是同城容灾，或者是异地切流，因为容量是我们容灾首要考虑的因素。

海外重大事故根因分析

根据我们近二三年的不完全统计，海外基础设施类的事故几乎每个月至少发生一起，而且几乎可以导致核心业务中断最长可达数小时，这对于业务发展期的我们来说是非常致命的。重大事故，如机房级事故，有时修复时间甚至长达数周甚至数月。这种情况在国内可能有些公司从未遇到过。

除了自建机房的挑战外，我们还依赖第三方厂商提供的云服务，而这些服务同样存在问题。综合来看，海外业务建设面临的挑战远大于国内：例如海外基础设施建设的验收标准与国内完全不同。机房的验收流程也不尽相同，会与国内有比较大的差别，这些也导致了交付之后进入到运行态了，仍然会有较多基建类的基础问题频发。此外，海外机房是否有隔断、高温时如何降温、限电情况下如何使用柴油发电机等，因此，我们时常会遇到机房漏水，塌方，掉电，进动物等等导致服务不可用的情况，而遇到这些情况时，处理措施的不完善，能力的不成熟以及物料供给的不及时，叠加海外人员的沟通差异，都会导致事故的持续时长均是国内的几倍甚至几十倍。

我想给计划出海的业务提供一些建议：进行海外建设时，在前期就制定好准入标准，并进行风险巡检。当事故发生后，重点不在于我们的能力建设有多完善，而在于如何与海外团队进行有效沟通与协作。我们需要考虑如何在文化、地域以及法律、法规完全不同的情况下，确保海外团队能够与我们很好地配合，从而达成我们的容灾和应急响应预期。

容灾策略的实施重点

这部分介绍我们实施容灾的策略和重点。在考虑实施容灾时，我们需要关注以下几个关键点。

容灾架构设计

我们的容灾架构设计应基于我们公司历史上发生过的实际案例，同时考虑在架构设计过程中可能遇到的风险。我们可以借鉴业界的经验和我们公司在发展过程中遇到的各种事故。架构设计应该结合我们的经验教训，通过学习和研究，反馈到我们的日常建设中。

在建设这一部分，除了基础架构的部署建设，我们还需要考虑在问题发生后如何快速进行容灾逃逸，即我们的容灾预案能力。这包括整个容灾平台的建设、预案的制定，以及相关能力的构建。

建设完成后，我们必须进行相应的演练和验收。这是为了确保我们的容灾计划完全符合预期，能够真正在灾难发生时发挥作用。容灾演练是验证和提高容灾计划有效性的关键步骤。

预案建设

整体而言，预案建设是一个长期的过程，它需要我们基础设施层、基础产品组件层以及上层业务层的协同合作。

在许多公司中，都有一个中台概念的预案平台。这个平台的底层需要集成众多底层组件，比如流量管理、基础配置、服务管控等基础能力。除了这些基础建设的输入和接入外，我们还要考虑如何面向上层业务的容灾场景提供支持。

我们的目标是能够以可配置化的方式、以非常低的成本，实现高可靠性的容灾建设，以保障我们的核心业务。无论是链路层面还是大面积机房层面的容灾和逃逸，都是我们重点关注的方向。

容灾演练

除了能力建设之外，我们非常关注建设结果是否完全符合预期，因此，预案的演练是极为重要的，但进行演练的成本是非常高的，包括场景评估、组织人力以及投入的时间和精力等。我建议大家在进行能力验收时，应基于长远和中长期的考虑，以降低成本为目标。字节跳动在容灾演练方面的演进过程是从最初的全员现场参与，逐渐过渡到部分在线参与，再到全面在线进行，最终发展到红蓝对抗和突袭演练的模式。我们希望将对容灾能力和预案验收的能力持续地融入到日常工作中，以更低的成本、更高的效率，配合更低损，甚至无损的方式，确保容灾能力和预案的持续高可用性。

小结

最后，我想简单地总结一下我们的容灾建设和演练的情况，并分享一些思考。虽然字节跳动在容灾建设和演练方面一直不断努力，但我必须承认，我们还没有达到一个非常完善的结果。不过，从策略上讲，我们始终坚持常态化的建设，并基于建设结果进行持续化的验收，以此来推动我们的容灾能力向更好的方向发展。

在国内容灾和海外容灾方面，我们目前都在采用同城容灾加异地多活的模式，并且我们正在持续不断地完善整体的容灾能力建设。从当前的成果来看，我们的核心业务在国内外已经能够实现在 20 分钟之内完成区域间的流量切换，同时在半小时之内完成存储层的切换。虽然我们认为还有提升的空间。正如许多业界公司和从事容灾工作的同事们都知道的，容灾能力的提升是一个持续优化的过程。

在容灾建设中，我们特别关注三个关键词：资源、流量和数据。容灾建设强依赖于资源评估。无论是专线中断还是 AZ 不可用的情况下，我们的首要任务是评估资源容量是否充足。我们需要判断是同城资源不足，还是异地资源不足。基于资源评估，我们再考虑流量是否可切换，能切换多少，如果资源不足，我们需要决定哪些业务或服务需要降级。数据的恢复也是一个不可忽视的问题。灾难场景下的逃逸通常会导致一定的数据损失，如何修复数据是我们必须重点关注的问题。

至于国内和海外容灾的差异性，国内可能会根据业务类型选择不同的异地多活部署模式。而海外可能会采用单元化的策略，比如按照国家维度进行部署。同时，我们在进行区域间流量切换时，也会考虑不同国家和地域的部署特点。

在容灾实施方面，我们主要关注做好容灾架构设计，并结合常态化建设，逐步完善容灾能力。此外，周期性的常态化演练也是确保容灾预案持续可用的关键。

最后，我想强调的是，在进行能力建设时，我们必须重点考虑容灾相关产品平台自身的高可用性。因为在重大灾难发生时，容灾平台的可用性可能是我们最后的救命稻草。因此，确保这些平台的鲁棒性和可靠性是至关重要的。

经验总结

最后，我想给大家提供一些经验总结和建议。

1. 容灾与常态化建设的结合： 容灾不仅仅是作为最后的保障措施来建设，而是期望其结果能够反馈并提升我们的常态化建设。容灾的考虑应该融入到前期的架构设计和部署中，在规划业务、机房容量、专线容量以及存储计算部署模式时，都应该将容灾作为一个核心部分来考虑。
2. 容灾能力的持续优化： 容灾能力的建设不是一次性的，而是一个随着业务发展和公司整体架构调整而不断优化的过程。因此，希望大家能够重视容灾演练、验收以及常态化预案的持续化管理，并且采用逐步降低成本的方式来进行。
3. 准备最糟糕场景的应对策略： 在所有前期工作完成后，我们需要考虑可能发生的最糟糕场景，并为之做好准备。这是我们的最后保障措施，相当于一个保命策略。即便我们不确定前期工作是否做得足够充分，也必须有一个兜底计划来应对极端情况。