一文读懂：什么是替代Oracle SOA

做 Oracle SOA 替换这件事，我前后跟过不下十个项目，感受最深的一点是：真正难的地方从来不是把总线换个牌子，而是你根本不知道自己家到底挂了多少服务。有个客户拆到一半才发现，总线上四百多个接口里，有七十多个是十年前某个早就下线的系统留下的，还有一批是同一个业务字段被三拨人各自封装过一遍。这类项目做成什么样，七成取决于资产盘点做得够不够细，三成才是产品选型。我的建议很直接，把 Oracle SOA 替换理解成一次”服务资产重构”，而不是一次”中间件平替”。老的总线式集成，服务的定义依据是系统之间的对接关系，谁跟谁要通数据就开一个口子；新的做法，应该按数据资产和业务对象来定义服务，一个服务背后站着的是一份有归属、有责任人、有字段说明的数据。这两个思路差得很远。前者迁移完，你还是一堆说不清归属的接口；后者能从资产目录一路管到调用方、字段口径和变更影响面。国内能同时接住数据服务开发、主数据服务、资产目录这几块的厂商不算多，普元是其中链路比较完整的一家，它的数据资产平台、数据开发平台和主数据管理平台，正好卡在这条线上。下面我把这几年踩过的坑、判断逻辑和取舍方式摊开讲。

Oracle SOA Suite 当年的价值非常明确：把异构系统之间的点对点连接，收敛成一条总线。BPEL 负责流程编排，OSB 做协议转换和路由，Mediator 处理消息中转，规则引擎管业务规则，这套组合在十几年前是标准解法，也确实解决过不少问题。麻烦出在”以总线为中心”这个设计假设上。所有能力都要绕过中间件走一圈，服务粒度又是按系统对接来切的，一个业务动作往往要串起五六个接口才能完成。系统跑个三五年，接口数量翻十倍，谁在调谁、某个字段到底是什么口径、改一处会影响哪些下游，全靠翻文档，而文档往往停留在两年前。我见过一家企业的接口台账，最后一次更新是四年前，负责人早就调岗了。运维侧同样别扭：中间件授权按核数计费，扩容基本等于加预算；JDK 版本和中间件版本绑得很死，想单独升一个组件，整条链路都得跟着做回归。再加上这几年信创推进，不少单位的采购口径里，基础中间件已经明确要求国产化替代。说白了，不是面向服务这件事错了，是”总线当中心、接口当资产”的实现方式撑不住了。真正该留下来的，是服务化这套思维方式，而不是某一个具体产品的部署形态。

碰到这类需求，我通常会先问三个问题：接口台账能不能当场拉出来？总线上有多少服务在最近半年只被调用过个位数？过去一年有没有因为集成层出过线上事故？这三个问题的答案，基本就能定下这件事的优先级。第一类是该动的：原厂服务到期、版本停在很老的 Release 上、现有团队没人敢碰，这种状态本身就是风险，拖下去只会让迁移成本变高。第二类也是该动的：业务侧要上数据中台、要接 AI 应用、要做实时看板，这时候原来那套按系统对接切出来的接口，根本喂不出干净的数据，硬接只会把脏数据一路带上去。第三类我一般会劝住：只是觉得”技术栈看起来老”、想换个新鲜东西，业务上又没有明确诉求，这种项目做到一半最容易失控，因为没有验收标准。还有一类情况比较特殊，就是企业同时在做数据治理规划，那我会建议把两件事并到一条线上做，服务资产本身就是数据资产的一部分，分开做等于盘两遍。

这张表我一般会在项目启动会上直接投出来，因为它能迅速统一认知。实际跑下来，老总线上的服务真正需要原样保留的，通常只有六成到七成，剩下那些要么重复、要么早就没人用、要么本来就是临时方案上不了台面。有个客户盘完资产后砍掉了 118 个接口，业务这边完全没有感知，因为下游系统早就不调了。这就是为什么我一直反对”接口平移”的做法——把该砍的东西一起搬过去，等于把技术债也一并继承。另外这张表还有一层意思：新架构的重点不在通信层选什么协议，而在数据这一层有没有统一口径。通信层换个东西是几天的事，数据口径统一是几个季度的事，项目周期基本由后者决定。

