【观点】太保科技数智研究院云首席架构师、 AI Infra负责人王辉：基于信创云的双活建设

当前国内金融数字化转型迈入深度深化阶段，行业发展呈现两大清晰主线。其一，信创自主可控建设由试点探索转向规模化全域落地，监管持续引导金融机构完成芯片、操作系统、数据库、中间件全栈国产化替代，自主可控基础设施成为机构建设刚需；其二，金融业务线上化程度持续加深，保险、银行等机构7×24小时不间断服务成为标配，叠加监管对业务连续性要求不断收紧，传统小时级恢复能力的老旧灾备架构，已无法匹配业务运营与合规管控双重标准。保险行业业态多元，覆盖产险、寿险、养老、资管、投资等多条业务线，存量系统数量庞大、业务链路冗长，多数中型保险机构存在IT预算有限、存量系统改造难度高、国产化软硬件适配磨合周期长等共性痛点。如何在可控成本范围内，搭建一套兼顾信创自主、金融级灾备能力、贴合自身业务现状的双活架构，是整个保险科技领域亟待解决的行业难题。在此背景下，太保科技落地的信创云双活建设项目获评金科创新社年度十大标杆案例，为中等规模金融机构提供了一套可落地、可复制的完整实施路径。

近日，2026金融科技创新发展论坛暨第九届金融科技管理人年会顺利举办，太保科技数智研究院云首席架构师、 AI Infra负责人王辉围绕太保信创云双活项目全流程实践展开专题分享，完整拆解项目建设背景、顶层设计、技术落地、运营保障与实践经验，为行业信创+双活融合建设提供实操参考。

一、项目建设背景：监管与业务双重驱动，催生同城双活建设需求

1.监管政策标准持续收紧，统一金融行业灾备底线

2019年银保监合并前，保险行业业务连续性管控标准宽松，灾备恢复时长普遍以小时为计量单位。监管政策出现两次关键升级，直接抬高行业灾备建设门槛：2019年银保监29号文明确，重要业务中断满30分钟需启动突发事件上报流程；2024年金融监管总局11号文进一步统一银行、保险灾备规范，要求核心业务系统必须配套同城、异地两级灾备，大型金融机构需具备单数据中心故障下长期完整承接核心业务的能力。传统异地冷备架构仅能实现基础数据备份，恢复RTO超2小时、数据丢失RPO超过15分钟，完全无法满足新规要求，搭建同城双活架构成为合规硬性要求。

2.保险全线上业务倒逼全天候高可用能力

当下保险业务全面面向C端线上运营，官网、微信公众号、移动端APP承载投保、核保、理赔、客服、投资交易等全流程服务，全年无间断对外提供服务。单条承保理赔业务链路往往串联十余套甚至二十套系统，任一环节故障都会直接造成业务停摆，同步引发客户流失、财务损失、品牌声誉受损、合规处罚多重风险。

原有单机房集中式架构存在致命短板，无法支撑实时线上业务稳定运行。集团自2024年正式启动信创云双活项目，确立“先筑牢国产化技术底座，再分批次完成核心业务系统双活改造”的整体实施思路。

3.项目锚定四大金融级核心技术指标

项目规划阶段即对标国家一级灾备能力，明确四项不可突破的硬性指标：一是RPO数据指标，同城双活实现数据零丢失，异地灾备数据丢失无限趋近于零，依托底层数据库实时复制机制落地；二是RTO恢复指标，核心业务系统故障恢复目标控制在20分钟以内，轻量化业务最快可实现12分钟内完成全量流量接管；三是高可用等级，达成数据中心级完整双活能力，可覆盖部件、机柜、节点、数据中心四层故障场景；四是整体架构标准，落地两地三中心多AZ信创云底座，一套架构同时承载同城双活、异地灾备、集群仲裁三类核心能力。

二、顶层核心方法论：八横四纵分层体系+三大落地实施策略

项目摒弃零散单点改造模式，搭建标准化顶层框架，形成“一套分层高可用体系、三大落地实施策略”完整方法论，从源头规避资源浪费、改造返工、业务中断风险。

1.八横四纵高可用分层体系，实现业务全链路无单点短板

横向八层：覆盖业务全流程防护路径

横向分层完整覆盖从互联网接入到数据持久化的全业务链路，每一层独立配套双活高可用方案，消除链路单点故障隐患：互联网入口与核心网络层、全局负载均衡GSLB层、安全防护层、WEB接入层、APP业务处理层、分布式中间件层、数据库处理层、底层数据存储层。

纵向四级：分级递进的故障容灾能力

纵向划分四层高可用能力梯度，项目建设目标直接锁定最高等级数据中心级容灾：部件级，单硬件部件故障自动切换；机柜级，整机柜故障业务平滑迁移；节点级，服务器集群节点故障无感恢复；数据中心级，整机房故障下另一中心完整承接全量业务流量。

