故障总是会出现，业务系统面对故障时的容错能力则体现了系统架构师的设计能力。但是，在现实的世界中，系统的容灾建设总是优先级很低的任务，可能长期躺在”to-do“当中。

在过去的几个月中，国内两大云厂商均出现了可用区级别的故障（链接、链接）、B站在3月5日发生过一次大规模不可用（参考 参考）、OpenAI在3月也发生过一次宕机（参考），技术团队如此强大的公司依旧会出现此类大故障，那么几乎是一定的：我们的系统也会出现类似的故障，你的也会。而这类故障，不是第一次，也不会是最后一次。

本文就从数据库角度，看看构建有效的跨区域容灾有哪些难度和挑战。

挑战1：业务系统总是优先于容灾系统

在公司的各级团队中，业务系统总是优先于容灾系统，这是常态。这并不是技术人员不知道其重要性，而是在当前互联网企业普遍追求KPI/OKR考核的环境下，都需要将资源投入到可短/中期见效业务系统建设中，而对于长期非常重要的容灾建设，其优先级都会比较低。目前，大部分公司的考虑机制都是，按年进行，每到年底都会进行绩效（KPI/OKR）考核，并依此决定一年最重要的年终收入分配（涨薪/年终奖/股票/期权等），业务目标和容灾建设孰轻孰重，大家都会用脚投票。所以，对于容灾建设，通常容易停留在保障在当前自己的任期内不出大问题就可以了，很难会有人考虑系统化的建设企业的容灾系统。

挑战2：容灾系统建设架构难度大、成本高

一个有效的容灾体系建设，几乎需要公司大部分的技术团队介入，如果没有非常强权利或者影响力的团队则通常难以推进。一方面，有效的容灾需要企业的应用、中间件、数据库、IDC等团队协作完成，另一方面，不同的组件容灾其技术架构和方案均不同，整体上，需要非常强的技术把控能力。

成本也是另一个经常会限制容灾建设的另一个潜在原因。在整体降本增效的大背景下，即便做好了技术、人员的准备，成本也可能成为另一个重要的限制，这个成本包括直接成本，例如硬件设备、机房建设、人员等，还有部分间接成本，即由此给业务迭代增加一定的复杂度。

挑战3：容灾系统有效性验证难，且需要持续维护投入

企业的业务和技术总是在不断演进的，如果在架构设计时没有考虑架构发展的连续性，那么后续架构迭代也会对现有的容灾系统带来非常大的影响，甚至很可能会导致现有的容灾系统失效。所以，容灾方案需要定期进行审查和更新，以确保其能够应对这些变化。然而，部分企业可能没有实施持续改进和更新的机制，导致容灾方案逐渐过时。

根据经验来看，容灾系统的验证也通常很困难。真实的业务环境是千变万化的，现在的互联网系统几乎是按照”周“为迭代周期在持续不断的发展，要进行有效的容灾系统验证，则可能需要考虑很多的维度，包括底层硬件失败、机房网络失败、操作系统失败、流量分配系统失败等，此类演练通常需要付出非常高的成本，并且，在演练验证过程中，如果由于环境变化导致原有的容灾系统失效，则很可能会引发真实的系统故障。

有效性的验证，在实际的经验中，是企业中的”脏活与累活“。因为依旧存在演练失败的风险，所以此类演练一般是放在业务低峰的凌晨进行，涉及的基层技术人员、团队也比较多，强度是比较大的；另外，此类事情，结果如果符合预期，即容灾成功，则通常会被认为是理所应该的，而失败了则会进行一定范围的追责与复盘，再进行修复，虽说是一个良性过程，但是”追责“依旧是大家尽量避免的，所以，此类工作的配合度、执行度意愿都比较低。

应对1：异地多活是一次了不起的探索与实践

阿里在多年前的异地多活实践，可以说是一次非常了不起的探索和实践。是容灾领域一个非常正面的案例：

• 将容灾这个原本重要，但不被重视的事情，提到了公司核心技术架构的战略上来
• 将容灾这个单纯的成本花费，和提升业务可用性联系起来
• 将容灾这个日常难以验证的基础设施，进行了常态化的处理

当然，异地多活的难度也是非常大的，而且比较遗憾的是，目前即便是阿里（云）也没有提供比较产品化的能力帮助企业实现异地多活，其中的难点非常多，这里不再赘述。

不过，目前也看到不少公司在进行探索，希望在业界能够逐渐形成可复制可参考的经验或者产品。

应对2：建立负责容灾建设的架构师团队

鉴于容灾系统对于中大型企业的重要性，以及各种客观因素导致其建设困难，在业界另一个常见的方案是，通过构建专门的架构师团队，专职负责容灾建设。当然团队通常还负责类似的安全建设、架构统一等职责。

通过独立的团队，可以培养具备容灾架构知识的专业的人员，也可以在公司建立起统一的容灾架构方案，还可以形成周期性的容灾演练机制。同时，可以避免各个独立团队各自为阵，建立起一个看似可以容灾的独立组件，但真正在系统性故障发生，难以耦合来应对故障。

应对3：数据库在跨地区容灾方向的建设案例

• DynamoDB、Aurora、PolarDB的Global Database：Auroa使用了三中心(AZ)六副本的架构，也实现了单可用区失败的可用性保障，以及AZ+1的数据可靠性保障，但是并不提供跨区域的容灾。在2019年，Aurora推出了Global Database实现数据库层面的跨区域容灾。PolarDB在2020年也推出了类似的全球数据库功能，阿里云RDS则可以通过异地的容灾实例实现类似的能力。
• OceanBase的多地多中心能力是数据库领域的容灾方案的典型。OceanBase在多地多中心上的能力是非常突出的，一方面，在数据库写入时，OB会通过一致性协议向多个中心写入，另外，OB在上层提供了单个中心失败时，较为自动的切换能力，大大简化了系统在建设跨区域容灾的复杂度。可以说，比较好的解决了数据库跨地区的容灾能力。

应对4：基于同步产品的数据库容灾构建

使用数据库同步产品构建容灾，则是另一种非常常见的方案。这种方式的优势在于：

• 对于原来的架构改造、影响非常小
• 可以较为自由的实现跨云、跨区域的容灾，例如从AWS RDS MySQL同步到腾讯云的RDS
• 可以实现跨数据库类型的容灾，例如源可以是AWS新加坡的Aurora数据库，目标则是阿里云、华为云的RDS MySQL实例

实现此类功能的数据库同步产品有NineData数据复制、Oracle Goldengate、Qlik Replicate、DSG、Canal等，可以帮助企业实现数据库之间的容灾。

最后

昨天看到腾讯对于329故障处罚结果，包括公司副总裁、事业部总裁、负责具体业务的总经理都受到了不同程度处罚，所涉及的人员级别之高可以看到腾讯对此次故障的重视程度。

而在去年12月18日上午，阿里云香港也曾出现大量基础服务不可用（参考），持续时间超数小时，而随后在当月月底，阿里云则发生了4年以来最大规模的组织架构调整，并强调“对云计算而言，稳定和安全是对客户最基本的责任，我们要始终秉持敬畏之心，不辜负客户的信任和依托。”（参考）。

无论在哪个公司，哪个环境，都需要在架构上考虑系统的容灾方案，因为故障总会发生，我的也会，你的也会，这个故障这不是第一次，也不是最后一次。