2025 年底，科技行业的注意力和主流叙事，仍然在向 AGI 靠拢。好消息是，前沿技术的理解成本在降低，新的技术价值在涌现；坏消息是，想重启对云端业务保障话题的讨论，客观上变得困难了。

但不管行业关注点怎么变，业务能不能稳定运行，始终是企业最关心的问题之一。尤其是行业当下所处的发展阶段，保障业务“高可用”变得越来越重要。

首先，快速变化的技术栈和基础设施，使上云几乎成为商业公司规模化扩展业务的最优解。云端承载的业务量级正在急剧扩张，相应的业务保障难度也在上升。

此外，全球化已经从“可选题”变成“必答题”，传统企业服务厂商与头部客户携手出海的案例比比皆是，而新兴公司几乎从诞生第一天起，就是云化的、全球化的。

综合影响下，很多公司 2025 的增长方式已经演变为“多业务线 + 多区域 + 多渠道 + 多合作方”。随着系统复杂度的剧增，对高可用保障的需求变得越发急迫。

而对高可用的回应，既不能粗暴设置为“异地多活”，也不能简单概括为“冗余多备份”。高可用真正的难点，不在于“把系统再部署一份”，而在于“多地同时对外服务时，怎么保证一致性、怎么切流量、怎么控制故障半径、怎么回切”。

《腾讯专有云 TCE 高可用技术白皮书》是对以上问题的系统回应，直接给出了详细的架构方案和设计思路。

[点击此处直接下载/查阅《腾讯专有云 TCE 高可用技术白皮书》全文]

“四个九”：从统计口径到工程路径

曾有观点认为，高可用的讨论意义不大，技术提供方只要承诺是“4 个 9”还是“6 个 9”就够了，概率外的属于“黑天鹅事件”，主要看“命”。

实际上，当请求量、依赖数、变更频率增加以后，如果没有做好高可用，所谓的小概率事件有可能按周出现。无论几个九，都只是统计口径，但高可用要交付的是工程路径，结果由边界、口径、依赖、故障域、演练能力共同决定。

这是为什么在报告的开始，首先要统一工程语言和建设目标。

在语言方面，最需关注的关键术语有三个：可用性、RTO、RPO，它们共同定义了 SLA（Service Level Agreement，服务级别协议）。

可用性：一般以百分比的形式呈现。以电信运营商（ISP）提供的企业专线服务为例，如 ISP 向客户承诺，可用性指标为 99.99%（一般称为 4 个 9），每年计划外停止服务的时间在全年服务时间中的占比，就不应当高于 0.01%，也就是 365（天）×24（小时）×0.01%=0.876（小 时），合 52.56 分钟。

RTO（业务恢复时间）：指的是从灾难状态恢复到可运行状态所需的时间，用来衡量系统的业务恢复能力，也就是所谓的业务连续性。

RPO（数据恢复目标）：指的是在灾难过程中的数据丢失量，用来衡量系统的数据冗余备份能力，也就是所谓的数据可靠性。

早期机房容灾常被简化为“有备份、有双机”。但在真实事故里，业务恢复太慢（RTO 过高）、数据丢失太多（RPO 过高） 的问题经常出现，于是监管、审计、企业风险控制把“高可用”从体验问题转换成了指标问题，RTO、RPO 也随之成为讨论高可用的统一语言。

那么如果将 RTO 作为 X 轴，RPO 作为 Y 轴，就得到了用于规划建设目标的象限图，如下所示：

解决高可用问题，本质上是在解决分布式问题，一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance） ，或许还要加上经济性，几乎不可能被兼顾，必须把业务可接受的损失，映射到技术路线，以方便 IT 负责人作取舍。

越想要 RPO=0（不丢数据），越要依赖同步复制与一致性机制，成本与写性能压力就会上升；反过来，越想要 RTO≈0（业务几乎不中断），越要依赖多活，自动化切换与流量治理，导致架构复杂度上升，治理难度上升。

更理智的做法是把能力分层： 关键数据链路尽量做到 RPO=0，关键业务链路逐步压低 RTO，非关键部分用多活换扩展性。

关于高可用设计的深度探讨与体系化建议，白皮书内有更为详尽的论述，欢迎参阅白皮书全文，获取完整的工程参考指南。

行业领先的“八横四纵”高可用体系的构建

明确了建设目标，应该如何在架构层面进行设计？腾讯专有云 TCE 在白皮书中给出了具体的参考，叫做“八横四纵”高可用保障框架。

“四纵”架构明确了高可用能力的容灾深度，即云平台在不同物理规模故障下的生存能力。其核心逻辑是实现故障域的逐级隔离。分别为：

1.  硬件组件级高可用：任一硬件组件，如单块磁盘、单条网络线缆或单个电源模块等组件故障，均不影响业务的正常运行，也不会引起数据丢失；

2.  节点级高可用：任一硬件组件，如单块磁盘、单条网络线缆或单个电源模块等组件故障，均不影响业务的正常运行，也不会引起数据丢失;

3.  机柜级高可用：任一机柜发生整体故障，如 PDU 断电或其他物理设施故障造成机柜内部分或所有设备均掉线时，不影响业务的正常运行，也不会引起数据丢失；

4.  AZ（可用区）级高可用：任一 AZ 整体故障，如整个机房的电力供应或网络连接中断等情况，使得整个 AZ 无法提供服务时，不影响业务的正常运行，也不会引起重要的数据丢失。

