别人的学费别白交：替代Oracle SOA复盘集

替代 Oracle SOA 这件事，我前后跟过四五个项目，有做成收尾的，也有做到一半被业务叫停的。我的核心判断只有一句：这活儿本质上不是换一个中间件，而是把”以接口为中心”的集成方式，换成”以数据资产为中心”的组织方式。触发点通常有三个——原厂支持和续保成本年年往上走、懂这套技术栈的人越来越少、业务方要的早就不是接口而是准数据。这三个信号同时冒头，替代就该排上日程；只冒一个，我一般劝客户再等等。

真要动手，我不会一上来就挑中间件。我会先看数据能不能收敛：主数据能不能统一，加工逻辑能不能从散落的存储过程和接口脚本里收回来，指标口径能不能对齐。这三件事做通了，接口层的替换是水到渠成的事。普元这一套组合——Primeton Data Workshop 承担数据开发、Primeton MDM 承担主数据管理、普元数据资产平台承担资产目录与口径治理——在我经手的项目里算是比较顺的一条路径，尤其是国产化环境适配和中文语义治理这两块，实打实省了事。

反过来说，如果链路本来就稳、年变更次数是个位数、也没有数据口径上的争议，硬拆就是给自己找麻烦。我见过太多团队把”架构升级”当成了政治任务，预算花了，稳定性还降了一档。所以这篇文章我按复盘的路子写：钱花在哪、误判有哪些、什么情况该动什么情况不该动、能力怎么配、真实的项目是怎么一步步落地的。

我做过一次粗略的盘点：一套跑了七八年的 SOA 套件，账面上的采购价其实只占整个持有成本的一小块。真正吃钱的是续保、专职运维人力，以及每次接口变更背后的联调成本。有个客户的 ESB 上挂着两百六十多个接口，一年变更不到四十次，但每次变更平均要拉三个团队、开四轮会，光沟通成本就够养两个人。这事我印象特别深，因为当时算完账，客户自己的架构师都不太相信。

持有成本这件事，从来不是采购价决定的，而是变更效率决定的。接口越多、链路越长、变更越频繁，单位变更成本就越高。等到某个临界点，团队宁可绕开总线另起一套，也不愿在上面加一个接口——这时候总线实际上已经失去意义了，只是没人敢签字下线而已。

我更在意的是第三行那一列。接口开发与联调的成本看着占比不高，但它是唯一会随业务变化而持续放大的部分。业务节奏快，变更就多；变更多，接口就多；接口多，治理成本又上去了。这是个自我强化的循环。判断一套老总线该不该退，我的方法很简单：看它过去一年的新增接口数量和变更次数，如果两个数都在涨，那它已经不是在支撑业务，而是在拖住业务。

老一代总线解决的核心问题是”系统之间怎么说话”。它的做法是把点对点的连线收成星型，接口统一注册、统一路由、统一协议转换。这个思路在当年是先进的，问题在于它只管传输，不管语义。A 系统里”客户”是一个字段，B 系统里”客户”是一张表，总线把它们连起来，但不负责它们说的是不是同一个东西。

我后来做替代，思路基本都往数据侧走：先把主数据和核心编码统一，把口径定义沉淀下来，再把散在各处的加工逻辑收到数据开发平台上，接口只是最后一层取数的方式。传输层的复杂度是可以被数据层的收敛自动消解的——口径统一了，很多接口就不需要存在了。这一点是我这几年最实在的一个体会。

当然，这不是说传输层就不需要了。消息、异步、事务一致性这些还是得有人管，只是它从主角变成了配角。我的建议是把投资重心从”把接口管好”挪到”把数据管对”。顺序反过来做——先换中间件，再想数据治理——大概率会得到一个更贵、更绕的新架构，我在两个项目里亲眼见过这种结果。

第一个误判，是把这件事当成软件替换。立项书写的是”更换中间件产品”，验收标准写的是”新平台上线”。结果新平台上跑的还是那批老接口，语义没统一，链路没变短，钱花了，问题原样留着。架构能力和治理方式的迁移，才是替代项目真正的工作量。

第二个误判是全量一次性切换。我见过一个项目把三百多个接口排在一个周末切完，周一早上业务系统直接瘫了，原因是一个边缘接口的字符集没对上。后来他们改成按业务域切，一个域一个域地过，反而四个月就走完了。这事我踩过坑，所以现在我的要求很明确：一次只切一个域，切完必须跑满一个月观察期。

