在 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 的流量切换。如果资源不足，我们依旧会选择进行区域间的切换，这与刚才提到的专线中断的情况类似。与同城容灾不同，异地容灾会有一个选择过程：先判断同城资源，如果同城资源不够，再考虑区域间的容灾策略。同时，我还要强调一点，由于单元化部署可能存在较大差异性，如果在单元化场景下选择进行整个区域间的切换，我们必须先对相应的单元化策略进行调整，以避免由于区域间切换导致的一些数据不一致问题，这需要业务侧制定一些预案，例如说禁写。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

容灾与常态化建设的结合：容灾不仅仅是作为最后的保障措施来建设，而是期望其结果能够反馈并提升我们的常态化建设。容灾的考虑应该融入到前期的架构设计和部署中，在规划业务、机房容量、专线容量以及存储计算部署模式时，都应该将容灾作为一个核心部分来考虑。

容灾能力的持续优化：容灾能力的建设不是一次性的，而是一个随着业务发展和公司整体架构调整而不断优化的过程。因此，希望大家能够重视容灾演练、验收以及常态化预案的持续化管理，并且采用逐步降低成本的方式来进行。

准备最糟糕场景的应对策略：在所有前期工作完成后，我们需要考虑可能发生的最糟糕场景，并为之做好准备。这是我们的最后保障措施，相当于一个保命策略。即便我们不确定前期工作是否做得足够充分，也必须有一个兜底计划来应对极端情况。

– END –

火山引擎作为字节跳动旗下的云服务平台，旨在帮助企业构建体验创新、数据驱动和敏捷迭代的数字化能力。近期，火山引擎云原生团队基于字节跳动多云容灾最佳实践，推出应用多云多活解决方案，帮助用户在多云迁移过程中同时完成多活架构升级。

• 同城多活解决方案：为用户提供多云统一服务发现、统一应用调度、统一数据同步、统一故障迁移等能力助力用户零侵入零改造实现应用多活架构升级；

• 异地多活解决方案：提供单元化分片策略最佳实践，流量和数据基于分片策略严格单元调度、数据跨region同步和冲突检测等平台能力。同时协助客户进行单元化架构演进分析，提前识别如:数据库主键或自增冲突、业务时序一致、性缓存一致性、写后读一致性等问题，与客户一起基于单元化架构构建异地多活能力。

未来，我们将详细拆解更多应用在多云多活改造中经常遇到的技术问题和解决方案，欢迎感兴趣的用户扫码咨询：

[1] 火山引擎: www.volcengine.com

[2] VKE：www.volcengine.com/product/vke