云原生时代的业务连续性：双活还是容灾？

土耳其和叙利亚两次7.8级的强震（2023年2月6号）造成了巨大破坏和惨重损失，这也再次提醒我们居安思危，构建业务连续性能力来抵御不可预期的灾害的必要性。从IT角度而言，我们追求的业务连续性就是不管天灾人祸，都能够在可接受的水平上持续为业务服务提供支撑，这不仅是有明确可计算的经济价值，在关键时刻带来的社会价值更是无法估量。

构建业务连续性系统的具体技术本身会随着计算生态的改变而改变，但是业务连续性系统的底层逻辑和方法论是一脉相承的。

传统IT时代：容灾和双活是业务连续性进化的不同阶段

在传统IT的业务连续性建设上，一般会经历主备中心（Active-Standby)，生产查询中心（Active-Query)，再到双活中心（Active-Active）三个阶段，每个阶段的业务连续性能力是不断飞跃的，尤其是在有效减少业务中断的时间上。在主备阶段，业务需要在备端重启，RTO一般在小时级；到了生产查询阶段，交易型业务仍然无法做到实时切换，但是查询业务可以在灾备站点连续对外提供服务；再到双活阶段，业务可以在站点间做到无缝切换，消除业务中断。所以双活一直是业务连续性建设所追求的更高目标。

然而，从主备中心，到生产查询中心，再到双活中心，其投入的建设成本和方案复杂度也在急剧上升。主备中心，包括扩展出来的两地三中心架构，在基础设施层面就可以有通用且成熟的建设方案。对于生产查询中心，除基础设施能力建设外，已经牵扯到业务应用的改造，进行交易和查询业务的分离，方案复杂度大幅增加，但因为灾备中心平时只需要承载只读的查询业务，技术难度依然相对可控。而对于双活中心，不可避免的需要将整体业务应用改造成分布式架构，牵涉到从存储和网络基础设施、到中间件和数据库、再到上层应用本身和流量分发的整个链条，建设成本投入、项目周期和后期管理复杂度都非常之高。

云原生时代的业务连续性需求

现今，以容器和Kubernetes为基础的云原生架构已成为广泛流行的新一代企业IT基础设施，在互联网、金融、政府、先进制造等关键行业，有越来越多的云原生关键业务应用开始在正式的生产环境中运行，从合规和数据安全的角度，进行云原生业务连续性系统建设已经成为刚需。此外，针对容器和Kubernetes环境的攻击也在快速增长，据安全公司StackRox的研究报告显示，其94％的企业受访者在过去12个月内在其Kubernetes和容器环境中经历了安全事件，因此，对于云原生业务连续性建设的迫切性也越来越强。

作为一个颠覆性的新技术生态，云原生系统的以下特点使得传统成熟的基于中间件和虚机的业务连续性方案不再适用：

云原生是一个以应用为中心的系统。容器化的应用和微服务会由kubernetes平台自动在几百乃至上千台物理机或者虚拟机中进行调度，用户不关心也很难去跟踪到应用在哪个机器里运行，所以传统方案针对机器粒度进行灾备保护就无法工作。另外一个方面，完成一个业务需求的云原生应用包含了许多种组件和微服务，相关的镜像、配置信息、以及持久化数据，需要作为一个整体被备份保护起来，而恢复时也需要端到端的恢复整个应用和数据，这是跟传统灾备非常不一样的地方。
云原生天然是多云的。Kuberenetes平台屏蔽了底层基础设施的差异性，符合Kubernetes规范的应用可以在任何一个Kubernetes平台上运行，因此针对云原生的业务连续性方案设计必须立足于多云。例如，在一个Kubernetes集群中备份下来的应用和数据，需要能支持在其它Kubernetes平台上顺利进行恢复；同时，需要能在不同的Kubernetes平台间进行跨云的容灾和迁移。
云原生是一个全新的生态，有自身的开发运维的工具链和最佳实践，比如快速部署、高度自动化运维、声明式API、跟Prometheus和ELK的集成等等，业务连续性方案本身也必须融合在这个生态里。

因此，在云原生环境下，我们需要为这个新的生态量身定制全新的业务连续性方案。方案要能在Kubernetes自身集群内高可用的基础上，对于其它可能对业务连续性造成严重影响的故障因素，如病毒、黑客攻击、人为失误、应用缺陷等逻辑故障，K8s集群升级、维护造成的集群级别故障，以及超越了集群级别的更大域的故障，如机房、云的可用区级别的电力/网络故障等，也能提供额外的手段来保障业务的连续性。

在云原生时代构建业务连续性能力，依照循序渐进的思路，按照成本、自动化程度以及RPO/RTO效果，可以分为三种方案：基于备份恢复的方案，基于主从切换的跨集群灾备方案，以及跨集群双活方案。

云原生时代的备份与恢复

备份恢复是一种成本低廉，适用性广的方案，对容器环境下的多数工作负载都能够进行有效的保护。备份恢复方案的缺点是RPO和RTO往往在小时级或天级，对于很多关键业务而言，无法满足业务的连续性要求。

在容器环境下，针对无状态应用的保护、有状态应用的保护和集群的保护，都有多种备份的方法。在企业生产环境中，使用专业备份软件可以有效提升运维效率，降低操作复杂度。

