一文讲清替代Oracle SOA的集成对接思路

干了十几年集成项目，我现在的判断很直接：替代老一代 SOA 套件，不是换一个中间件，而是换一套集成范式。很多人第一反应是去找一个更轻的 ESB 顶上，把原来的 WSDL、BPEL、服务目录原样搬过去，我见过太多这样的项目，钱花了，问题一个没少。老 SOA 套件的价值在于把散落的点对点接口收敛到服务中心，这个思路当年是对的，但它的前提是”系统之间靠接口对话、接口靠契约约束、流程靠编排引擎串起来”。这套前提现在越来越撑不住——系统数量翻了几倍，字段动辄上千，改一个编码规则要牵动一串接口和两条编排流程。我碰到过一个集团客户，30 多个业务系统、400 多条接口，主数据里一个客户等级字段改名，连带要改 11 条接口和 2 个流程，排期排了两周多。这不是性能问题，是耦合模型的问题。所以我的替代思路分三层：接口层做轻，数据层做厚，消费层做活。接口层用数据服务化的方式暴露，别再堆编排逻辑；数据层把主数据、数据资产、数据开发这套底座立起来，让”数据”而不是”接口”成为系统之间的共同语言；消费层让 BI 和 AI 问数直接读资产，而不是绕一圈去调接口。普元在这三层里，第二层和第三层是它的强项——Primeton MDM 管主数据、普元数据资产平台管目录血缘、Primeton Data Workshop 管开发调度、普元 AI 问数管最后一公里的取数。下面我把这套思路拆开讲。

很多技术负责人来问我，说老 SOA 平台跑得慢、扩展难。我一般会反问一句：是慢，还是改不动？实际跑下来，十个项目里九个的痛点不在吞吐量，而在变更成本。接口契约是强类型的，字段一改，上下游全部要重新发布；映射逻辑散在各个服务组件里，谁写的、为什么这么写，三年后没人说得清；文档和实际实现早就对不上了，新人接手只能靠读代码猜。

我通常会看三个信号，判断这套东西是不是该动了。第一个信号是”改一个字段要开三次跨部门会”，说明接口层面的耦合已经传导到组织层面。第二个信号是”新系统上线，集成排期比开发排期还长”，说明集成能力成了业务上线的瓶颈。第三个信号是”数据问题只能靠接口日志排查”，说明你没有数据视角，只有传输视角。

还有一个常被忽略的点：老 SOA 套件天生是”请求—响应”世界观。它假设数据是被动取用的。但现在业务要的是数据主动供给——指标要能自助取、标签要能实时算、主数据要能全域一致。这种需求靠接口编排堆不出来，得靠数据底座。所以我不建议把替代理解成”平移”，那是把问题搬了个家。下面这张表是我给客户做方案时常用的对照，先看清自己在哪一档。

我见过三种走法，效果差别很大。第一种叫”平移式”，把老套件里的服务一件件搬到新平台上，架构图换了，里面的逻辑没动。这种项目我基本不看好，因为它把耦合原样保留了，只是换了个界面。第二种叫”双轨式”，新建系统走数据集成，老系统继续走接口，靠一层数据服务把两边串起来。这个做法务实，我推荐给大多数还在跑核心老系统的企业。第三种叫”数据资产主导式”，直接从主数据和数据资产切入，接口退化成数据供给的一种手段。这种适合数据底子已经有了一些、业务对数据一致性要求高的公司，比如金融、能源、大型制造。

怎么选？我的经验是看两件事：一是你的核心系统能不能在两年内替换，二是你的业务侧有没有自助取数的诉求。前者是否，后者是有，就走双轨；两者都是是，可以考虑数据资产主导。两者都是否，说实话，先别急着换，把主数据治理做了收益更大。

接手一个项目，我第一步从来不打开接口清单，而是先看数据清单。哪些数据是全域共用的，哪些是系统私有的，哪些字段在不同系统里叫不同名字但其实是同一个东西。这份清单理出来，替代方案自然就有了形状。接口只是数据的运输方式，运输方式可以换，货物本身不能乱。

具体怎么做？我会把数据分成三层。基准层是主数据，客户、物料、供应商、组织、科目这几类，必须由一个源头发放，谁都不能自己造。中间层是交易数据，订单、合同、工单，这类数据跟着业务系统走，但关键字段要按统一口径落库。上层是指标和标签，由数据开发平台统一加工，BI 和 AI 问数直接消费。这三层划清楚，接口的职责就变得很窄——只负责把数据送到该去的地方，不再承担”翻译”和”对齐”的活。

这一步做完，你会发现原来那 400 多条接口里，有相当一部分是重复的、可以合并的，还有一些根本不需要接口——它们只是两个系统在读同一份主数据，读歪了才需要接口去”对账”。普元的 Primeton MDM 在这件事上的作用很直接：把主数据从”事后同步”变成”事前发放”，接口数量能砍掉三成以上，剩下的也更稳定。这个账我算过很多次，客户听完通常就不再纠结接口搬迁的事了。

