云厂商故障 = 业务停摆？uniCloud跨云灾备方案来了！

# 云厂商故障 = 业务停摆？uniCloud跨云灾备方案来了！

当某云厂商突发故障，你是否陷入 “服务停摆、数据失联” 的绝境？
当遭遇DDoS攻击时，是否只能在割肉买高防和用户投诉之间艰难取舍？

开发者的烦恼，都是DCloud的努力方向。

在uniCloud推出扩展数据库后，经过自用系统验证成功，现在给出了一套极具性价比的跨云灾备方案：它破除了对单一云厂商的依赖，将数据安全与业务连续性从高昂的“架构特权”，转化为易于部署的“平台能力”。

如需获取跨云容灾的详细技术支持，请点击进入 uniCloud 跨云灾备交流群

# 什么是跨云灾备？

跨云灾备，之前是大型政企招标采购中高昂、复杂的代名词，直观解释：业务方同时接入多家不同云厂商，搭建 “主备空间架构” 的灾备方案：日常用主空间跑业务，一旦主云厂商故障不可访问时，能快速切换到备空间，确保业务不中断、数据不丢失。

uniCloud让这件事变得简单、低成本。

在uniCloud中，同时开通多个不同云厂商的服务空间、开通扩展数据库、开通扩展存储。这些都很便宜。

将存储和计算分离，数据库存在统一的扩展数据库中，不使用服务空间自带的数据库，不依赖不同的serverless计算供应商。

风险最高的是计算服务，即 faas层。因为对外暴露了访问方式，云函数非常容易遭受攻击。过去uniCloud的云厂商们也出现过数次被攻击造成的服务暂停。

我们把这一高危计算层分散给不同的云厂商，支付宝云、阿里云、腾讯云。选一个作为主计算层，其他为备份。

不管哪个计算层，他们都是serverless的，他们只负责计算，数据库访问都链接到独立的扩展数据库中。扩展数据库不对外暴露地址，不会遭受攻击。

这样不管哪个云厂商的服务空间出现故障或遭受攻击，都可以动态切换计算层，改用其他云厂商的服务空间来运行云函数。

数据库自身具备高可用。而云函数的变更同步，只需要在修改云函数代码后上传到多个服务空间即可。

当一个云厂商的服务空间被攻击后，我们可以立即切换到其他云厂商，然后停用被攻击的这个服务空间，避免投入大量成本抵御攻击。（DDoS成本本身是由uniCloud云厂商承担的，不需要开发者付费，这里指的是成本更高的上层攻击）

uniCloud本身就便宜，再加上备用服务空间支持按量计费，不用不花钱。这套方案比传统的跨云灾备的成本低的多的多。

# 详解uni 扩展数据库和扩展存储

跨云灾备的核心挑战在于如何保证主备服务空间能够访问并操作同一份数据和同一份文件存储资源。如果数据和文件存储分散在不同的云厂商，切换时必须进行复杂、耗时且容易出错的跨云同步。

跨云壁垒：单云内置资源的局限性

主流云厂商的内置数据库和内置存储普遍存在厂商绑定壁垒：

内置数据库：仅限同厂商、同一服务空间的连接，形成数据隔离，无法被异构云厂商的空间共享访问。
内置文件存储：虽然部分云厂商的内置存储支持跨云访问（只读），但无法支持跨云写入和删除等关键操作。

这种限制导致跨云容灾无法实现数据层的天然一致性，极大地增加了数据同步的复杂性和数据丢失的风险。

uni 扩展服务：解耦计算层与资源层

uniCloud 通过uni 扩展数据库和uni 扩展存储，彻底将计算资源（云函数）与数据资源（数据库/存储）解耦，为跨云灾备奠定了坚实的资源基础。

数据统一：uni 扩展数据库

独立部署与共享：uni 扩展数据库是独立于单云厂商的原生 MongoDB 实例。它支持将不同云厂商的服务空间关联至同一个数据库实例，实现了“一份数据、多云计算资源共享访问”的架构。
数据一致性保障：主备空间读写同一数据源，消除了跨云数据同步的必要性，天然保障了切换时的数据一致性（RPO 趋近于零）。
高可用保障：厂商内置数据库普遍存在集合数量限制、索引数量限制、慢查询导致限流、查询超时等系统瓶颈，这些问题在uni 扩展数据库中全都不存在。
良好的兼容性：有些云厂商的内置数据库不是标准MongoDB，有一定兼容性，这些问题在扩展数据库中也不存在。
可使用专业数据库管理工具管理：服务空间内置数据库，不对开发者暴露地址，导致无法使用专业数据库管理工具来管理，web界面功能和便利性有限。扩展数据库对每个开发者暴露了独有地址，开发者保护好数据库地址，可以通过专业数据库管理工具来管理，更方便运维和备份。