保护对象	示例	保护内容	保护方法
无状态应用	Web服务、Spring Cloud等	应用信息、配置信息	✔ 发布流程（DevOps） ✔ 专业备份软件 ✗ 手工备份（YAML文件）
有状态应用	数据库、消息中间件、大数据等	应用信息、配置信息、持久卷	✔ 专业备份软件 ✗ 手工备份（YAML文件、数据库备份）
集群	社区版、Rancher、Kubesphere等	K8s集群配置本身、厂商发行版定制部分	✔ 专业备份软件 ✗ 手工备份（etcd备份）

在容器环境下，实施备份恢复方案通常还需要考虑的其它方面包括：

方案部署和管理的简便性，如能否在容器环境中直接部署，能否支持多集群同时管理。
应用的自动发现与精准定义，能否做到整体应用的完整保护与恢复。
数据一致性保障，能否支持宕机一致性与应用一致性。
基础设施无关性，能否在其它异构集群上进行恢复，自动屏蔽存储和平台差异性。

云原生时代的容灾

相对于备份恢复而言，容灾方案会以低RPO和RTO为设计目标，同时能够为管理员提供更加自动化的端到端故障切换流程，以及故障恢复后的回切流程，减少人工失误，提高容灾切换效率。

在云原生环境下，基于主从切换的跨集群容灾是一种成本较低、适用性强的业务连续性方案。通过主从容灾管理系统，可以自动化的实现容器应用、持久化数据和容器镜像的跨云跨集群同步，在遇到主集群故障时，可以通过容灾管理系统自动化的完成应用级别或整个集群级别的数据切换、镜像服务切换、应用切换与流量切换，从而保障业务的连续性和高可用性。

在云原生容灾方案中，容器应用和配置信息的数据量较小，可以比较容易的进行主从集群的同步。容器镜像一般的更改频率较小，目前主流的镜像服务（如Harbor等）也都提供了完善的的同步功能。因此整个方案的RPO主要取决于数据卷的同步方案，根据不同数据卷同步技术的差别，主从切换的RPO可以做到分钟级、秒级甚至RPO=0。

在云原生容灾方案中，灾备集群上的应用配置会克隆自生产集群，容灾管理系统会自动化完成应用相关资源的切换，RTO主要取决于Kuberenetes调度器启动应用实例的速度（包含镜像拉取的时间），在实践中可以从秒级到分钟级别。

因为主从切换的方案是在从集群复制出一份主集群的应用，而无需人工介入重新发布应用，因此可以适用于大多数容器应用（无状态或有状态应用），并且无需进行应用改造，也无需改变现有业务应用的发布流程，因此是一种成本较低、建设周期短，同时对运维友好的方案。

云原生容灾方案的其它考虑因素包括：

跨云的异构集群之间容灾时，是否能实现异构基础设施的自动适配和转换。
容灾集群的K8s版本不同时，能否能够支持应用在容灾集群上的顺利拉起。
提供容灾演练的能力。
提供完善的监控和报警功能。

云原生时代的双活

通过DevOps流水线和发布系统实现双活发布

在云原生的环境下，对于无状态应用而言，如果应用本身就是分布式的设计与实现，也充分考虑了跨数据中心的网络延迟等相关因素的影响，那么双活的发布是相对比较简单的。包括Karmadar或者OCM等多集群管理的项目现在都能实现容器应用在多Kubernetes集群上的同时发布与管理，再加上全局负载均衡器和流量分发，基本上就能快速构建一个双活的应用系统。

然而这里一个重要的误区是，云原生双活发布并不等于云原生双活系统本身，而只是云原生双活系统建设中的一个环节。

双活发布本身没有提供完善的切换流程管理，当主集群故障，将业务流量切换至从集群上的应用需要人工介入。而当主集群修复后，如何在主集群上重新部署应用实例，再进行流量的重新分发，也依然需要人工介入。这里的人工介入需要针对每个应用来操作，当需要管理的双活应用数量非常大时，切换效率和可靠性都会受到挑战。
双活发布无法解决有状态应用的双活切换，管理员仍然需要借助其它工具和手段实现数据的共享和双活访问。
双活发布对异构集群支持难度大，当两边K8s集群版本或者厂商不同时，需要在Devops流程中针对不同集群构建不同的应用发布版本，在部署时需要手工选择合适的版本进行发布，这也对运维团队带来了不少的压力和挑战。

云原生双活依然是需要高投入的复杂方案系统

在云原生的环境下，依然不存在通过平台层面实现的通用双活方案，双活方案必须针对具体的业务应用来设计，需要综合考虑流量层、应用层和数据层的同步和切换技术。

在上图所示的一个简单云原生双活方案中：

应用的多个分布式实例（图中应用服务1-4）可以通过多集群发布同时部署在跨云的多个K8s集群上，相互协作对外提供业务服务，由全局负载均衡器进行业务流量的负载调度。
数据服务由跨集群的双活数据库提供，通过数据库层的实时数据复制完成业务数据的同步和双活访问。
数据服务通过服务聚合，提供从应用服务实例到数据服务实例之间的跨集群访问。

整个双活系统的建设需要应用团队、中间件团队和平台团队共同参与，方案的复杂度和成本都较高，一般建议针对少数刚需的核心应用系统来实施。

云原生时代业务连续性最佳实践

云原生时代的业务连续性建设，到底是选择双活还是容灾？其实没有统一的答案，最佳实践还是需要根据企业自身阶段性的业务连续性需求，团队的技术能力，以及预算来因地制宜的设计，云原生备份、容灾和双活系统都是可选项。按照国内多数企业的云原生发展进程而言，可以循序渐进，先针对整体应用和容器平台构造完整的备份、容灾能力，然后选择性的针对关键核心应用实现双活。