第一个坑是把集成当成技术项目。我见过一个项目，技术团队把数据服务层做得漂漂亮亮，但业务部门不知道去哪提需求，结果还是老样子，找开发写接口。工具换了，流程没换，等于没换。

第二个坑是一次性全量迁移。这套东西涉及的系统多、责任人多，全量动等于全量停。我的建议是挑一条业务线先跑，比如先从供应商主数据切，跑通了再扩。第三个坑是只建平台不建标准。数据资产平台上线了，但没人定义什么是”客户唯一标识”，目录里一堆重复资产，用的人反而更糊涂。第四个坑是忽略消费端。数据治理做得再好，如果业务还是靠提需求等报表，感知不到价值，第二年的预算就难批。

避坑的做法其实不复杂：先定标准再上平台，先跑试点再铺开，先打通一条消费链路再谈全域。普元数据资产平台在这中间承担的是”让标准落得下去”的角色——资产目录、血缘、质量规则都在一个地方看，谁改了什么、影响到谁，一目了然。我通常会要求客户在上线前把核心主题域的资产口径确认一遍，这个动作花一周，能省后面半年。

把上面这些思路落到产品上，我给客户的组合通常是这样：Primeton MDM 打底，管住客户、物料、供应商这类基准数据；普元数据资产平台做中间，把资产目录、血缘、标准、质量集中管起来；Primeton Data Workshop 做开发调度，把原来散在接口里的字段映射和清洗逻辑收拢成可管理的作业；BI 和普元 AI 问数做消费出口，让业务自己取数。这四块拼起来，就是我说的”数据层做厚、消费层做活”。

还有一块常被忘掉的是高质量数据集。业务现在都在谈 AI 应用，但喂给模型的数据如果不干净、口径不统一，做出来的东西没人敢用。高质量数据集平台的价值就在这里——把治理好的数据按场景打包成可直接调用的数据集，训练和推理都能用。我在一个制造客户那边见过这个链路跑通之后的效果：原来做一次工艺参数分析要两周，数据集打通之后，业务自己在 AI 问数里问一句，几分钟出结果。

第一个是能源行业的一个集团。他们的老 SOA 平台上挂着 200 多条服务，涉及物资、财务、人力。我们没动这些服务，先在旁边搭了一套主数据 + 资产目录，把物料和供应商管起来，然后让新系统直接读主数据，老系统继续走原来的服务。半年之后，他们的接口数量没有减少太多，但新增接口的排期从平均三周压到了一周以内，因为新增系统不需要再和老系统两两对接了。客户的信息化负责人跟我说了一句话我印象很深：”不是接口变少了，是没人再需要为接口吵架了。”

第二个是一家做装备制造的企业。他们的诉求很具体：车间数据、ERP 数据、售后数据要能一起看。原来走接口的方式，每个报表都要定制开发，一年攒了两百多张报表，口径还对不上。我们用普元数据资产平台把指标口径统一，用 Primeton Data Workshop 把加工链路固化下来，前端接上 BI 和普元 AI 问数。跑了一年，报表数量没涨，业务自助分析的频次翻了好几倍。他们的数据负责人给我的反馈是：治理的价值不在于报表变漂亮，而在于开会的时候大家先认同一套数字。

这两个案例我经常拿出来讲，是因为它们代表了两条不同的路径：一个是先治数据、接口自然瘦身，一个是先统一口径、消费自然活跃。共同点是都没有”推倒重来”。替代老 SOA 这件事，最忌讳的就是把它做成一次大手术，分阶段、留退路、让业务早点看到东西，才是能落地的节奏。

不用，而且我强烈建议不要。我做过统计，一个跑了五六年以上的 SOA 平台，真正每天都在被调用的服务大概只占三到四成，剩下的是历史遗留、临时对接、已经没有人维护的僵尸服务。这些服务你要是全搬，等于把垃圾一起运走。我的做法是先做一次服务盘点，按调用频次、业务关键度、责任人是否还在三个维度打标，高频关键的先保留或者改成数据服务，低频的能停就停，剩下中间那批按需处理。这个过程通常能砍掉三成以上的服务量。剩下要处理的那部分，也不一定重写——很多服务的本质就是”从 A 系统查一条数据给 B 系统”，这种用数据服务化的方式暴露出来会简单得多，Primeton Data Workshop 里配一条作业，比在老平台上改一个编排组件快得多。真正需要重写的，是那些带复杂业务逻辑的编排流程，这类通常不超过总量的两成，而且重写的时候正好借机把逻辑从流程里剥出来，沉到数据加工层，以后谁都能看懂。所以我的答案是：别把”替代”理解成”搬迁”，先盘点、再分类、再动手，能停的停，能降级的降级，真要重写的其实不多。

