点击上方👆蓝字关注我们！
来源 | InfoQ
声明 | 本文由 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 不可用的情况下，我们的首要任务是评估资源容量是否充足。我们需要判断是同城资源不足，还是异地资源不足。基于资源评估，我们再考虑流量是否可切换，能切换多少，如果资源不足，我们需要决定哪些业务或服务需要降级。数据的恢复也是一个不可忽视的问题。灾难场景下的逃逸通常会导致一定的数据损失，如何修复数据是我们必须重点关注的问题。
至于国内和海外容灾的差异性，国内可能会根据业务类型选择不同的异地多活部署模式。而海外可能会采用单元化的策略，比如按照国家维度进行部署。同时，我们在进行区域间流量切换时，也会考虑不同国家和地域的部署特点。
在容灾实施方面，我们主要关注做好容灾架构设计，并结合常态化建设，逐步完善容灾能力。此外，周期性的常态化演练也是确保容灾预案持续可用的关键。
最后，我想强调的是，在进行能力建设时，我们必须重点考虑容灾相关产品平台自身的高可用性。因为在重大灾难发生时，容灾平台的可用性可能是我们最后的救命稻草。因此，确保这些平台的鲁棒性和可靠性是至关重要的。
经验总结
我想给大家提供一些经验总结和建议。
容灾与常态化建设的结合 ：容灾不仅仅是作为最后的保障措施来建设，而是期望其结果能够反馈并提升我们的常态化建设。容灾的考虑应该融入到前期的架构设计和部署中，在规划业务、机房容量、专线容量以及存储计算部署模式时，都应该将容灾作为一个核心部分来考虑。
容灾能力的持续优化 ：容灾能力的建设不是一次性的，而是一个随着业务发展和公司整体架构调整而不断优化的过程。因此，希望大家能够重视容灾演练、验收以及常态化预案的持续化管理，并且采用逐步降低成本的方式来进行。
准备最糟糕场景的应对策略 ：在所有前期工作完成后，我们需要考虑可能发生的最糟糕场景，并为之做好准备。这是我们的最后保障措施，相当于一个保命策略。即便我们不确定前期工作是否做得足够充分，也必须有一个兜底计划来应对极端情况。
点击【 阅读原文 】咨询火山引擎多云多活解决方案