“四纵”的划分本质在于解答故障域问题，也是对高可用问题比较坦诚的回应。行业中，经常有厂商承诺“4 个 9”，但没说清是应对单机故障，还是应对 AZ 级故障。不先定四纵层级，SLA 承诺就没有可参考性。

有了“四纵”，IT 人员首先可以根据业务需求，反推高可用的实际保障范围，另外也避免了过度设计，反而因为成本和复杂度问题导致难以为继。

如果说“四纵”回答的是“扛多大的灾”，那么“八横”回应的就是“靠哪些能力抗灾”。因此，报告中的“八横”，是从基础设施高可用，一直延伸到终极目标：应用高可用。

“八横”把高可用拆成一组必须协同的层级能力，每个业务都必须回答， 要达成对应的纵向等级，在这一“横”需要实施哪些动作，怎样完成验收。

很多平台事故的关键症结是：业务还有希望，但控制台/API 不可用、调度/迁移/扩容不可用、权限/配置下发不可用，最终导致 RTO 过高。

所以在事故里，最脆弱的往往不是运维最关注的那一层。

“八横”将最容易被忽略的“网络+管控+运维”与最被重视的“计算+存储+数据库”拉齐到了同等重要的位置。可以说，高可用“4 个 9”的真正底气，来自“八横四纵”高可用保障框架。

关于具体的部署模式，《腾讯专有云 TCE 高可用技术白皮书》中也进行了具体的阐述。

单 AZ、双 AZ（可选仲裁区）、三 AZ、多地中心部署，实际上近似一套可以直接“抄作业”的完整答案。

单 AZ 部署能够保证单 AZ 内部基础硬件点、各个云组件、机柜间、外部网络以及基础电力的高可用，这种部署模式仅适用于一些对数据安全性和业务连续性没有太高要求的用户，但因为其成本也较低，恐怕会长期存在。

“双 AZ + 仲裁”模式的优势在于，在任意一个 AZ 故障，或双 AZ 出现脑裂时，不需

要手工拉起这些支撑组件，能够实现对平台和云产品无影响。这种模式可能会成为“严肃场景的默认形态”，直到企业愿意为“三 AZ”模式付出更多建设成本。

“三 AZ”模式将支撑组件集群、云管控平台及部分云产品服务集群跨三个 AZ 部署，任意一个 AZ 故障时，ZK 和 etcd 等支撑组件集群能够保持多数派存活，保证云管控平台和各个云产品集群的服务不中断，对云上应用不产生影响。当业务足够关键、组织能力足够成熟时，三 AZ 显然是更“工程化”的答案。

而多地中心部署的思路更适用于银行等对数据安全性和业务连续性要求极高的用户，这些用户往往在同城双中心的基础上，再增加异地灾备数据中心。当极端情况出现，同城双 AZ 同时不可用时，异地部署的备 Region 就可以接管业务。

当然，部署模式的选择仍然是个复杂的问题，并不存在针对某一行业的通用解决方案。白皮书中也给出了覆盖国家级 5G 新媒体平台、头部农商银行等行业的实战案例。

历经万亿级金融业务验证的高可用技术

在金融行业，业务连续性与数据安全往往面临更复杂、更极端的考验。从白皮书披露的多个实践案例可以看到，无论是头部农商银行、国有大型保险集团，还是股份制商业银行，这些机构普遍具备交易量大、核心系统多、监管要求严格等共性特征，对“不可中断““零数据丢失“的要求极高。

在这些场景中，腾讯专有云 TCE 并未采用单一模式套用，而是结合金融业务实际，给出了包括双活 AZ+仲裁、双 Region、三 AZ 的分级容灾方案，其中服务某头部股份制商业银行的“三 AZ”案例，也是业内首个同城三 AZ 的金融云平台案例，非常有参考价值。

从结果来看，这类架构已能够在真实生产环境中支撑金融核心系统运行，在单 AZ、机房级甚至地域级故障场景下，实现业务快速接管与数据完整性保障。综合白皮书中的案例实践，腾讯专有云 TCE 当前已能够提供全场景金融级容灾能力，最高支持六级容灾等级，实现 RTO ≤ 2 min、RPO = 0 的高可用目标。

而这种能力之所以被认为处于行业前列，源于其在复杂金融场景中的持续积累与演进。一方面，它在多家金融机构的核心系统中长期运行，并通过反复演练不断完善；另一方面，也经受了微信支付、理财通等万亿级金融业务在高并发与极端场景下的实际检验。

正是在这些真实业务环境的共同锤炼下，该高可用能力逐步形成了一套成熟路径，为金融行业对高可用“可落地、可验证、可持续”的要求提供了现实参考。

更多案例细节在此不再赘述，腾讯专有云 TCE 所构建的这一套高可用架构方法，足够先进，可复制性强，为企业排除了高可用建设的诸多“噪声”。这套方案精准契合了当下企业核心业务全量上云与全球化稳健扩张的双重需求，具有极强的实战指导价值和标杆意义。

诚邀下载《腾讯专有云 TCE 高可用技术白皮书》查阅参考。若您希望就相关技术架构与腾讯专有云 TCE 团队或 InfoQ 展开进一步探讨，欢迎在评论区留言。