DCloud 官方的uni-im 使用的就是uni 扩展数据库，扩展数据库更多介绍可参考：扩展数据库介绍

存储统一：uni 扩展存储

跨云读写能力：配合扩展存储，主备空间可以跨云访问同一个存储实例，并获得完整的读写/删除权限。这样可以避免某个云厂商挂掉后，服务空间内置的存储和cdn也无法访问。
文件高可用：存储在独立的高可用存储服务上，避免了文件层面的单点故障，且自身具备 CDN 加速能力。
性价比更高：uni 扩展存储相比内置存储，价格更便宜，功能更强大，特别是权限控制更灵活。

更多介绍可参考：扩展存储介绍

跨云容灾的关键价值：业务连续性保障

通过使用 uni 扩展服务，跨云灾备的“数据层”和“存储层”获得了以下关键优势：

零数据同步开销：避免了复杂的定时同步和增量同步机制，确保主备空间始终使用同一份文件存储和数据资源。
企业级高可用资源：扩展数据库采用 MongoDB 三副本集群架构，具备故障自动切换能力。
无数据断层切换：业务在主备空间切换后，客户端访问的是完全一致的数据库和文件存储资源，确保用户体验无“数据缺失”或“资源加载失败”等断层现象。

# 跨云灾备怎么实现客户端 “无感切换”？

为了确保业务在云厂商故障时能迅速恢复，我们必须实现客户端在不发新版的情况下，快速切换。实现这一目标的关键在于将服务路由决策与应用代码彻底解耦。

设计核心：高可用动态路由机制

uniCloud 方案通过引入一个独立的高可用配置层来解决：

路由信息外置：将当前健康服务空间（主/备）的配置信息抽象化，并存储在一个独立于业务代码的远程配置中心。
配置中心选型：选择 uni 扩展存储（uni-cdn）作为配置中心。它天然具备 CDN 加速能力，保证了配置文件的高可用、实时更新和多端兼容，成为实现快速切换的理想载体。并且它不存在被攻击打挂掉的可能。
App 启动决策：客户端（App/小程序）在启动时，自动拉取这个最新的 JSON 配置文件。根据文件内指示的当前健康可用服务空间信息，动态地完成 uniCloud 全局对象的初始化。

技术价值：架构的灵活性与韧性

这种设计使得服务空间切换成为一个纯粹的配置变更动作：

数据平面与控制平面分离：业务逻辑（云函数代码）和数据、存储保持不变，而路由控制权被提到了一个高可用的外部层。
极速响应：一旦主空间故障，运维人员只需更新 CDN 上的 JSON 配置（控制平面），业务终端用户在下次启动时即可自动连接到备用服务空间，最大限度地减少业务中断时间。

这种将配置抽象化和高可用的设计，确保了在极端情况下，您的应用可以不依赖厂商，不依赖发版，快速地完成服务切换，极大地增强了应用的韧性。

# 跨云灾备实现方案：三步部署策略

本方案将云函数代码与服务路由配置解耦，开发者只需遵循以下三步部署策略，即可快速落地跨云灾备换架构：

步骤 1：部署统一资源层与主备服务空间

此步骤的核心是搭建跨云共享的数据与存储资源层。

服务空间配置：选用 2 个不同云厂商的服务空间，作为灾备架构的主空间（Active）和备空间（Standby）。
数据层统一：确保这两个服务空间都关联到同一台 uni 扩展数据库实例，保障数据的一致性。
存储层统一：在主空间开通 uni 扩展存储，并通过配置，让备空间也指定访问此扩展存储，实现文件存储资源的跨云共享读写。
成本优化建议：推荐将主空间设置为常用计费模式（如包年/套餐），备空间设置为按量计费模式，以实现低成本的冗余配置（不使用不产生费用）。

步骤 2：部署高可用动态路由配置文件