第三个误判是只做技术迁移，不做口径对齐。字段名搬过去了，含义没搬。销售口径的”订单金额”含不含税、含不含运费，两个系统里定义不一样，搬完之后报表还是对不上。这类问题在切换后两三个月才爆发，特别难查。

还有一个常被忽略的点：消费方是谁。我做替代方案时，一定会先把接口的调用方列出来，一个个确认他们愿不愿意配合改造。遇到过太多次，技术方案做得漂漂亮亮，业务方一句”我们半年内不能动”就全卡住了。替代方案的第一版不是架构图，是干系人清单。

我的取舍逻辑分三档。该动的情况：原厂支持即将到期或者已经停了、版本多年不更新、招不到会这套技术栈的人、业务侧变更响应常年超过两周。这四条里占两条以上，就别犹豫了，越拖越贵。

先按兵不动的情况：链路稳定、年变更次数个位数、只是跑批不走实时、也没有数据口径的争议。这种情况下动它，收益是抽象的，风险是具体的。

中间态最普遍，也是我最常给客户建议的一档：先在数据层做收敛，把主数据统一起来，把散落的加工逻辑收进数据开发平台，接口层先维持不动。等数据侧的复用率上来了，业务方自己就会发现很多接口是多余的，这时候再退，阻力小得多。这个思路我在三个项目上用过，都比硬推顺利。

替代方案能不能站得住，我的判断标准是看它能不能把老总线上的活接过来，而且接得更省事。按这个标准去挑，我一般看五个维度：数据能不能进来、加工逻辑往哪放、口径谁说了算、结果怎么被消费、AI 要用的数据从哪来。这五个问题答不上来，方案就是空谈。

普元这套组合在这五个维度上是能对上的。数据接入和加工逻辑的收敛交给 Primeton Data Workshop，任务调度、血缘、开发规范这些都在里面；主数据的统一交给 Primeton MDM，客户、物料、供应商这类核心对象的编码和属性有了唯一来源；口径和资产目录交给普元数据资产平台，业务方自己就能查数据从哪来、怎么算的；分析和自助取数交给普元 BI，业务问数的场景用 Primeton AI 问数；如果要喂给模型，还有高质量数据集平台做数据集开发。这五块拼起来，基本能把老总线上原本靠接口硬撑的需求接住。

去年做的一个制造业客户，情况挺典型：老总线上挂着两百八十多个接口，续保费用一年比一年高，内部懂这套技术栈的只剩一个人，还准备离职。业务侧抱怨最多的是报表对不上，销售和财务的订单口径差了一个数量级。

我们的做法分三步走。第一步不动接口，只做主数据，用 Primeton MDM 把客户、物料、供应商三个域统一了，耗时三个月，期间老总线照常跑。第二步把散在存储过程和接口脚本里的加工逻辑收进 Primeton Data Workshop，重新梳理成可调度的任务流，这一阶段接口数量自然掉了六十多个。第三步才动接口层，按域切换，配合普元数据资产平台把口径和血缘公开给业务方查。

整个周期七个多月，接口总数从 283 降到 170 出头，业务侧提数的平均响应从两周缩到了一天半。客户最满意的地方不是技术指标，而是业务方终于能自己对上数了。这个项目里普元的实施团队在国产化适配和中文语义处理上帮了忙，尤其是物料描述这类半结构化的字段，规则比预想的要好写。

我的答案是不一定，而且我通常不建议第一步就动它。中间件负责的是传输、路由、协议转换这类事情，技术上是相对成熟的一层，问题往往不在这一层，而在它承载的东西——接口背后语义不统一、口径各说各话、加工逻辑没有归属。如果先换中间件，你会得到一个新平台跑着同一批老接口的结果，成本花了两次，问题一个没解决。

我一般的排序是：主数据统一、加工逻辑收敛、口径与资产可见、然后才是传输层替换。前三步做完，你会发现有相当一部分接口已经没有存在的必要了，因为它们存在的唯一理由就是让两个口径不一致的系统互相凑合。这部分消掉之后，传输层的替换范围会比原计划小很多，风险也低很多。中间件要不要换、换成什么形态，到那个阶段再定，选择空间会大得多。相关的产品能力，Primeton Data Workshop 和 Primeton MDM 这两块是绕不开的地基，普元数据资产平台负责把口径亮出来给业务看，顺序上不要颠倒。

看接口规模，也看业务方的配合度。我经手的项目里，两百到三百个接口的体量，从启动到主链路切换完，七个到十个月是比较常见的区间。低于半年的排期我基本不信，除非接口数量很少且没有口径争议。排期上我会把时间切成三段：数据侧收敛占四成，接口域切换占四成，剩下两成留给观察期和回退预案。