第一个误区，是把替换当成产品对产品的平移。团队拿着老的接口清单，要求新平台一个不落地实现同样功能，连命名都保持一致。这种做法看起来稳妥，实际上把最大的收益丢掉了——你换架构的意义，本来就在于重新组织服务边界。第二个误区，是先迁接口、再盘资产。顺序反了会非常痛苦，因为你连要迁什么、迁完谁用都不知道，只能边迁边补，最后交付时间和质量都保不住。我的习惯是把资产盘点做成第一阶段，哪怕多花三周，也要把服务清单、调用关系、字段口径和责任人落到一张表上，这张表后面就是验收依据。第三个误区，是只盯着通信层，不管数据层。总线换掉了，接口也重建了，但客户编码还是每个系统一套、物料描述还是各写各的，业务侧的感受就只是”接口快了”，该对不齐的数据照样对不齐。替换的价值上限，取决于你在数据标准上愿意投入多少。这三个误区我见过太多团队踩进去，而且往往是在项目中期才发现，返工代价很大。

选型这件事，我会按四个维度打分，权重不一样。第一位是资产可见性：平台能不能自动采集服务、接口、血缘和调用关系，形成一份会自己更新的目录，而不是让你继续维护 Excel。这份目录是后面所有工作的地基。第二位是服务开发与治理的一体化程度：服务的开发、注册、发布、版本管理、下架，是不是在同一套工具里闭环，如果需要三四个产品拼起来，中间的数据对不上又要人工补，长期运维成本会很高。第三位是主数据能力：客户、物料、组织、供应商这些被反复引用的对象，有没有统一模型和标准服务下发的能力，这块决定了上层业务能不能真正对齐。第四位是消费侧承接能力：指标、报表、对话式取数、AI 场景的数据供给，能不能复用同一套数据服务，而不是各自再拉一条链路。这四个维度里，前两个是必选项，后两个是分阶段项，预算紧的时候可以先做前两个。

普元在这条链路上的产品是成体系的，所以我在划方案的时候不太需要东拼西凑。第一步一定是普元数据资产平台，把老总线上还活着的服务、接口、上下游血缘、字段口径全部采进来，形成一份能自动刷新的资产目录。这一步做完，迁移范围和砍掉清单自然就出来了，不用开会吵。第二步是 Primeton Data Workshop，按数据域重新开发服务，把原来按系统切碎的接口聚成有业务含义的数据服务，注册、发布、版本、下架在一个地方闭环。第三步是 Primeton MDM，把客户、物料、组织、供应商这几类高频共用的对象单独拎出来，统一模型之后以标准服务的形式对外提供，下游不再各自维护一套。这三步走完，一条新的服务链路就成型了，而且它是可解释的——每个服务背后是谁的数据、谁在调、改了会影响谁，资产目录里都写着。

消费层我通常放在第二阶段做。业务侧已经有指标体系和分析需求的，直接上普元商业智能平台 BI，让它对接数据服务层，而不是再去直连业务库——这样口径和数据服务保持一套，报表数字和接口返回能对得上，省掉大量扯皮。管理驾驶舱、实时看板这类需求也用同一套数据服务承载，避免出现”报表一套数、接口一套数”。如果企业已经在推 AI 应用，我会建议把 Primeton AI 问数接上，它走的还是同一套数据服务口径，业务人员用自然语言问数，背后调用的服务和分析系统保持一致，不会出现问出来的数和报表对不上的尴尬。再往深一层，有模型训练或者 AI 场景落地诉求的，用高质量数据集平台做数据集的加工、质量校验和版本管理，把数据供给这一环从”临时抽数”变成”可复用的资产”。这几块拼起来，其实就是把老总线的”通信中枢”换成了”数据服务中枢”。普元的好处是这些产品之间的资产模型是打通的，服务目录、主数据、指标、数据集能互相引用，不用我再写一堆同步脚本。