2.三大落地实施策略，平衡改造成本与落地风险

策略一：规划先行，分级评估锚定核心业务价值

项目前期搭建标准化业务连续性分级评估模型，从财务影响、客户体验、合规风险、品牌声誉四大评估维度，对集团近千套存量业务系统统一打分定级。集团涵盖产险、寿险、养老、资管、投资多类子业态，不同子公司业务规模、用户群体差异显著，因此差异化设置分级判定门槛。

通过分级筛选，将核保、理赔、客服、销售、集团资金管理、统一登录、消息推送、投研交易等核心业务链路纳入改造范围，最终锁定100余套关键系统作为双活建设对象，实现核心业务全覆盖，避免非核心系统盲目投入，精准管控整体IT改造成本。

策略二：渐进实施，试点先行稳步批量推广

保险核心业务链路复杂，单条业务流程依赖数十套系统，一次性全量改造业务风险极高。项目采用“由简到难、低成本试错”实施思路，优先选取依赖关系简单、业务影响范围小的系统开展试点，例如车险移动理赔、寿险银保通、集团资金平台等。

试点阶段完整验证信创云双活部署、跨中心流量切换、数据同步、应急处置全流程，沉淀标准化实施手册与运维操作流程，验证完成后再向全集团批量复制推广，最大程度降低大规模改造带来的业务中断风险。

策略三：同步搭建全维度闭环运营保障体系

双活基础设施落地不等于业务稳定高可用，项目同步配套运维、监控、常态化演练体系，形成完整运营闭环。第一，搭建全链路统一监控体系，覆盖双中心网络、存储、数据库同步延迟、应用运行状态，实现故障秒级发现与告警，完成切换后持续监测业务运行指标；第二，建立四级常态化切换演练机制，划分应用级、组件集群级、平台级、数据中心级四类演练，应用级切换随版本上线常态化执行，集群、平台级定期开展，数据中心级每年组织综合大型演练；第三，动态迭代应急预案，区分系统自动切换、人工介入处置两类故障场景，依据历次演练反馈持续优化处置流程，明确不同故障等级标准化操作规范。

三、整体解决方案架构：一个中心、四大配套支撑体系

项目整体架构遵循“一个中心、四大支撑”设计逻辑，依托国产化信创云底座承载整套双活能力，为八横四纵全链路提供平台级底层支撑。

1.核心中心：两地三中心多AZ信创双活云底座

整套云平台基于国产Para架构搭建，落地两地三中心多AZ部署模式，统一承载计算、存储、网络、数据库、中间件、安全全栈国产化软硬件资源。同城两大生产AZ对等部署，同步对外提供内外网业务服务；第三同城AZ承担集群仲裁、数据副本存储职能；异地机房作为城市级灾难备份中心。

同城三机房两两光纤链路双向传输延时控制在1.5毫秒以内，单条链路故障时流量自动绕行，绕行总延迟不超过3毫秒，底层网络架构为跨中心数据实时同步提供基础保障。

2.四大配套支撑体系

混合统一云管平台：云管平台实现多数据中心、多信创平台资源统一纳管，具备双活能力一键发放、双中心扩容自动化编排、存量单活应用批量迁移至双活架构能力；同时支撑切换演练、流量调度自动化操作，替代传统人工重复配置工作。

分布式双活应用部署体系：项目同步推进微服务、云原生架构改造，原有单体业务逐步完成容器化拆分，针对车险开门红等短期营销敏态业务配套弹性伸缩能力。双中心对等部署应用集群，任一机房故障可承载50%-70%业务流量，采用主备流量调度模式，兼顾业务稳定性与改造成本。

多层级智能流量调度体系：流量调度分为外网互联网GSLB、内网智能DNS两层架构：互联网侧依托运营商、地域完成一级调度，结合机房优先级实现二级调度，联动WAF、公网IP实现故障自动切流，配套实时后端健康检查机制；内网侧采用分布式AnycastDNS就近解析，跨机房访问动态切换，受DNS解析延迟限制，极端故障场景配套人工切换兜底方案。

业务连续性演练平台：平台集成CMDB、自动化运维、容灾编排能力，支撑全场景故障模拟演练，自动记录切换时长、数据同步延迟、业务报错等核心指标，输出标准化演练报告，用于持续迭代优化应急预案。

四、核心技术落地：多品类信创组件适配与双活方案选型对比

1.信创数据库、中间件差异化双活适配方案