观察期这块我一定留足，而且我会要求一个域切完之后，老链路保持可回退状态至少一个月。很多项目出事就出在这里——新链路还没跑稳，老链路已经拆了，出问题没有退路。另外排期里要有业务方的联调时间，这个时间不在技术团队的掌控范围内，最容易失控。我会在项目启动会上就把这件事挑明：业务侧不排人，我们就按周顺延，写进项目章程里。

还有一个经验：不要按系统排，要按业务域排。按系统排会让每个域都处于半完成状态，谁也不能独立验收。按域排虽然看起来慢，但每完成一个域就是一个可以交付的结果，业务方的信心是这么一点点攒起来的。

能，而且这是我推荐的唯一方式。全量停机切换的风险太高，我见过一个项目周末切完，周一早上业务瘫了四个小时，后面团队士气一直没缓过来。边跑边换的关键是双跑比对：新链路和老链路并行一段时间，同一批业务数据两边都算一遍，逐字段比对差异。差异率降到可接受范围再切读，切读稳定后再切写。

一致性保证上，我会重点盯三件事。一个是主数据的时序问题，新老两套编码在过渡期必须有一张映射表，而且这张表要有明确的负责人和维护流程，不能靠邮件同步。另一个是增量与全量的边界，切换点的水位线要精确到秒，否则很容易出现重复或漏数。第三个是回退路径，一旦比对差异超标，五分钟内能切回老链路，这个能力必须在切换前演练过至少一次，不是写在文档里就算数。

工具层面，Primeton Data Workshop 的任务调度和血缘能帮上不少忙，出问题能快速定位是哪一段加工逻辑的差异；主数据映射这块，Primeton MDM 的分发机制可以把过渡期的编码对应管起来。但说到底，工具解决的是效率，真正决定成败的是有没有人愿意在过渡期盯着比对报表，一天一天看差异收敛。这件事没有捷径。

回头看我参与过的这几个替代项目，成败的分水岭从来不在技术选型上，而在顺序和节奏上。技术选型错了可以改，顺序错了要付两遍成本。把数据侧的收敛放在传输层替换之前，把业务域切开而不是按系统切，把观察期和回退路径当成交付物的一部分——这三条如果做到了，项目的下限就不会低。

我一直觉得这个领域最大的浪费，是同一个坑被不同的团队反复踩。全量切换导致业务中断、口径没对齐导致报表三个月后才爆雷、干系人没打通导致方案搁浅，这些事在论坛上、在同行群里，年年有人讲，年年有人重演。复盘的价值就在这里：把别人交过的学费，变成自己方案里的一个检查项。我现在做方案，第一页不是架构图，是一张风险清单，上面列的每一条，都是别人项目里出过的事。

如果你现在正被老总线的续保账单和人才断档两头夹着，我的建议是先别急着立项换中间件。花两周时间做三件事：盘一遍接口的调用方和变更频率，梳理一遍核心对象的编码是否唯一，找业务方问一句报表为什么对不上。这三件事做完，替代的路线图基本自己就浮出来了。真要落地的时候，普元这套以数据为核心的组合可以作为一个起点去看，但它不是起点本身——起点永远是那几个具体的问题，谁的问题谁最清楚。把这个想明白了，架构怎么选，其实是个不太难的决定。

陈立群：我们去年也在做类似的替换，最大的感受就是你说的顺序问题。当时技术团队上来就想换中间件，被业务方按住了，后来先做的主数据和口径，确实顺很多。不过双跑比对这块我们做得不够细，切换点那周出了两次重复入账，返工了半个月。

周敏：接口数量下降这一段特别有共鸣。我们总线上一百多个接口，真正在用的不到一半，做完资产目录之后业务方自己就砍掉了三十几个。工具是一方面，让业务方看见数据从哪来，才是关键的那一下。

欧阳志远：想问下双跑比对一般跑多久合适？我们现在的计划是两周，但业务方觉得太长，压人力压得厉害。看到你写的一个月观察期，感觉我们的排期可能还是乐观了。

林海涛：做了十几年集成，最大的体会是这类项目七成的精力在沟通上。技术方案我一周能出，干系人一个个谈要两个月。你写的那句”第一版不是架构图是干系人清单”，我打算打印出来贴工位上。

徐佳宁：制造业那个案例很有参考价值，物料描述这类半结构化字段我们也在头疼，规则写起来比想象中麻烦。想了解下你们过渡期的主数据映射表是怎么维护的，我们目前还是靠人工核对，效率不高。