此步骤将服务路由控制权外置到高可用的 CDN 边缘。

文件创建与存储：创建名为 cloud.json的路由配置文件，并将其上传至步骤 1 中统一配置的 uni 扩展存储。

配置结构：文件内包含主备服务空间的详细连接信息，以及一个关键的 use字段用于指示当前应被使用的健康空间

{
    "use": "main",
    "main": {},
    "backup": {
        "provider": "aliyun",
        "spaceId": "mp-xxxxxxx",
        "clientSecret": "xxxxxxi04209bObxjqQ=="
    }
}

示例源码如下，请查看 pre > code 标签中的内容

{
    "use": "main",
    "main": {},
    "backup": {
        "provider": "aliyun",
        "spaceId": "mp-xxxxxxx",
        "clientSecret": "xxxxxxi04209bObxjqQ=="
    }
}

use：路由指针，指示客户端应连接的主/备空间。

main：保持空对象，表示使用应用默认绑定的服务空间。

backup：包含备用空间所需的 uniCloud.init参数，用于动态初始化。

获取 CDN 地址：获取该配置文件的 CDN 访问地址（例如：https://cdn.domain.com/cloud.json），作为客户端动态路由的入口。

步骤 3：客户端动态初始化与切换逻辑

此步骤通过应用启动的生命周期，将路由配置注入到 uniCloud 运行时。

配置加载时机：在 App 的 onLaunch生命周期中，请求步骤 2 中生成的 cloud.json文件。
切换逻辑判断：客户端比对当前配置与远程配置，如果发现 use字段发生变化（即服务空间已切换），则更新本地缓存配置。
动态初始化：使用远程 JSON 中的配置数据 (initData)，通过以下代码实现 uniCloud 全局对象的运行时重新初始化：

// 在获取到最新的 initData 后执行
Object.assign(uniCloud, uniCloud.init(initData));
// 提示或通过 uni.reLaunch() 平滑重启当前页面，确保所有服务调用指向新的健康空间

示例源码如下，请查看 pre > code 标签中的内容

// 在获取到最新的 initData 后执行
Object.assign(uniCloud, uniCloud.init(initData));
// 提示或通过 uni.reLaunch() 平滑重启当前页面，确保所有服务调用指向新的健康空间

架构效果：客户端在故障发生时，无需重新发版，只需在下次启动时动态切换到 cloud.json中指向的健康服务空间，实现业务的快速恢复。

架构对比:uniCloud 扩展服务容灾vs传统自建服务器容灾

传统的云服务器容灾方案（基于 ECS、负载均衡、RDS 等）需要进行复杂的底层架构设计和资源依赖管理。相比之下，uniCloud 基于 Serverless 的跨云灾备方案，在成本、运维和安全三大维度上展现出结构性优势。

我们从关键指标进行对比分析：

成本维度：从高昂的固定开支到精细化的按需订阅

关键要素	传统服务器容灾方案	uniCloud 跨云灾备方案	结构性优势
基础资源	需购买多台 ECS (主备)，负载均衡 (SLB)，高可用 RDS 实例，费用数万元/年。	仅需支付主/备空间的消耗费用，以及一份 uni 扩展数据库/存储的订阅费用。	资源按需订阅，极大降低了初始投入和闲置成本，实现从固定成本到可变成本的转变。
抗 DDoS	需额外付费购买高防 IP，例如：最基础的阿里云高防服务每月费用可达2万元。	uniCloud 基于云厂商的函数计算服务构建，天生具备云厂商提供的内置、免费的 DDoS 防御能力。	彻底消除昂贵的安全支出，将安全能力转化为平台内置福利。

运维便捷性：从专家运维到平台托管

关键要素	传统服务器容灾方案	uniCloud 跨云灾备方案	结构性优势
架构管理	运维门槛高，需专业人员负责底层网络、中间件、操作系统、负载均衡和数据库集群的手动搭建与维护。	Serverless 架构，底层资源完全免运维。开发者仅需关注云函数代码和配置管理。	大幅降低人力成本和运维复杂性，开发者可聚焦于业务创新。
故障排查	依赖复杂的多组件日志，排查定位困难。	uniCloud 平台提供统一的云函数日志和扩展数据库的可视化监控与慢日志分析。	简化排障流程，缩短 MTTR（平均恢复时间）。