应用多活技术白皮书.pdf

3234156784第一章 应用多活的起源1.1 容灾成为企业上云和用云的基础要求1.2 灾备容灾的局限性1.3 应用多活：以应用为中心的云原生容灾架构1.3.1 应用多活的概念1.3.2 应用多活的优势1.4 阿里巴巴的应用多活之路1.4.1 集团阶段1.4.2 云化阶段第二章 应用多活的典型架构2.11同城场景的应用多活2.21异地场景的应用多活2.3 混合云场景的应用多活第三章 应用多活的技术分析 3.1 应用多活的课题研究3.1.1 应用多活解决的技术问题3.1.2 应用多活领域的研究状况3.2 应用多活的设计标准3.3 应用多活的技术方案第四章 应用多活的技术原理4.1 应用层技术原理4.1.1 接入网关实现原理4.1.2 微服务组件实现原理4.1.3 消息组件实现原理4.2 数据层技术原理4.3 云平台技术原理第五章 应用多活的管理策略5.1 应用多活的投入产出比5.1.1 应用多活的收益5.1.2 应用多活的成本管理5.1.3 投入产出比分析5.2 应用多活的能力保鲜第六章 应用多活的实践案例6.1 同城应用多活行业案例6.2 异地应用多活行业案例6.3 混合云应用多活行业案例第七章 应用多活的未来展望7.1 混合云多活将成为客户上云的关键决策点7.2 应用多活成为云原生容灾领域的新标准7.3 分布式云场景的应用多活7.4 AIOps 加持的应用多活7.5 多云多芯的应用多活附录：名词术语第一章 应用多活的起源51.1 容灾成为企业上云和用云的基础要求2019 年 IDC 发布的全球云计算 IT 基础设施市场预测报告显示：2019 年全球云上的 IT 基础设施占比超过传统数据中心。越来越多企业因为云计算低成本、稳定性而选择在云端构建系统，云已经变成了一个主流 IT 基础设施。近年来，开源技术和云技术保持高速发展，出现种类繁多的产品和服务，技术人员决策权变大，架构更迭速度日益加快。在高速演进的过程中，要谨防人为的不合理故障，同时也要关注自然灾害的影响。一次不恰当业务中断，可能带来严重的品牌、客户、经济损失。所有的上云企业都把容灾系统能力建设作为最基础目标来要求，并保证投入。只有确保灾难发生时，关键数据不丢失，系统服务尽快恢复运行，企业才能保证长久、平稳的高速发展。1.2 灾备容灾的局限性灾备容灾建立在数据级容灾的基础之上，常用的实现方式是在备份机房构建一套相同的应用系统，灾难发生时会在约定的时间范围（RTO）内恢复运行，尽可能减少灾难带来的损失。在实际实施时，存在以下几个问题：灾备中心平时不提供服务，在切换到灾备中心的关键时刻时无法确定是否可以成功切换。灾备中心平时不提供服务，整个灾备资源会处于闲置状态，成本浪费比较高。灾备中心平时不提供服务，所以平时提供服务的机房还停留在单地域，当业务体量大到一定程度时，这种模式无法解决单地域资源瓶颈的问题。6图 1-1“同城灾备架构”和“异地灾备架构”示意图1.3 应用多活:以应用为中心的云原生容灾架构1.3.1 应用多活的概念“应用多活”是“应用容灾”技术的一种高级形态，指在同城或异地机房建立一套与本地生产系统部分或全部对应的生产系统，所有机房内的应用同时对外提供服务。当灾难发生时，多活系统可以分钟级内实现业务流量切换，用户甚至感受不到灾难发生。阿里巴巴的“同城多活架构”和“异地多活架构”（代号“单元化”）都是典型的应用多活实现技术。图 1-2 阿里巴巴“同城多活架构”和“异地多活架构”示意图71.3.2 应用多活的优势分钟级 RTO：恢复时间快，阿里内部生产级别恢复时间平均在 30s 以内，外部客户生产系统恢复时间平均在 1 分钟。资源充分利用：资源不存在闲置的问题，多机房多资源充分利用，避免资源浪费。切换成功率高：依托于成熟的多活技术架构和可视化运维平台，相较于现有容灾架构，切换成功率高，阿里内部年切流数千次的成功率高达 99.9%以上。流量精准控制：应用多活支持流量自顶到底封闭，依托精准引流能力将特定业务流量打入对应机房，企业可基于此优势能力孵化全域灰度、重点流量保障等特性。1.4 阿里巴巴的应用多活之路1.4.1 集团阶段在 2007-2010 年期间，阿里巴巴采用同城多活架构保障在线业务的高可用。同城多活架构能够抵御机房级故障，即：同城任一机房发生故障，其他机房都具备实时接管能力。但是同城架构存在地域单点的隐患。2013 年，随着业务规模的逐年攀升，阿里巴巴面临杭州机房容量不足的问题。与此同时，杭州的夏天大约持续了 1 个月 40高温，机房全天 24 小时空调不间断的工作，持续高温用电量飙升让机房存在被限电的风险。如果断电情况发生，对业务将是直接跌 0 的影响，阿里工程师就在每天的惊心吊胆中度过了这异常“Hot”的 1 个月。在容量和灾难的双重压力下，阿里工程师开始发起内部代号单元化的异地多活项目，提出1 年验证，2年双活，3 年多活的目标。2013 年，阿里工程师在杭州同城两个机房完成多活技术可行性论证。2014 年，为了保障技术的稳定演进，工程师挑选距离杭州相对较近的上海进行生产双活试点，成功构建杭州和上海两地异地双活架构，阿里正式成为业内第一个具备异地多活的企业。2015 年，在具备 2 年双活成熟实践经验的基础上，阿里工程师开始探索多个数据中心多活的技术可行性，攻坚多单元梳理、改造、数据同步、运维等一系列难关，生产业务部署在千里之外的三地四中心，具备生产级别可用的异地多活能力。2017 年，异地多活构建的多单元成为阿里的基础设施，阿里多个新兴技术均依托多活能力进行生产规模化的测试验证。同年双十一，阿里工程师为支撑业务提出在双十一凌晨切流的目标，如何在减少在线业务流量影响面下更快更稳的流量切换成为多活重大的挑战。8图 1-3 阿里应用多活发展之路2017 年，异地多活支撑双十一平稳进行数据中心流量调度数次，意味着在已有的日常稳定性保障基础上，异地多活已具备大促时期流量无损的秒级切换能力。1.4.2 云化阶段2019 年年初，阿里巴巴 CTO 行癫提出在 2019 年阿里巴巴核心系统全面上云的目标，与此同时，外部企业在稳定性的挑战下，提出希望阿里对外输出成熟的多活架构经验的需求。阿里工程师为服务集团上云应用和外部客户，将多年沉淀的多活技术产品孵化上云，以阿里云云产品的形态服务阿里巴巴集团和外部客户，以丰富多样的多活架构支撑不同的业务形态。在 2019-2021 年期间，应用多活云产品（AHAS-MSHA）先后帮助数字政府、物流、能源、通信、互联网等十余家不同行业中的大型企业成功构建应用多活架构，基于大型企业的行业经验，应用多活进一步演进出混合云多活等一系列新特性。2022 年初，随着企业对容灾诉求日益强烈的诉求增强，应用多活的发展需要更多的组织和人介入共建，推动应用多活的发展。阿里工程师正式把多活架构代码对外开源，命名为 AppActive，希望和社区企业、开发者共建多活生态和能力，在阿里多年应用多活经验的基础上，结合社区的需求和贡献，帮助企业构建高可用架构。第二章 应用多活的典型架构92.1 同城场景的应用多活图 2-1“同城应用多活架构”示意图同城应用多活对应用系统的代码侵入较小，基于灵活的流量调度和单元格间的流量路由，能做到故障场景下的业务快速恢复，实现业务恢复与故障恢复的解耦。同城应用多活，顾名思义就是分布在同城多个机房内的应用同时对外提供服务。同城机房物理距离较小(物理距离小于 100 公里)。同城场景下多机房的网络、服务互通，某机房局部故障会影响到全局，爆炸半径不可控。应用多活架构的难点，在于机房之间的流量路由和隔离。当某机房出现故障，可以做到机房级的快速切换。更精细化的场景，如果是某中心内某应用的故障，还需要做到应用级的切换。为了实现机房间的流量调度，同城应用多活架构下，建立多个服务部署的逻辑区，这个逻辑区称之为单元格（Cell）。每个单元格内的业务流量尽可能的在本区域内调用优先。由于同城跨机房 RT 较小，因此多个单元格的云服务采用单集群模式，从而可以避免数据一致性上的复杂度。同城应用多活的架构如下图所示：102.2 异地场景的应用多活图 2-2“异地应用多活架构”示意图同城近距离的容灾建设难以抵御地域级别的灾难，参考银行业的容灾标准，灾备中心建设都要求满足“三不原则”（即：灾备中心与生产中心不应设立在同一地震带，同一江河流域，同一电网），因此异地灾备中心一般距离生产中心 300 公里以上。异地应用多活，顾名思义就是分布在异地多个机房内的应用同时对外提供服务。在异地超远距离的场景下建设应用多活，最大的挑战在于超远距离带来的网络延迟。由于网络延迟大，云服务很难跨地域的以单集群的模式提供服务，而多集群模式下会带来数据一致性的复杂度。为了解决单集群无法突破物理距离限制的问题，阿里提出了“单元化”方案。核心思路是对数据进行分片，通过自上而下的流量路由，让特定分片的数据到特定中心完成读写，以此解决数据一致性的问题，并在此基础上解决了业务的容灾和水平扩展问题。这个可以水平扩展的逻辑中心称为单元（Unit）。单元分为两种类型，中心单元与普通单元。单元内部署的业务分为三种类型，全局业务、核心业务、共享业务。中心单元只有一个，部署全局业务、核心业务、共享业务。普通单元部署核心业务、共享业务，普通单元具备水平的扩展能力，可以任意复制。全局业务：强一致性的业务，在中心单元写，在中心单元读。核心业务：做单元化拆分的业务，在普通单元写，在普通单元读。共享业务：被核心业务高频依赖的全局业务读服务，在中心单元写，在普通单元读。112.3 混合云场景的应用多活混合云融合了公有云、私有云、托管私有云、边缘计算节点等不同部署模式，面向企业云上基础架构、中间件、开发全生命周期和/或应用平台的各种能力需求，为云上开发、构建、运维、运营、管控等各种技术与业务实践提供支持。IDC 报告中显示 2021 年有 14%的客户会单独选择公共云，86%企业采用多云混合云架构。混合云应用多活，顾名思义就是分布在混合云环境的应用均对外提供服务。混合云应用多活架构是在多云和异构场景衍生的容灾架构方案，将业务恢复和云基础架构、云服务解耦。混合云多活管理产品对开发者和上层用户屏蔽混合云容灾的复杂度，提供一致的开发、运维、运营体验。混合云应用多活，最大的挑战在于多云独立和多云异构，做到多云集成和数据互通。多云集成，即集成多云的账号、权限、资源、数据，在此基础上构建统一的多云操作界面。数据互通，即多云的基础架构、异构的中间件体系，需要做到互相发现、互相同步，在此基础上实现数据的容灾。为了实现多云集成与数据互通，混合云多活管理需要有多云适配来屏蔽底层的差异，主要依靠三大核心功能：云服务接口适配，对下通过插件化支持多云适配，对上提供统一的云服务接口。数据模型适配，对云的账号、权限、资源、数据进行抽象，屏蔽多云的数据差异。统一容灾接口，提供标准化的容灾定义和接口，利于异构云异构技术栈的快速接入。图 2-3“混合云应用多活架构”示意图第三章 应用多活的技术分析12 容灾指标在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）最多只能同时实现两点，不可能三者兼顾。在容灾场景下，多数系统选择 AP 或 CP 模式。3.1 应用多活的课题研究3.1.1 应用多活解决的技术问题多站点生产系统同时对外提供访问，RPO0 或 RPO=0，应用多活 RTO=应用灾备 RTO。3.1.2 应用多活领域的研究状况典型架构容灾模式衡量指标同城双活CP 模式RPO=0，RTO 分钟级别异地多活AP 模式RPO 0，RTO 秒或分钟级别异地多活CP 模式RPO=0，RTO 分钟级别表 3-1 容灾架构的不同模式 容灾距离可用性代表系统在某个考察时间是可以正常运行或提供服务。描述一个系统可用性的常用指标有响应时间和错误率。不同系统的响应时间有所不同，从用户体感和客户端访问视角都会有某个超时阈值。对于跨地域数据同步的情况，数据库同步复制和异步复制的模式。数据库同步复制会带来一定的响应时间上升。当数据站点距离较远时，响应时间会超过阈值，请求成功率会大幅下降。13 容灾平台企业应用可以选择云产品构建生产系统，技术涉及中间件（Middleware PaaS）、数据库（Database PaaS）、基础设施（IaaS）。在当前的情况下，云厂商间的应用编程接口（API）暂无统一标准。对于混合云多活架构，需要通用平台，为上层业务屏蔽运维和管控的差异性。应用多活领域的实现难点 流量路由一致性从可用性角度，所有业务请求均能够在可接受的时间内有所响应，并且请求质量不随着机房的物理距离和云平台设施的不同而改变。因此就需要从入口流量开始，每一层技术组件都能够识别、纠错流量，减少不合理的跨机房、跨地域调用带来的访问延迟。数据读写一致性从一致性角度，所有业务数据都要在可接受（客户有体感前）时间内保持数据正确性，即：短暂数据延迟及没有数据错乱。因此就需要数据层具备单集群和跨集群同步的能力。对于跨集群异步同步的场景，极端场景下可能存在数据不一致的问题，上层数据层组件要提供面向业务的容错方案。多活运维一致性从容灾平台角度，所有容灾操作都要有标准化操作流程和预期效果。容灾平台需要有通用的服务接口、数据模型、容灾接口，帮助业务屏蔽底层云平台异构的问题。3.2 应用多活的设计标准应用多活定位是一套支持跨地域、跨平台的通用多活架构方案。应用多活架构的标准架构，需要满足以下 4 个设计标准：业务流量多活（BFA，Business Flow Active）：应用多活的最终呈现是业务，多活容灾系统具备按照业务特征进行生产流量的精细化调配。同城多活（LRA，Local Region Active）：应用是分布式系统的最小服务集合，当主中心出现问题进入容灾态时，要具备全局或局部应用的多活切换能力。异地多活（UDA，Ultra Distance Active）：在超远距离（机房间距超过 300 公里）时，业务系统仍具备较好的访问性能。进入容灾态时，RTO、RPO 在分钟级。14混合云多活（HCA，Hybrid Cloud Active）：向上对业务屏蔽容灾细节，提供统一的多活编程范式。向下对云平台技术保持兼容，支持公有云、私有云、托管私有云、边缘计算节点等不同部署模式的多活场景。图 3-1 应用多活架构设计标准3.3 应用多活的技术方案应用多活的技术方案，我们一般分为三部分，分别为应用层、数据层和云平台。三部分组件遵循应用多活的设计标准，支撑应用构建应用多活架构能力。应用层是业务应用流量主经的链路，基本构成可分为三部分：接入网关：接入网关作为业务流量打入机房的第一跳，负责应用多活入口流量的识别和分发，具备机房路由和应用路由两个核心能力。微服务：业务流量在机房内部和跨机房的同步调用方式，一般有 Consumer、Provider、注册中心等角色，具备流量路由、流量保护、故障隔离三个核心能力。消息：业务流量在机房内部和跨机房的异步调用方式，基于消息削峰填谷，一般有 Producer、Consumer、Broker 等角色。数据层涵盖业务应用数据读写、数据存储和数据同步，其具备流量路由、数据一致性保护、数据同步三个核心能力。云平台是支撑业务应用运行的核心基石，基本构成覆盖单云、单机房、多云、混合云等形态。15图 3-2 应用多活的整体技术方案依托于应用层、数据层和云平台三部分应用多活的具体技术实现，企业可快速支撑业务实现应用多活容灾架构。第四章 应用多活的技术原理164.1 应用层技术原理4.1.1 接入网关实现原理一次流量请求，从移动端或 PC 端发起调用，到进入业务应用的整个流量链路过程中，我们期望尽早进行路由纠错，从而大大减少下游进行路由纠错和不必要的跨机房调用的次数。DNS 域名解析是最早的一个环节，但 DNS 仅支持按权重随机分流，无法满足应用多活架构流量灵活路由的需求。HTTPDNS 具备自定义路由规则的能力，但 HTTPDNS 也存在着不适用于 PC 端流量的局限性。综上所述，应用多活架构需要在机房入口处部署一套流量接入网关，来负责七层流量的灵活路由。核心能力接入网关核心能力可以概况为：机房粒度流量路由：比例分流：支持根据一定的比例规则，将流量分流到不同机房。路由纠错：支持从流量请求中提取携带的业务标识，并根据一定的路由规则，将流量路由纠错到正确的机房。应用粒度流量路由：支持根据流量属性按照一定映射规则，将流量路由到不同的后端应用。工作模式接入网关在技术架构设计时，存在单集群和多集群两种模式。单集群模式，接入网关集群对外提供一个统一接入点。流量进入网关后集群后，按照一定的路由规则将业务流量调度到相应机房内的应用。当某机房发生故障时，可以通过修改接入网关的流量规则，从而将故障机房流量切换到其他正常机房，实现故障机房流量切 0。17图 4-1 接入网关组件多活实现原理（单集群）多集群模式，每个接入网关集群对外提供一个统一接入点，使用 DNS 按权重解析访问到不同的网关集群。多个网关集群均按照相同一致的的流量规则进行路由纠错。当某机房发生故障时，通过修改所有网关集群的流量路由规则，将故障机房的流量切换到其他正常机房。若故障影响到了接入网关集群，则还需要调整 DNS 权重来将故障机房整体流量切 0。图 4-2 接入网关组件多活实现原理（多集群）4.1.2 微服务组件实现原理应用多活架构中，微服务多活组件同样需要具备流量路由纠错能力，来满足多种微服务调用场景的路由需求：可能存在流量不经过接入网关的场景（例如定时任务调度发起的流量调用）。可能存在需要使用不同业务标识进行路由纠错的场景（例如，用户 A 向用户 B 转账处理过程中的服务调用，需要分别使用 2 个用户 ID 进行路由）。18可能存在需要使用不同数据维度的路由规则进行计算和纠错的场景（例如，电商交易下单处理过程中的服务调用，需要使用用户 ID 和商品 ID 来分别进行路由）。核心能力微服务多活组件通常有 SDK、Agent、Sidecar 等不同实现形态。其核心能力可以概况为：机房粒度流量路由：条件路由：支持根据服务属性和参数等信息，按照一定条件进行规则匹配和路由，使服务调用到相应机房内的 Provider 节点。优先路由：支持 Consumer 优先调用同机房内的 Provider，从而减少跨机房调用，同时还能将故障的爆炸半径控制在一个机房内。流量保护：Provider 接收到服务请求时，根据最新的路由规则进行计算，若识别为错误流量，则拒绝处理请求，保证全局流量路由的一致性。故障隔离：当局部 Provider 出现异常时，支持将异常的 Provider 进行故障隔离，保证所有机房内的Consumer 均不会调用到异常的 Provider，实现微服务流量的故障逃逸。工作模式微服务多活组件在技术架构设计时，存在单集群和多集群两种模式。单集群模式，多个机房内的应用共享同一个注册中心集群，Provider 对所有机房的 Consumer 可见，微服务调用时按照一定的流量规则进行路由纠错，使 Consumer 调用到正确机房内的 Provider。当流量没有命中路由规则时，支持同机房优先调用，避免跨机房带来的 RT 增长。当某机房发生故障或局部 Provider出现故障时，根据一定的异常识别策略可以自动进行故障隔离。当机房内健康的 Provider 低于一定数量时，则同机房优先调用策略失效，随机调用到所有机房内的健康 Provider 节点，避免继续同机房调用流量压垮下游 Provider 应用。19图 4-3 微服务组件多活实现原理（单集群）多集群模式，应用固定访问本机房对应的一个注册中心集群。服务同步组件通过异步复制的方式，实时将所需的 Provider 服务同步到其他集群。基于跨注册中心的服务发现，微服务调用时就能按照一定的流量规则进行路由纠错，使 Consumer 调用到正确机房内的 Provider。当微服务调用没有命中路由规则时，可以同机房优先调用，避免跨机房调用带来 RT 增长。当某机房发生故障时，可以通过修改流量路由规则将故障机房微服务流量切 0，使得所有机房内的 Consumer 不再调用故障机房的 Provider。图 4-4 微服务组件多活实现原理（多集群）204.1.3 消息组件实现原理由于消息是异步消费的，从消息被生产出来再到被消费到的时间段中，流量路由规则可能发生了变化（例如进行了切流）。如果消息有堆积的话，那么这个异步消费的时间差还会更长，生产和消费两个时间点路由规则不一致的概率会更大。因此只在上游通过接入网关、微服务调用进行流量路由是不够的，还需要在消息消费时按照最新的路由规则再次进行路由纠错。核心能力消息多活组件通常有 SDK、Agent、Sidecar、Proxy 等不同实现形态。其核心能力可以概况为：流量路由：消息消费时，需要根据最新的路由规则进行消息路由，仅在正确的机房内进行消费。流量保护：Consumer 接收到消息时，根据最新的路由规则进行计算，若识别为路由错误的流量，则拒绝处理请求。故障隔离：当某机房发生故障时或局部 Consumer 出现异常时，支持对异常的 Consumer 进行故障隔离，保证异常的 Consumer 不再消费消息，实现消息流量的故障逃逸从而快速恢复业务。工作模式消息多活组件在技术架构设计时，存在单集群和多集群两种模式。单集群模式，多个机房内的应用均共享同一个消息队列集群，上游应用生产的消息，随机的被分配到下游 Consumer 应用进行异步消费。当某机房发生故障时，可以对故障机房内的 Consumer 进行故障隔离，避免故障机房内的 Consumer 继续消费消息。再配合上接入网关和微服务的流量切换能力，即可实现故障机房整体流量的切 0，实现分钟级容灾切换。图 4-5 消息组件多活实现原理（单集群）21多集群模式，应用固定访问本机房对应的一个消息队列集群，多个集群之间通过消息同步组件实现消息数据的同步。一个机房内应用生产的消息，会异步同步到其他所有机房，但消息消费时会进行路由纠错，仅允许正确的机房进行消费，其他机房则识别为错误流量不消费。当某机房发生故障时，可以通过修改路由规则，将故障机房的流量切换到其他机房，从而让其他机房内的 Consumer 能够在消费路由计算时，识别为正确流量从而进行消费。另外多个消息队列集群的消息消费速率，堆积情况是不一样的，为了避免故障机房堆积未消费的消息已经被其他机房丢弃，因此修改路由规则生效后，还需要对流量切换的目的机房进行消费位点回溯。图 4-6 消息组件多活实现原理（多集群）4.2 数据层技术原理数据层多活组件在技术架构设计时，存在单集群和多集群两种模式。同城近距离的场景，由于机房间网络延迟小可以选择数据库单集群的模式进行强一致的数据读写。而远距离场景以及混合云场景，通常需要采用数据库多集群的模式，数据按一定业务维度进行分片（分片的规则就是流量路由规则），一个业务请求经过上游层层路由纠错后，最终保证只在正确的机房强一致的读写对应分片范围内的数据。数据层多活核心需要解决的是数据一致性的问题，需要针对可能出现数据不一致的问题场景进行数据一致性保护：一个真实复杂的业务系统当中，即使有上游链路的路由纠错，仍然有可能出现流量路由不一致的情况，例如调用链路路由标丢失导致路由失效、路由规则推送部分应用节点失败等。切流时，变更的路由规则推送给接入网关集群、应用节点过程中，短时间内会存在不同机器上路由规则不一致的情况。22切流时，如果数据异步同步存在延迟，则切流目的机房内的应用可能读写到旧数据，以及写后被同步数据覆盖的问题。数据层是读写数据库前的最后一道关卡，相比采用异步或定时数据对账来事后发现数据不一致问题的方式，在数据写入前通过路由正确性校验和错误流量禁写等保护措施，能够提早杜绝数据不一致的发生，从而避免此类问题的进一步扩大和蔓延。核心能力数据层多活组件通常有 SDK、Agent、Proxy 等不同实现形态。其核心能力可以概况为：数据一致性保护：日常态禁写保护：支持写数据时需根据最新的路由规则进行计算，若是错误流量则禁止写入，避免正确路由流量和错误流量分别在多个机房读写数据，造成脏写。切流态禁写保护：路由规则变更期间禁写保护：切流时，支持在流量路由规则变更和推送到接入网关和应用节点期间，禁止所有机房内的写数据库操作，保证切流期间数据不脏写。数据同步延迟期间禁更新保护：切流时，支持在数据同步延迟期间，对切流目的机房内的应用采取禁更新策略，禁止数据更新操作的执行（可以针对受切流影响的数据范围进行控制），避免出现脏写以及写后又被同步数据覆盖的问题。数据同步：支持将数据异步复制到其他机房，以便实现数据的冗余备份，保障故障场景数据不丢失和极端场景数据少丢失，从而满足 RPO 300Km1高异地应用多活收益：容灾、创新、容量 2高混合云应用多活（异地模式）收益：容灾、创新、容量表 5-2 业务应用多活架构对照表5.2 应用多活的能力保鲜应用多活旨在给出一套帮助业务应对未来潜在灾难场景下的解决方案。但业务会持续发展，架构也会不断演进，容灾治理始终解决的是发展中问题。因此容灾治理不仅要持续建设更高阶的容灾架构技术，还需要增强“基础设施”、“业务系统”、“保障工具”、“生产制度”和“应急人员”之间的协同。唯有时刻追求能力保鲜，才能立足于日新月异的复杂环境。容灾演练的四个发展阶段容灾演练作为一种管理型技术手段，可以帮助业务度量容灾能力，暴露潜在风险短板。演练按照演练目的可以分为三个类型，即：沙盘推演、模拟演练及实际业务接管演练。业务接管演练还会配合一些生产故障演练，虽然会对线上引入一定影响，但是演练效果往往更加真实。容灾演练一般会经历下面四个阶段的演进：阶段一、可控的暴露问题（未知的已知）围绕“基础设施”和“业务系统”提前梳理出影响可用率的风险因子，确定风险因子具体影响大小、是否可自愈、是否为跌零因子，此阶段需要通过生产小规模的生产实验来探索和验证。32 阶段二、可靠的收敛问题（已知的已知）通过阶段一的验证，已经可以初步得出有效的跌零因子，同时也暴露出一些问题和风险。接下来需要继续坚持把已知的风险进行收敛，并常态保鲜演练。本阶段通常以演练成功率作为驱动指标。阶段三、可信的量化问题（已知的未知）经过阶段二，“基础设施”和“业务系统”已经初步具备确定性。这时候需要开始关注“保障工具”、“生产制度”、“应急人员”这三个动态因素对整体结果带来的影响。这一阶段可以采用类似攻防对抗、突袭的方式来驱动，逐渐建立度量体系，完成度量指标的梳理和数据化沉淀。阶段四、可能的挖掘问题（未知的未知）通过阶段三的积累，已经掌握了一定的结构化的数据，此时可以借助智能化的方案，挖掘出一些隐藏的、潜在的弱点和风险。图 5-2 应用多活能力保鲜的建设策略33容灾演练的平台建设一个标准的容灾演练平台需要具备演练预检、故障注入、容灾恢复和演练复盘四项基本能力。演练预检：可以提前发现容灾的风险、确定影响面，提升容灾演练的成功率。故障注入：传统的业务接管演练，只是让容灾机房交替运行一段时间。增加故障注入环境后，比模拟演练，可以看到更真实的业务效果。多活恢复：在容灾演练中，预期业务可以通过容灾平台进行一键式流量恢复，为业务结果兜底。演练复盘：容灾演练的结果数字化，指导后续问题改进和架构优化。图 5-3 容灾演练的功能架构第六章 应用多活的实践案例6.1 同城应用多活行业案例背景和挑战菜鸟乡村作为服务农村的新型物流业务，近一年来业务规模成十倍增长。而业务系统仅在云上单可用区部署，存在缺少容灾能力的风险。因此业务决心进行同城容灾能力建设。解决方案菜鸟乡村与阿里云一起针对所面临问题以及未来业务规划进行了深度沟通与研讨。结合业务容灾的诉求以及业务技术栈，阿里云制定出了同城应用多活架构的解决方案，方案要点如下：可用区级应用双活：从 1 个可用区拓展到 2 个可用区，2 个可用区部署对等容量的应用。基于多活接入网关产品承接所有业务流量，并按照比例或精准路由规则将流量调度到不同可用区的后端应用，多个可用区部署的应用同时对外提供服务，实现应用多活。微服务同可用区优先调用：基于多活产品 Agent 能力，支持开启 Dubbo/SpringCloud 同可用区优先调用功能，从而避免跨可用区调用带来的 RT 增长。而当机房内健康的 Provider 数量低于配置的阈值时，则优先调用策略自动失效，避免同可用区 Provider 过少支撑不住上游的流量压力。快速容灾切换：当某一可用区发生故障时，基于多活产品的一键切流能力，首先通过多活接入网关将HTTP 流 量 切 换 到 另 一 可 用 区，同 时 基 于 多 活 产 品 Agent 能 力 将 故 障 可 用 区 内 的RPC(Dubbo/SpringCloud)、MQ（RocketMQ）、定时任务（SchedulerX/XXL-Job）客户端进行故障隔离，实现全局流量的快速容灾切换。34图 6-1 菜鸟乡村同城应用多活架构示意图应用收益借助于阿里云的同城应用多活解决方案，帮助菜鸟乡村实现了在较短的时间内业务同城容灾的目标，实现业务 7*24 小时不间断服务，即使单机房故障也能够分钟级恢复，最大程度保障业务的连续性。6.2 异地应用多活行业案例背景和挑战联通新客服是联通深化混改的重点建设项目，致力于打造智能化、平台化、个性化、集约化的全国智能云客服系统。新客服以集中系统为支撑，通过资源集中调度和区域集中化运营，提升服务效能、降低服务成本、保障服务质量。当前新客服已完成全国集约，服务数近万，容器数达万级。全国集约后，稳定性显得尤为重要，需要加强容灾建设以避免全国性故障风险。35解决方案联通新客服使用阿里云 MSHA 多活解决方案，建设异地两中心业务同时在线的分区域应用双活。阿里云多活产品基于灵活流量调度、跨域跨云管控、数据一致性保护等能力，保障业务在故障场景下可以快速恢复。联通新客服中的方案要点如下：跨 Region 应用多活：应用在相隔较远的 2 个数据中心冗余对等部署，两个数据中心同时对外提供服务，资源不浪费。灵活流量调度：基于省份的流量调度，可以随时切换某省份流量到某个数据中心。数据一致性保护：基于阿里“单元化”架构的多活方案，2 个数据中心的数据库同时承担写流量而不脏写。图 6-2 联通新客服的多活架构解决方案应用收益中国联通总部智慧客服联合阿里云，打造了智能化、集约化的云化双活客服系统，实现联通客服从接入、外呼到智能 IVR、知识中心等 7 大业务域的双活容灾。支持话务/业务的单独切换，以及各业务中心的单36独切换。历次大规模双活容灾演练和真实故障，业务系统秒级切换，为联通智慧客服提供了有力的容量及容灾保障。6.3 混合云应用多活行业案例背景和挑战汇通达是国内领先的面向零售行业企业客户的交易和服务平台，核心业务部署在自建 IDC 中。近年来业务的飞速发展暴露出自建 IDC 机器资源不足和跨机房容灾能力缺失的问题。解决方案汇通达与阿里云一起针对所面临问题以及未来业务规划进行了深度研讨。结合汇通达业务上云和业务容灾诉求，阿里云制定出了混合云应用双活解决方案，核心内容包括：云上云下应用双活：选择离 IDC 较近的阿里云上海 Region，应用在云上云下容量对等部署，同时对外提供服务。云上云下应用均读写 IDC 内的数据库，数据强一致。云上云下灵活流量调度：基于阿里云多活接入网关进行灵活的流量调度，支持比例分流、按业务流量属性路由以及根据访问来源 IP 段灰度路由，将流量按需、灵活的调度到云上或云下。云上云下服务互通与同机房优先调用：业务是分批上云的，过程中存在应用仅 IDC 内部署的情况。基于阿里云多活产品注册中心服务同步功能，实现云上云下服务互通，助力业务上云。同时支持开启Dubbo/SpringCloud 同机房优先调用，从而减少跨机房调用带来的网络延迟。37图 6-3 汇通达的混合云双活解决方案应用收益基于阿里云的混合云应用双活容灾解决方案，汇通达核心产品线在业务应用不改造的前提下实现了快速上云以及云上云下容灾的诉求。上云后云的弹性解决了自建 IDC 机器资源不足容量受限的问题，同时应用双活架构使得业务具备了故障场景 RPO 和 RTO 均小于 1 分钟的容灾能力，为汇通达业务提供了有力的容灾保障。38第七章 应用多活的未来展望7.1 混合云多活将成为客户上云的关键决策点无容灾不上云，应用系统要随时具备对灾难故障的逃逸能力。平稳迁移上云是每位决策者的关键决策点。应用多活架构要帮助客户业务适配云基础架构带来的差异性，提供一朵云、混合云场景一致的开发和运维体验。近年来，应用多活服务逐渐成为云厂商的标准化服务。7.2 应用多活成为云原生容灾领域的新标准应用多活解决的是全局可用性的问题，任意技术组件的不合理设计都可能导致全局多活的不确定性。应用多活需要形成跨越云厂商、开源、客户自研的通用技术标准。7.3 分布式云场景的应用多活到 2025 年，有超过 50%企业会使用分布式云。公共云服务能力将延伸到边缘计算和 IDC，一朵分布式云实现全场景覆盖。跨云、跨平台、跨地理位置的应用多活场景和技术将开始浮现。7.4 AIOps 加持的应用多活结合了大数据和机器学习功能的应用多活技术，更加主动的发现潜在的业务流量下跌，在切流前进行影响面判断和辅助决策，最终实现自动化、智能化的故障快恢。7.5 多云多芯的应用多活半导体和集成电路产业在大规模发展，未来国产芯片的应用场景会进一步拓展，企业系统运行在国产芯片上，基于应用多活能力构建多云多芯的高可用架构，进一步提升国产芯片下的业务稳定性。39附录：名词术语RPO：Recovery Point Objective，数据恢复点目标。以时间为单位，即在灾难发生后，系统数据必须恢复的时间点要求。RTO：Recovery Time Objective，恢复时间目标。以时间为单位，即在灾难发生后，信息系统或业务功能从停止到必须恢复的时间点要求。IaaS：即 Infrastructure-as-a-Service，基础设施即服务，是云服务的最底层，主要提供一些基础资源。PaaS：即 Platform-as-a-Service，平台即服务，提供软件部署平台，抽象掉了硬件和操作系统细节，可以无缝地扩展。SaaS：即 Software-as-a-Service，软件即服务，提供的是具体的服务，多租户公用系统资源，资源利用率更高。Region：Region 指不同的物理区域。AZone：AZone 是指在同一地域内，电力和网络互相独立的物理区域。云计算：云计算是一种按使用量付费的模式，这种模式提供可用的、便捷的、按需的网络访问，进入可配置的计算资源共享池(资源包括网络，服务器，存储，应用软件，服务)，这些资源能够被快速提供，只需投入很少的管理工作，或与服务供应商进行很少的交互。公有云：即在共享基础设施上提供可扩展性、弹性以及所用即所付的付费模式，客户以租户的身份共享云产品服务。专有云：即面向某一组织内部用户的云形态，只有属于该组织的成员才有云服务的使用权限。混合云：混合云是一种将公有云和专有云加以结合的云计算环境，可以在他们之间共享数据和云计算服务。MSHA：多活容灾 MSHA（Multi-Site High Availability）是在阿里巴巴电商业务环境演进出来的多活容灾商业化产品，为客户提供容灾架构建设，提升业务的连续性。横向支持容灾架构的上线、运维、演练、切流，升级到下线。纵向支持业务流量的全链路管理，从流量接入到服务化调用再到异步化消息，最终完成数据落库。单元化：“单元化”是阿里对异地应用多活的一种架构实践，通过数据分片和流量路由的方式，使核心业务可以在逻辑数据中心内完成闭环，并且逻辑数据中心可以水平横向复制。40