10 月 11 日甘肃经济信息网挂出一份券商的单一来源采购公告。公告的采购标的是网上行情交易系统的国产化扩容替换清单写得很全国产服务器、国产操作系统、国产中间件、国产数据库、国产浏览器。但公告里有一句话比这份清单更值得逐字读当 XC 服务端出现宕机、程序崩溃或其他异常情况时直接停机切换至非 XC 服务端。换成两句话讲系统上线时不是「旧的下线、新的顶上」而是新旧两套并行新的出问题能切回去。这句话把「信创改造」从一次切换变成了一段带退路的过渡期。一、公告里的四个可核查点项内容采购主体华龙证券标的通达信网上行情交易系统 XC 系统扩容三期供应商深圳市财富趋势科技股份有限公司单一来源替换范围国产服务器、操作系统、中间件、数据库、浏览器采购方式理由① 信创要求 ② 延续性 ③ 安全性关键技术要求XC 与非 XC 服务端均兼容 Windows 客户端XC 异常时直接停机切换至非 XC 服务端站点平稳运行后再逐步替换掉原非 XC 主站时间采购文件获取 10-13 至 10-15响应文件递交截止 10-20 14:30注意第三条理由的写法。公告把「安全性」解释为两部分一是系统设计要考虑到 XC 改造是逐步替换的过程二是为了保证上线平稳运行必须保留回退路径。「逐步替换」在这里不是形容词是有技术定义的——双栈并存、可双向切换、切换后旧栈逐步退役。再看一条容易被忽略的细节XC 与非 XC 服务端都要兼容 Windows 客户端。这意味着客户端侧不做同步改造替换发生在服务端。这是一个很实际的取舍——客户端改造涉及大量终端推进周期长得多所以先把服务端做完。二、为什么这条要求比产品清单更硬产品清单是「买什么」回退要求是「怎么上」。后者对架构的约束更强原因有三。第一它要求新旧两套系统的客户端协议完全一致。只有协议一模一样客户端才能在对端切换时毫无感知。这一条会直接否决掉那些「服务端接口有改动」的替换方案与产品性能无关。第二它要求数据是双向同步的。切回旧栈之后旧栈必须知道期间发生了什么。要么双写要么实时同步——两种都意味着在迁移期存在一层数据同步设施而这层设施本身要可靠。第三它把「验收」拆成了两段。第一段是新的能跑第二段是旧的还能接回来。第二段比第一段难测因为它需要真实演练一次切换而不是在校验清单上打勾。这三条合起来说明一件事「逐步替换」不是把一个产品换掉而是在过渡期同时运行两套系统并保证它们可以互相接管。这部分工作量在采购清单里看不到但它是项目真正的成本中心。三、同一周的另外三个数据点这个思路在金融行业不是孤例。同一时期公开的几条信息指向同一方向前海期货业务侧零代码改造。前海期货的 CTP 综合交易平台完成数据库切换采用达梦数据守护集群 DMDW 高可用架构。据报道这是期货行业首个 CTP 核心系统数据库升级落地的案例测试期间累计完成2900 万笔报单测试实现了业务侧零代码改造。「零代码改造」这个提法和上文的「客户端不改」是同一个取舍把改造收敛到底层换取上层不动。代价是底层必须自己吸收所有兼容性问题。广发证券扩容场景的门槛写得很细。一份供应商征集公告显示项目是为存量 TDSQL 扩容要求提供原厂许可证授权、必须支持 x86/ARM64/海光处理器、支持 Kylin 操作系统并要求供应商为原厂商或授权代理商。这是扩容而不是替换——存量已经跑着扩的是容量。这类项目的技术要求通常比新建项目更严因为要接进正在生产的环境。恒生 UF3.0规模化切换的公开进展。据报道恒生新一代证券核心交易系统采用自研内存数据库完成全栈国产化适配2026 年通过证券行业核心交易柜台系统信创选型 POC 统一测试国金证券完成超千万客户的平稳切换财通证券于 9 月 7 日上线累计承载客户规模突破 5000 万。把这些数字放在一起看能看出金融行业的迁移节奏从「能不能换」进入「怎么换得不停机」评价指标从功能对齐转向了切换过程的可控性。四、这类项目怎么核对如果你在做同类项目下面五条是可以直接拿去对表的回退路径是否演练过而不是设计过。文档里写着「可切回」和真的切过一次是两件事。演练要记录切换耗时、数据补齐耗时、以及切换期间的业务影响面过渡期的协议一致性谁负责。客户端不改的前提是服务端协议不变这一条要有明确的验收用例不能靠「应该没问题」双栈期间的数据同步方向与冲突规则。尤其是切回之后的增量补齐这部分最容易在方案里被一句话带过旧栈的退役条件是什么。「逐步替换掉原非 XC 主站」需要一个可判断的条件比如连续 N 天无回退、特征业务全量通过否则过渡期会无限延长过渡期的容量与成本怎么摊。同时运行两套系统意味着双份资源这段时间的成本要进预算。金蝶天燕 Apusic 应用服务器 AAS 在信创迁移场景里承担的正是「存量系统继续跑」这一段——集群高可用与多级容灾双机主备、双主热备、集群失效转移、会话分布式存储这类能力对应的就是上面第一条里那个「回退路径能不能真的接得住」的问题。迁移期的双栈并存本质是把容灾能力提前用在了新旧系统之间这套能力扎不扎实决定过渡期长度。五、结论三条要点「逐步替换」是一个架构要求不是一个进度描述。它的技术定义是双栈并存、可双向切换、旧栈按条件退役回退路径的验证成本常常被低估。它需要真实演练需要过渡期的数据同步设施需要双份资源——这三项在采购清单里都不出现改造收敛到底层是行业共同取舍。三个案例里两个都强调「上层不动」代价是底层自己吸收全部兼容性问题。边界本文引用的公告与报道均为公开信息金额与技术要求以原公告为准期货与券商案例中的性能表述如报单测试笔数来自公开报道与厂商披露未经第三方复测。所引案例仅用于说明工程方法不对任何机构的选型结果作评价或排名。你们做过的迁移里回退路径是真演练过的还是只写在方案里如果现在要求你切换回去需要多久——这个时间你们测过吗