结合集团多品类国产化基础软件存量现状，针对不同产品定制专属集群同步架构，平衡业务可用性与硬件投入成本：OceanBase用于核心交易系统，采用三AZ三副本或五副本架构，依托多数派机制保障单AZ故障下数据一致性，稳定实现RPO=0；达梦、TD-SQL采用主备数据守护集群架构，同城主机房为主节点，另一机房部署异步备机，搭配监视器集群统一管控；MongoDB、Redis缓存采用双机房主备集群模式，当前Redis故障切换时长约10分钟，后续升级三AZ架构后，切换时长可压缩至30秒以内；RocketMQ消息队列将Broker主备节点拆分部署至不同机房，保障消息不丢失、业务消费不中断。

2.传统双活与单元化双活方案选型权衡

行业主流存在两类双活架构，项目团队完成全面成本、改造难度、业务适配对比，现阶段选择传统跨中心双活作为主力落地方案，单元化多活作为中长期演进路线。传统双活方案：应用跨双机房统一部署，数据库、中间件跨中心组成分布式集群，两套机房共用一套数据集群。优势为业务改造量低、落地速度快，20分钟内完成故障切换，适配保险现有复杂长链路业务现状，硬件投入可控。单元化双活方案：业务分库分表、按业务单元独立部署，单机房即可形成完整业务闭环，故障影响范围更小、切换速度更快；短板是改造复杂度极高，现有近千套存量系统重构成本巨大，暂不匹配当前阶段建设目标。

3.两地三中心灾备模式：分层覆盖三级灾难应对场景

整套架构形成“同城双活+同城仲裁AZ+异地灾备”完整两地三中心布局，分层应对不同等级灾难事件：第一，单应用、单组件故障场景：应用、中间件集群自动完成主备切换，RTO＜5分钟，业务运行基本无感；第二，同城单数据中心整体故障场景：另一同城机房完整承接全部核心业务，RTO＜20分钟，RPO=0，全程无数据丢失；第三，城市级全域灾难场景：业务流量切换至异地灾备中心，依托异地应用冷备+部分热备资源承接业务，RTO约2小时，仅存在数分钟级数据落差。

五、项目落地成效与行业可复用实践经验

1.平台建设与业务落地成果

第一，信创自主可控全面落地，实现从底层芯片、操作系统、数据库到上层业务应用全栈国产化，建成多层级多AZ信创云底座，完成机房、网络、云产品、管控面全链路双活灾备演练验证；第二，核心业务连续性指标全面达标，稳定实现数据中心级同城双活，关键业务RPO=0、RTO＜20分钟，完全满足金融监管最新灾备合规硬性要求；第三，核心业务系统分批上线落地，集团100余套纳入双活改造范围的核心系统，当前已有近40套完成上线，2026年度计划完成80%系统改造；受国产化硬件供货周期、硬件价格波动影响，项目实施节奏适度放缓；第四，统一云管控能力成型，混合云管平台实现多中心资源统一运维，配套全链路监控、自动化应急演练平台，常态化灾备运营机制完整落地。

2.项目两大维度核心实践经验

①架构建设经验

一是坚持全链路统筹思维，严格依托八横四纵分层体系开展建设，每一层同步规划高可用保障方案，杜绝只重视底层存储、忽视应用层改造的片面建设思路，消除全链路各类单点短板；二是应用架构与云平台同步改造，基础设施信创双活建设与业务微服务、云原生重构同步推进，不割裂平台底座与上层应用架构，避免二次改造带来重复投入；三是常态化演练是保障高可用的核心抓手，分级演练机制持续验证切换流程，通过实战暴露数据同步延迟、流量调度、权限配置等隐性问题，持续压缩故障恢复时长。

②行业推广落地经验

一是分阶段分批实施，降低业务冲击。以试点系统验证整体技术方案，形成标准化流程后批量复制，适配中型金融机构有限IT预算、复杂存量系统的现实现状；二是信创转型与双活建设一体化推进。将国产化适配改造、机房双活改造合并为同一项目周期，统一申请资源、统一测试割接，减少重复人力、硬件投入，规避两次业务停机改造带来的运营风险。

当前国内金融行业信创建设与业务连续性保障已进入常态化、标准化建设阶段，对于绝大多数中型保险、金融机构而言，直接照搬大型银行单元化多活架构，将面临改造投入高、落地周期漫长、存量系统适配困难等现实阻碍。太保科技落地的信创云同城双活实践，以“八横四纵”分层体系为整体骨架、两地三中心国产化云底座为底层支撑，在有限IT投入约束下达成监管要求的金融级灾备指标，同时兼顾自主可控、业务稳定、成本可控三大核心诉求。该项目为国内中等规模持牌金融机构打造了一套轻量化、易落地的双活建设样板，为行业信创灾备标准化建设提供完整实操参考，也为金融机构中长期平滑向单元化多活架构演进夯实底层技术底座。