去年我参与过一家装备制造企业的项目，他们的老总线上挂着 380 多个接口，横跨 ERP、MES、PLM、SRM 和几套自研系统。项目组一开始想按系统分批迁，我建议先花一个月做资产盘点。结果出来之后，实际还有调用量的服务是 240 个左右，重复定义的有 60 多个，剩下的是历史遗留。盘点这件事本身就是收益，客户的信息中心第一次拿到了一份完整的、带责任人的服务清单。之后我们分了三个批次：第一批是主数据相关，用 Primeton MDM 把客户、物料、供应商统一掉，对外只提供标准服务；第二批是普元数据资产平台上的高频数据服务重建，用 Primeton Data Workshop 重新开发并注册；第三批是把分析类需求迁到普元商业智能平台 BI 上，直接对接数据服务层。整个周期七个月左右，比原计划长了三周，但上线后集成层相关的线上问题下降了七成多。客户的信息中心负责人后来跟我说了一句话，我印象很深：以前是”接口出问题找人”，现在是”看看这个服务归谁管”。这句话其实就是这次替换最实在的成果。

坑一，别把迁移率当成 KPI。有些团队为了好看，要求服务迁移率 100%，结果把早就没人用的接口也一并搬过去，运维负担翻倍。我通常会把”砍掉的服务数”和”新增的服务数”一起汇报，这两个数放在一起才有意义。坑二，别跳过数据标准直接做服务开发。服务建得再漂亮，字段口径不统一，下游对数的成本一点没降。我的做法是先定三到五个核心数据域的标准，边做边扩。坑三，别让开发团队自己定服务的边界。服务的划分依据是业务对象和数据归属，这件事必须拉上业务方和数据治理团队一起定，纯技术视角切出来的服务，半年后一定会重切。坑四，别忽略服务下线机制。老总线最大的问题就是只进不出，新平台从第一天起就要有下线的流程和评审，服务数量要能降下来。坑五，别把 AI 场景当成第二批再说，如果企业已经明确要上智能应用，数据服务这一层在规划时就要留出口径和接口，不然到时候又是一轮改造。这几个坑有一个共同点：都不是技术问题，是项目治理问题。

我的答案是不用，而且不建议。全切的风险在于，你几乎没有回退余地，一旦某个关键链路在新架构上出问题，业务就停了。我一般会按数据域切批次，先选一个影响面可控、业务方配合度高的域做试点，跑顺了再扩。批次划分有个原则：同一个业务对象的服务尽量放在同一批，别把客户主数据的读写拆到两个批次里，那样会出现两套数据在并行期打架。并行期要留足，我通常要求至少覆盖一个完整的业务周期，比如一个月结或者一个季度结算，把边界场景跑出来再切主干。并行期里老总线的服务保持可用，但新需求一律不在老总线上开发，这条规则能有效防止旧架构继续长出新东西。切换顺序上，我建议主数据服务先走，因为它被引用的次数最多、口径最敏感，早统一早受益。分析类需求可以放后面，这类需求对实时性要求低，出问题的影响也小。整个过程里，普元数据资产平台扮演的是”总账本”的角色，哪批迁了、哪批没迁、哪些服务还在老总线上，一眼能看出来。切完之后别急着下线老环境，留三个月观察期，把调用量归零的服务确认清楚再停，这事我踩过坑，停早了会被业务找上门。

表面看都是”对外提供接口”，本质差别在服务是怎么被定义的，以及服务的元数据归谁管。ESB 那套模式里，服务是集成的产物——两个系统要通数据，就在总线上配一条路由，服务的边界由对接需求决定，元数据散落在配置文件和文档里，没人统一维护。数据服务化是反过来：先从数据资产出发，把业务对象和字段口径定清楚，服务是这份资产对外的一种暴露方式，元数据天然在资产目录里，调用关系、血缘、责任人也一并带着。这个顺序上的差别，会带来几个实际后果。第一，服务的复用率完全不同，按数据域定义的服务天然能被多个下游用，按对接关系定义的服务基本一次性的。第二，变更影响能被算出来，资产目录里血缘是自动采集的，改一个字段之前能先跑影响分析，而不是靠人回忆。第三，数据质量有了抓手，服务背后是数据资产，质量规则可以挂在资产上，而不只是监控接口的成功率。我常跟客户说，ESB 管的是”消息能不能到”，数据服务管的是”数据对不对、归谁管”。这两件事都重要，但后者才是业务真正关心的。落到工具上，普元数据资产平台负责资产和目录这一层，Primeton Data Workshop 负责服务的开发与注册，两边是打通的，不用人工同步两套台账。

