云平台搭建案例,云平台搭建教程视频

越来越多的企业在数字化转型和上云进程中选择混合云的形态（云 自建 IDC 或云 其他厂商云）来进行容灾建设，一方面不会过度依赖单一云厂商，另一方面还能充分利用已有的线下 IDC 资源。

MSHA 云原生多活容灾解决方案[1]，也发布了混合云多活容灾产品能力。本文会通过一个业务 Demo 案例，介绍混合云容灾建设的难点，以及如何基于 MSHA 来快速搭建应用双活架构并具备分钟级业务恢复能力。

业务背景信息

A 企业是一个零售行业电商交易平台，业务系统部署在自建 IDC 机房，存在以下痛点：

• 业务仅在 IDC 单机房部署，缺少容灾能力。
• IDC 容量不足，物理机器升级替换周期长，不足以支撑业务的快速发展。

业务在快速发展过程中，多次遇到的容量不足以及故障问题引起了公司高层的重视，决心进行容灾能力建设。由于自建 IDC 是公司已有资产且稳定使用多年，同时不希望过度依赖于云，因此期望建立 IDC 云 的混合云形态容灾架构。

当前应用部署架构

电商交易平台包含的应用：

• frontend：Web 应用，负责和用户交互。
• cartservice：购物车应用，提供购物车添加、存储和查询服务。
• productservice：商品应用，提供商品、库存服务。

技术栈：

• SpringBoot。
• RPC 框架：SpringCloud、Dubbo，注册中心使用自建的 Nacos、Zookeeper。
• 数据库 Redis 和 MySQL。

混合云容灾目标

业务容灾需求归纳如下：

• 云上云下互容灾，切换 RTO 为分钟级。期望云上云下相互容灾，继续发挥 IDC 的价值，且不 100% 依赖于云。面对 IDC 或云故障场景，关键时刻要敢切换、能切换，且切换 RTO 要求小于 10 分钟。
• 无数据一致性风险。云上云下的两个数据中心数据强一致，日常态和容灾切换过程中都要避免存在脏写等数据一致性风险。
• 一站式管控。业务容灾涉及的技术栈框架和云产品，需要统一管控、统一运维、统一切换，操作收敛在一站式管控平台，方便故障场景快速白屏化操作，自动化执行。
• 实施周期短，改造成本低。业务存在多个产品线，依赖关系复杂、调用链路长，且处于高速发展频繁迭代时期，期望容灾建设不会给业务研发团队带来改造负担。

建设难点

• 流量管理难度高
• 若采用 DNS 将流量按权重解析到云上和云下，存在修改 DNS 解析生效时间长的问题（通常为十分钟或小时级，参见 DNS 解析生效时间 FAQ[2]），不能满足容灾切换小于 10 分钟的要求。
• 业务应用所依赖的 Redis 和 MySQL，IDC内采用开源自建而云上直接使用云产品，要实现开源自建 云产品的容灾切换能力难。
• 容灾切换数据质量保障难
• 容灾切换过程中，可能因数据同步延迟导致读到旧数据，以及切换规则推送到分布式应用节点时间不一致等原因可能造成云上云下数据库同时读写而出现脏写的问题，整个切换过程数据质量保障是个关键点，同时也是难点。
• 无业务代码侵入难
• 要实现 Redis、MySQL 容灾切换能力，通常需要业务应用配合改造，对业务代码侵入大。

解决方案

结合业务容灾需求和混合云 IDC 云形态的特点，采用应用双活架构能够较好的满足业务容灾诉求。

应用双活架构

架构简图：

架构规范：

• 选择离 IDC 物理距离<=200km 的云上 Region，网络延迟较低（约 5~7ms）。
• 应用、中间件云上云下冗余对称部署，同时对外提供服务（应用双活）。
• 数据库异地主备，异步复制备份。应用读写同一数据中心的数据库，避免考虑一致性问题。

详细方案

• 应用流量双活

业务应用云上云下对称部署，并基于 MSHA 接入层集群，来承接入口 HTTP/HTTPS 流量，按照比例或精准路由规则云上云下分流。多活控制台提供 MSFE 集群界面白屏化的部署、扩缩容、监控等常规运维能力，以及应对故障场景的分钟级切流能力。

• 服务互通和同单元优先调用

业务应用需要按业务产品线分批上云，过程中存在下游应用仅 IDC 部署的情况。利用 MSHA 注册中心同步功能，可实现云上云下服务互通，助力业务上云。同时基于 MSHA-Agent 的切面能力，在 Dubbo/SpringCloud 服务调用时，Consumer 优先调用同单元内的Provider，从而避免跨机房调用带来的网络延迟，减小业务请求 RT。

• 数据同步&数据库连接切换

数据库异地主备部署，云上云下应用日常态均读写云上 Redis 和 RDS 数据库，无需考虑数据一致性问题。MSHA 控制台通过集成 DTS 同步组件，支持云上云下的数据同步（异步复制）。同时基于 MSHA-Agent 切面能力，具备应用数据库访问连接的切换能力，云上 Redis 或 RDS 故障则可将读写访问连接切换到 IDC 内的 Redis 或 MySQL，反之亦然。切换过程中还具备禁写保护能力，避免产生读到旧数据以及脏写等数据质量问题。

• 一站式管控&无业务代码侵入

MSHA 控制台，支持 HTTP、数据库访问流量的统一管控、统一切换，操作收敛在一站式管控平台，方便故障场景快速白屏化操作，自动化执行。同时针对业务应用 MSHA 提供了 Agent 接入方式，无需业务代码改造即可获得相关容灾切换能力。

改造内容

• 应用上云
• 选择跟自建 IDC 较近的阿里云地域，云上完全冗余的部署一套应用、中间件和数据库，以便搭建云上云下双活容灾架构。在这个 Demo 案例中，选择杭州 Region 作为容灾单元。
• 网络打通：
• 接入 CEN 云企业网，实现云上云下网络互通（详见多接入方式构建企业级混合云文档[3]）。
• 接入集群部署和配置：
• 云上云下部署 MSHA 接入层集群（MSFE），上挂 SLB 用于公网接入以及 MSFE 集群的负载均衡（参见使用文档[4]）。
• 录入域名、URI 和后端应用地址，从而具备云上云下分流和分钟级切流能力（参见使用文档[5]）。
• 应用：
• 云上分批部署业务应用。
• JAVA 应用安装 MSHA-Agent，并使用 Nacos 作为管控命令下发通道，从而具备微服务同单元优先调用以及数据库访问连接切换能力（参见使用文档[6]）。
• 中间件和数据库：
• 云上部署 MSE 托管 ZK/Nacos 注册中心、云数据库 Redis 和 RDS，建议使用跨可用区部署高可用版本，具备同城双活容灾能力。
• 若存在某应用仅 IDC 部署的情况，需要配置注册中心的服务同步（参见使用文档[7]）。
• 配置云数据库 Redis/RDS 和自建 Redis/MySQL 的数据同步（参见使用文档[8]）。

改造后的应用部署架构

日常场景：IDC 云上同时承担业务流量--应用双活