阿里云原生专家复礼：多活容灾建设思路与经验分享
凌云时刻
编者按：2021年7月2日，阿里云用户组（AUG）的首场线下活动在济南召开。阿里云原生专家李华结合自身多活容灾领域经验，跟数十家山东企业分享了多活容灾建设思路和应用场景。本文根据作者的现场演讲整理而成。
首先，故障是不可避免的。
即使现在通过分布式技术架构，应用在单机房里面做了全链路分布式，但是像一些大型的灾难，比如说自然灾害、断电断网，小概率事件仍然会造成致命故障，影响系统可用性。尤其是云原生应用体系下，应用的敏捷开发带来的系统高频变更、代码发布，仍然会给我们的系统带来很多不确定性甚至故障。
我们有一个客户，他就是因为发布的时候，代码修改造成故障，导致机房内的应用不可用。最终就是花了很长的时间来找问题来纠错，对业务造成了影响。下图可以看到去年各大云厂商遇到的故障，虽然云平台给客户提供了高可用性，但对于需要保持连续性的业务来讲，还需要进一步的方案保障。
故障应对：先恢复业务，再定位故障
在生产环境下产生的故障，很难快速定位故障，因为时间和业务压力都不允许长时间去进行故障定位。更重要的是如何快速恢复业务，让业务跑起来。所以遇到故障时我们就有一个核心的理念，即先恢复业务，再定位故障。
图左边就是我们传统故障定位方式，故障发生时，先排查再恢复。在一个生产环境里面，面临着业务线那么大的压力的时候，很难把定位问题做完，即使做完了，也很难给一个准确的系统恢复时间。这个时候我们希望能够以恢复业务为第一优先级，先恢复再定位错误。问题产生，我们先不要去找问题，先把业务恢复，这个是最核心的一个区别。
双活就是要帮助客户快速恢复业务，以业务可用为第一优先级。双活涉及到几个层次的内容：
第一个是资源双活。对于公共云或者私有云，都需要双份的资源；
第二个是应用双活。两边的应用及数据如何处理，都需要进行精准的设计，当然在方案进行时我们尽量把复杂度降低，由产品及SDK完成双活；
第三个是业务双活。数据层面中多读多写的处理非常重要，需要根据具体的应用场景来确定数据读写的方式，比如同城双活与异地双活的数据处理方式是不一样的，读多写少的业务与读少写多的业务，处理方式是不一样的，这些都需要根据具体场景进行设计。
这是目前市场上主流的几种容灾方式。
灾备是过去大家常采用的一种方法，这个场景下有很多的劣势：第一灾备机房没有任何流量，平时是不起作用的，是资源的浪费；第二最关键如果真产生问题了，灾备机房起作用的机会不大，因为系统有没有部署好，数据有没有同步好，能不能正常恢复应用，没人敢打包票。
为了实现真正的业务双活，系统产生问题时敢切、能切，我们可以通过应用双活来解决灾备里的痛点，双活方案又分成同城、异地，最终发展到异地多活。
以同城双活为例，在这个体系中，同城两个机房同时在处理业务流量，一个机房发生问题时，可以方便地切换到另一边。因为同城的距离是可控的，距离可控意味着延迟可控，对业务的影响可控。同城双活具备很多优势，例如部署简单，业务侵入少，这样可以减少客户的实施成本，不用动业务。当然它也有一定的劣势，因为两个机房仍在一个区域，对于区域级别的自然灾害是无法抵御的。
异地双活和同城架构类似，区别是机房由同区域迁移到另外一个区域，可以抵御区域级的故障，但由于物理距离的增长，对业务系统的延时带来较大影响。如果客户的业务是一些延时敏感的应用，需要小心设计。
为了摆脱物理距离带来的延时影响，又保持区域级别的故障抵御，可以选择异地多活方案，它通过对应用的单元化改造，把应用通过多单元部署的方式，每个单元服务于本区域内的业务，保障快速响应；产生故障时可以在不同单元间切换。它很好的同时解决了两个问题。但它的改造成本较高，需要仔细的梳理业务，确定可以做单元化改造的数据维度以及改造工作内容。
在同城双活、异地双活、异地多活等方案中，由于思路与设计的改造，需要重新审视方案的变化以及面临的新问题。首先是流量管理问题，双活方案对于流量的管控要求较高。包括容灾切换数据质量的保障、数据同步策略的执行、多数据中心如何进行统一管控、双活方案在同城/异地间的演进，都需要在方案中一一考虑并解决。
整体来看，双活方案的架构上面临着一些挑战，需要相应的能力来解决这些挑战。
首先对于用户，双活方案的最终使用场景是故障时的切换，进行业务保障，而切换过程中流量如何控制、应用如何按步骤执行、数据库如何避免脏写等技术细节，都需要包装在产品与方案中，提供给客户的是一个可观测、可执行的一站式管控界面，尽量降低客户的运维与使用成本，整个方案才具备可行性。
第二，双活的基础与前提就是底层平台资源的冗余，例如同城2个机房、异地2个机房、异地多个机房，为上层应用提供资源支撑。所以云平台本身，及以上的各种云服务，都需要具备高可用能力、数据同步能力、分布式架构能力，以实现资源的冗余。
第三，流量可控，是整个双活方案的核心，只有接入、应用、数据里的业务流量可控，我们才能对业务进行管理，这里面需要支撑多种协议、多种产品的协同、流量管理，如同机房流量封闭，接入流量纠错，大规模的策略管理等，这样才能全面的覆盖双活中的种种情况与场景。
最后，双活方案必须是可演进的，因为每个客户发展的状况不同、硬件条件不同，比如有的客户只能提供同城机房、有的客户可以提供异地双机房、机房间网络的成本、机房本身的风火水电等情况，都会影响方案的选择，而客户本身又是在不断的发展，一定要给客户提供一个可持续演进的方案路线。
应用场景
双活方案中两个典型的应用场景，同城多活和异地双活。
同城多活，顾名思义就是分布在同城的多个站点同时对外提供服务。同城的含义是机房间物理距离较小，可一般会要求小于50KM。同城多活的多个站点共享同一套PAAS层云服务，在此基础上建立上层业务的同城多活以及容量扩展性。
看一个最典型的场景，在同城双活场景中，底层的云平台资源及产品是双机房部署的，由阿里的另一个云平台容灾产品来保障平台和产品的可用性，上层的应用通过msha来进行管理。这个场景下客户的业务系统修改的地方较少，可以认为对业务无侵入，通过流量层进行业务流量的分发；产品保障应用层实现本机房流量优先或者跨机房调用，最终两个机房应用的数据同时读写一个数据库，这样大大降低的机房间数据不一致的风险，同时又可以提供应用低延时的体验。
异地应用双活，顾名思义就是分布在异地的多个站点，所有站点均对外提供服务。当一个站点发生灾难或者业务流量调整时，另一个站点可接管流量，对外提供服务。应用双活，表示应用组件做到双活。在双活里面每个对外提供服务的站点，我们称之为单元（Unit），应用双活架构的单元也称之为应用单元。
异地双活真正实现了业务流量的切割，以下图为例，应用单元化后，分别部署在异地机房，每个机房负责本区域内客户的闭环业务，即业务全部本完成，很好的保障了用户的使用体验；如果产生问题，可以通过管控台把业务流量在短时间内切换到另外一个单元，实现业务高可用。
在这个过程中，不同单元间的数据通过云平台数据服务进行双向数据同步，来保障数据的一致性。
双活单元化方案对业务有一定要求，如果是需要业务全局一致性的业务就难以通过单元化拆分，所以这个过程需要对业务进行仔细梳理，来确认从哪个维度，对什么样的业务进行单元化改造。但大家注意这个单元化改造并不是对业务逻辑进行修改，而是在原有逻辑不动的基础上，加上双活的处理逻辑，例如流量打标操作。所以大家不用担心对既有业务代码有影响。
双活建设预期效果
最后总结一下，通过多活方案，在预防、决策、切换恢复等阶段，可以尽量让研发和运维放心休息，同时系统保持高可用性。希望达到的目标是随时的预防，1分钟能发现问题（但不是解决问题），5分钟定位，如果定位不了要快速执行止血方案，实现10分钟业务恢复的效果。
当然这是我们一个理想当中的愿景，要实现这个目标，需要结合客户具体软硬件情况、RTO/RPO的需求、客户的业务系统状态，来综合制定业务可高用方案。我们相信通过多活方案，会为大家的业务连续性带来巨大的提升。（完）
↓↓↓