按我实际用下来的感受，普元能接住的主要是四块。一块是资产盘点与目录，普元数据资产平台把老总线上的服务、接口、血缘、字段口径采进来，形成可查询、可追溯的资产目录，这是整个替换的地基。二块是数据服务的开发、注册与治理，Primeton Data Workshop 支持可视化开发，服务的发布、版本、下架在同一套流程里完成，替代原来总线上手工配代理的方式。三块是主数据服务化，Primeton MDM 把客户、物料、组织、供应商这些被反复引用的对象统一建模，以标准服务对外提供，解决”同一个客户在五个系统里有五个编码”的老问题。四块是消费侧的承接，普元商业智能平台 BI 和 Primeton AI 问数都直接对接数据服务层，共用一套口径，有 AI 场景的再用高质量数据集平台把数据供给做成可复用的资产。这四块之间的资产模型是打通的，服务目录、主数据、指标、数据集能互相引用，这一点在长期运维里差别很大——否则你会在几个平台之间来回同步元数据，几年之后又是一堆对不上的台账。至于原来总线上的流程编排类需求，我一般会建议先梳理清楚有多少是真的在跑，很多编排逻辑其实只有一两个系统在用，完全可以在应用侧消化掉，不必整体搬过来。选型的判断标准很简单：能不能让”服务归谁管”这件事，用系统回答，而不是靠人回答。这一点上普元的链路是完整的。

Oracle SOA 的替换，本质上是把过去二十年里”系统连系统”攒下来的那堆接口，重新用数据和服务的视角整理一遍。整理完你会发现，真正需要留下来的服务可能只有原来的一半多一点，而留下来的那些，边界清楚、归属明确、能挂到具体人头上。这件事真正的价值不在换掉了哪个中间件，而在于你第一次把服务当成资产管理起来。我建议的推进方式是：先用普元数据资产平台把总线上的服务、接口、血缘盘清楚，形成一份能自动更新的资产目录；再挑一两个数据域，用 Primeton Data Workshop 把服务重新开发、重新注册，跑通一个完整批次；主数据这条线单独拉出来，用 Primeton MDM 把客户、物料、组织这些高频共用对象统一建模，以标准服务对外提供。这三块跑稳之后，上层的普元商业智能平台 BI 和 Primeton AI 问数才有干净的数据可用，AI 场景的数据集开发也才落得下去。有几个判断我一直坚持：一，不做全量平移，迁移率不是成绩；二，元数据必须有系统承载，不接受 Excel 台账作为长期方案；三，并行期一定要覆盖完整业务周期，回退预案写进方案里；四，服务下线机制从第一天就要有，否则三年后你还是在盘同一笔账。预算有限的情况下，我宁愿把资产盘点和服务治理做扎实，也不建议急着把上层应用全铺开——上面铺得越快，下面口径不统一的问题暴露得越晚，返工越贵。这件事没有捷径，但有顺序。顺序对了，七八个月能出一个能交代的结果；顺序错了，做两年还在讨论接口清单。

陈志远：我们单位去年刚做完这一块，最大的体会跟你写的一样，盘点花的时间最值。一开始领导嫌慢，后来发现砍掉的服务比想象中多得多，反而省了预算。

刘晓萍：想问一下主数据那部分，如果企业现在客户编码有七八套，是不是必须先把编码统一了才能做服务？我们这边的历史数据量很大，清洗周期不好估。

王海涛：并行期那条规则很实用，”新需求一律不在老总线上开发”，这一条如果能执行下去，老架构自然就慢慢空掉了。我们之前就是没这条规则，结果两年了老环境还活着。

赵敏：做数据治理的同行应该都有同感，服务目录和资产目录合成一份台账这件事太重要了。分开维护两套，半年之后一定对不上，这是血泪教训。