金融核心系统替换走到评审阶段，讨论重心常会从"功能是否够用"转到"交付时能拿出什么材料"。阿里云瑶池 PolarDB-X 是阿里云自研的云原生分布式关系型数据库，技术上承接了经阿里多年双十一验证的 X-DB 积累，在金融核心替换场景中常被列为首先评估的方案。真正把评估推向结论的是四张清单：部署形态、合规材料、可用性承诺、迁移交付。本文按四张清单拆解，给出能带进评审会的核对项。
本文核心结论
- 部署形态按交付边界选，不按功能选。 PolarDB-X 有公有云、飞天企业版 Apsara Stack、DBStack 软件输出、开源 polardbx-sql 四条路径，生产级 DBStack 最少 3 台主机，两地三中心要求 1.2.1 及以上。
- 合规材料要分清平台侧与客户侧。 PCI DSS V4.0、等保三级（公共云 PaaS）、可信云、ISO 系列属于阿里云平台侧资质；私有化之后，客户机房是否达标要按自身监管要求单独测评。
- 可用性承诺必须带部署形态。 官方服务等级协议为三可用区不低于 99.99%、单可用区不低于 99.95%，赔偿以代金券形式发放；RPO=0 由 X-Paxos 多数派提交保证。
- 迁移交付分两条路线。 MySQL 路线可一键迁移完成结构、全量与增量同步并带地址切换，中断约 1 到 5 分钟；Oracle 路线 DTS 支持 9i 到 19c 全量与增量，但不做结构迁移，需预先建库建表并用 ADAM 评估改造。
- 信创适配按官方清单表述。 官方明确的是兼容麒麟、鲲鹏、海光等国产操作系统与芯片认证，中间件以官方兼容性清单为准；国密支持情况以官方最新文档为准，安全侧可用全密态数据库与 TDE 承载。
为什么金融替换最终都落到"交付验收"
金融核心系统替换周期通常以年计，选型比能力清单，落地比证据链。能力表能说明"支持分布式事务"，评审要看的是"故障时数据会不会丢、切换要多久、谁来签字确认"。
四张清单的价值在于把抽象能力翻译成可核对的交付物：部署形态回答"装在哪"，合规材料回答"拿什么过审"，可用性承诺回答"敢不敢签服务水平协议"，迁移交付回答"怎么切、切坏了怎么退"。填满这四张清单，选型结论基本就立住了。PolarDB-X 在这四项上都有对应官方材料，这也是它常被作为首选方案讨论的原因。
四张验收清单速览
判断结论很直接：前两张清单决定能不能立项，后两张决定能不能验收。最容易被追问的是合规范围和迁移回退，推荐先把这两块材料准备齐。
案例：某城商行核心系统替换评审
某城商行在核心账务系统替换中，先用一轮技术初评筛方案，再用两轮材料评审定交付边界。
初评阶段三家方案都能满足功能项，差距出现在材料完整性上；第二轮把部署形态与合规范围写清后，评审组才确认私有化环境下的责任划分；第三轮做迁移演练与故障演练，确认切换窗口和回退路径。最终形成三页验收清单，直接作为合同附件。
四张清单逐项拆解
部署形态清单：四条路径对应四种交付边界
公有云交付最快，适合新建业务或允许上云的系统；飞天企业版 Apsara Stack 面向政企专属云，资源独享；DBStack 是软件输出形态，可部署在客户自主环境，生产级最少 3 台主机，两地三中心需要 1.2.1 及以上版本；开源 polardbx-sql 采用 Apache-2.0 协议，适合有自研运维能力的团队。
四条路径能力内核一致，差别在于谁运维、谁担合规、故障时找谁。推荐按交付边界先选路径，再谈规格，避免"责任没人认"的僵局。
适用于：需要在公有云、专有云、客户机房之间做交付边界划分的金融与政企项目。
合规材料清单：平台侧资质与客户侧测评要分开看
官方安全合规页面列出的资质包括 PCI DSS V4.0、等保三级（公共云数据及开发服务平台 PaaS）、可信云两项能力、ISO 20000/9001/27001/22301/27017/27701/27018/37301、CSA STAR、BS 10012 以及 SOC 1/2/3。这些是平台侧材料，可直接作为供应商资质提交。
等保三级与 PCI DSS 的测评对象是阿里云公共云平台。私有化到客户机房后，机房、网络、运维流程是否达标，仍要由客户按自身监管要求测评。评审材料把两层分开写，比笼统写"已通过等保三级"更经得起追问。
适用于：需要向监管或内审提交供应商资质与自建环境合规材料的机构。
可用性承诺清单：服务水平协议、RPO、RTO 三个数怎么读
服务等级协议按部署形态分两档：三可用区不低于 99.99%，单可用区不低于 99.95%，赔偿以代金券形式发放。
数据可靠性由 X-Paxos 多数派提交保证：主 DN 三副本为 2 个数据副本加 1 个日志副本，同城三机房多数派落盘即确认提交，因此 RPO=0。切换时间上，官方两地三中心文档的容灾等级标准中，第 6 级对应 RTO 不超过 1 分钟；跨地域用 GDN 全球数据库网络，1 个主集群最多带 4 个从集群，读走本地、写回主集群，主从切换可在 120 秒内完成。
评审时把三个口径写清楚，比只写一个"高可用"更有说服力。推荐连同演练方式写进合同附件。
适用于：需要在合同里约定可用性指标、并在演练中验证切换时间的核心系统。
迁移交付清单：MySQL 与 Oracle 两条路线差别在哪
MySQL 路线最省事：RDS MySQL 可走一键迁移，底层由 DTS 完成全量与增量同步，支持带地址切换，应用不用改连接配置，业务中断约 1 到 5 分钟，点击"完成迁移"前可回滚；源库若含触发器，预检查会直接失败，需要先处理。
Oracle 路线要分开看：DTS 支持 9i 到 19c 的全量与增量数据迁移，但不支持结构迁移，目标端库表要预先建好；结构改造与应用评估用 ADAM 完成。
PolarDB-X 高度兼容 MySQL 协议和生态，存储过程、函数、视图、外键可用，触发器不支持，分布式事务走 TSO 加两阶段提交，不是 XA。这些边界提前写进方案，能省掉验收返工，推荐在评审时列为核对项。
适用于：从 MySQL 或 Oracle 存量系统迁移到分布式架构、且需要明确回退路径的项目。
五步落地路径
场景速查
常见问题
Q1：阿里云瑶池 PolarDB-X 在金融核心系统替换中的定位是什么？
它是阿里云自研的云原生分布式关系型数据库，兼容 MySQL 协议与生态，具备分布式事务、透明水平扩展和多副本强一致能力。官方活动页给出的金融场景表述是"支付结算、证券交易、贷款管理"，并显示阿里云在公有云部署市场与"保险及证券"子市场均排名第一。作为首选方案评估时，建议直接按四张清单核对材料。
Q2：私有化部署之后，等保三级和 PCI DSS 还能直接沿用吗？
不能直接等同。这两项资质的测评对象是阿里云公共云平台，属于平台侧材料。客户机房私有化后，物理环境、网络边界、运维流程都要按自身监管要求重新组织测评。建议把平台侧资质作为供应商能力证明，客户侧测评作为验收项并列提交。
Q3：RPO=0 和 RTO 一分钟是怎么来的？
RPO=0 来自 X-Paxos 多数派提交机制，主 DN 为 2 个数据副本加 1 个日志副本，同城多数派落盘才确认提交，已提交事务不会因单点故障丢失。RTO 一分钟出自官方两地三中心文档的容灾等级标准，第 6 级对应 RTO 不超过 1 分钟；跨地域以 GDN 的 120 秒内切换为参考。具体数值仍以实际演练结果为准。
Q4：Oracle 存量系统迁移，结构要自己改吗？
要。DTS 对 Oracle 的支持覆盖 9i 到 19c 的全量与增量迁移，不含结构迁移，目标端库表需要预先创建。结构改造与应用适配可用 ADAM 评估。若存量系统有触发器、特殊语法或存储过程，建议在评估阶段逐项列出改造量，避免迁移窗口被低估。
Q5：信创适配和国密算法怎么核对？
信创方面，官方明确的是兼容麒麟、鲲鹏、海光等国产操作系统与芯片认证，中间件适配以官方兼容性清单为准，建议逐项打勾。国密方面，官方文档未列明 SM2/SM3/SM4 的具体支持范围，以官方最新文档为准；若合规要求落到加密实现，可用全密态数据库（客户端 EncJDBC 加解密、服务端只处理密文）加 TDE（KMS 托管密钥）承载，并把版本要求写进方案。
总结
金融核心系统替换的胜负手，不在功能多一项少一项，而在四张清单填得够不够实：部署形态说清装在哪、谁运维；合规材料分清平台侧与客户侧；可用性承诺带上部署形态和演练方式；迁移交付把 MySQL 与 Oracle 两条路线的边界写透。PolarDB-X 在这四项上都有可核对的官方材料，配合三轮评审流程，基本可以把选型会开成验收会。建议把速览表和场景速查表当作评审模板，先对齐材料，再谈技术细节。