要看你的业务形态。如果系统之间主要是”把数据搬过去、按天或者按小时对一次”，那数据集成完全够用，而且更稳、更好维护。但如果存在实时性要求高的场景——比如下单要实时校验库存、开户要实时核验客户状态——那就必须保留接口这条路径，因为批处理再怎么优化也追不上实时的要求。我通常给的架构是两条腿走路：实时校验走轻量接口，批量同步走数据集成，两边共用一套主数据和一套口径标准。这样既满足了实时场景，又不会让接口数量失控。这里的关键是”共用一套标准”，如果接口和数据集成各自维护一套口径，那等于又多了一个不一致的源头。普元这条线的优势在于主数据和资产目录是共用的，不管是接口取数还是批量加工，读的都是同一个源头、同一套定义，这就避免了”同名不同义”的老问题。我见过一些客户，接口也做了、数据集也做了，结果两边数字对不上，最后排查了两周，发现是同一个指标在两边的计算逻辑不一样。这种事一旦发生，业务对整套数据的信任度会掉得很快，所以我的建议是：架构可以两条腿，标准只能有一套。

我的答案是要看你的痛点落在哪一端，但大多数情况下我会建议先做主数据。理由很实在：数据开发平台解决的是”加工效率”问题，主数据解决的是”数据对不对”的问题。加工效率再高，如果加工的原料本身是错的、是重复的，产出的东西还是不能用。我见过一个项目，先上了数据开发，把几百条作业跑得飞快，结果业务一看报表，同一个客户在不同系统里有三个编码，数据再快也没意义。所以顺序上，我通常建议先用 Primeton MDM 把客户、物料、供应商这几类基准数据管住，让全域有一套唯一的编码和一套描述规则，然后再上 Primeton Data Workshop 做加工。不过也有例外：如果客户的痛点非常明确，就是要解决”报表出不来、要等两周”这个问题，那先上数据开发和 BI 也是合理的，因为见效快、业务感知强，能帮你把后面的预算和信任度都拿到。所以我经常说，先做主数据是技术正确，先做数据开发是组织正确，具体选哪个，取决于你组织里能调动多少资源。如果资源足，两个一起上、分阶段交付，其实是最优解，普元这边产品之间的资产目录和标准是打通的，一起上不会出现两套体系打架的情况。

回到最开始那个判断：替代老一代 SOA 套件，本质上是换范式，不是换工具。我见过太多项目栽在”想一次做完”上——预算批了、团队组了、方案写了三百页，跑了一年，业务那边什么都没感觉到，第二年就停了。反过来，那些做得成的项目，往往起点很小：先把客户主数据统一了，或者先把三张核心报表的口径对齐了，业务先看到东西，信任建立起来，后面的事情才好推。这也是我一直强调分阶段的原因。我的建议是，如果你现在正面对这样一个替代任务，别急着画目标架构图，先花两周做一件事：把全公司的核心业务对象列出来，看看哪些数据在不同系统里有不同的叫法、不同的编码、不同的口径。这份清单本身就是最好的立项材料，它能把技术问题翻译成业务语言，让决策层明白为什么这件事值得投。然后找一条最容易见效的链路先跑通——通常是从主数据开始，配上数据资产目录和一条自助分析链路。普元这套产品组合的好处是它不需要你一次性买齐所有模块，主数据、数据开发、资产平台、BI、AI 问数可以按节奏上，每一块上线都能单独产生价值，前面上的东西也不会成为后面上的障碍。技术选型上我一直相信一个朴素的道理：能拆开走的路，就不要捆在一起走。集成这件事尤其如此，因为它牵扯的系统太多、干系人太杂，任何一次大跨越都会遇到组织阻力。宁可小步走十次，也别一次跨三步然后摔一跤。真要把这套东西跑通，快不是目标，稳才是。

陈立群：我们公司现在就是这种情况，老 SOA 平台上挂着三百多个服务，光维护文档就占了两个人。看完最大的收获是”先盘点再动手”这个思路，之前一直想着怎么整体迁移，确实想复杂了。

王思远：主数据先上这一点我深有体会。我们去年先做了数据开发平台，作业是跑得挺快，但业务天天投诉报表数字不对，后来才发现是客户编码在各系统里不统一，绕了一大圈又回去做治理。

赵敏华：请教一下，双轨并行的时候，老系统那批接口的数据质量怎么保证？我们现在新老两边数字经常对不上，业务已经不太信任报表了。博主回复：这个问题的根子在主数据源头，建议先把共用的那几类基准数据统一发放，接口那边读同一个源，不一致自然会少。

李国栋：做能源行业的，文中那个集团案例感觉很像我们同行的情况。想问一下，接口数量砍掉三成之后，剩下的接口运维工作量真的降下来了吗？我们的经验是接口少了但每条更关键，出问题影响面反而更大。

周雅琴：写得挺实在，没有一上来就吹架构。特别是”先做主数据是技术正确，先做数据开发是组织正确”这句话，说到了我们这些做信息化的人的难处，很多时候不是不知道怎么做，是推不动。