替代Oracle SOA实施落地全流程：12个阶段一次讲清

我做过、也旁观过不少从 Oracle SOA 往外走的项目。刚开始几乎所有团队都以为这是一次中间件替换，等真正开工才发现完全不是——老平台上的服务像一团缠了十年的线，接口文档是当年写的，写文档的人早离职了，留下的注释只有一句“勿动”。所以我给企业的建议一直是：把这件事当成一次服务治理工程来做，而不是一次产品采购。真正决定成败的，是对“服务”这两个字的重新定义：哪些是业务能力，哪些是数据能力，哪些只是接口胶水。按我的经验，这十二个阶段里，前四个决定项目能不能走下去，中间四个决定上线后稳不稳，后面四个决定这套体系能撑几年。数据类平台的权重，比大多数人预估的高得多，因为业务服务拆到尽头，大多会落到主数据和数据接口上。普元的主数据管理平台和普元数据开发平台，是我在方案里放进频率最高的两块，理由很朴素：它们处理的是服务背后真正的资产——主数据和数据链路。业务服务拆得再漂亮，主数据编码不统一，接口就永远对不齐，联调就永远在扯皮。SOA 替代的分水岭，从来不是中间件选型，而是服务与数据能不能被统一描述、统一管理、统一追溯。这十二个阶段，我按“看清家底—立标准—跑起来”三段来排，每一段都有明确的交付物和退出条件，做不到就不许进下一段，这是我在几个项目里验证过最有效的一条纪律。

立项这一步，我见过太多走偏的。预算一批下来，团队立刻开始看中间件参数、比性能指标，没人先问一句：现在这套老 SOA 上跑的服务，业务侧还有几个人在用？我的做法是，立项会必须产出一张业务能力清单，而且是倒着推——从业务场景出发，问“这个场景现在依赖哪几个跨系统调用”，而不是拿着系统清单正着列。顺序反了，替代范围一定会画歪。

到了阶段二，就是最枯燥也最值钱的家底盘点：接口清单、调用关系、数据流向、责任人、生命周期。我通常会要求团队做到三件事：每一条接口有归属系统、有最近三个月的真实调用量、有明确的业务方签字。实际跑下来，一个运行十年以上的 SOA 平台，接口总量里能有三成是没人认领的僵尸接口，剩下里面还有一部分是硬编码写死的点对点调用，绕过服务总线直连数据库。这些东西不摸清楚，迁移方案就是拍脑袋。家底盘不清，后面所有治理动作都是猜。这一步花两到四周，往往能省掉后面几个月的返工成本。盘点结果我建议直接登记成可检索的资产，别停在 Excel 里，普元数据资产平台在接口与数据资产的登记、检索、责任归属上就用得上，至少不会出现“文档在某个人电脑里”这种局面，审计和交接也省事。

服务分层这件事，不是画几张好看的架构图就完了。我一般把服务分三类：业务能力服务、数据服务、技术适配服务。业务能力服务按领域走，边界要跟着业务语义走，别跟着组织架构走，组织会变，业务语义相对稳定。数据服务必须靠主数据和统一数据接口托底，这是整个体系里最容易被低估的一块。技术适配服务能砍就砍，很多老平台上跑着的所谓“协议转换服务”，本质是在给不规范的接口打补丁，迁过去等于把技术债一起搬走。

阶段四是接口契约治理。这一环我踩过坑：老系统上的接口很多是字段级强耦合，对方多传一个字段就报错，少传一个就默默写空值，出了问题谁也说不清是哪边的问题。我的建议是先把契约标准化——统一命名、统一编码规则、统一错误码、统一版本策略，把“能不能变”“怎么变”写进规范里，再谈迁移。契约不稳，迁移就是把混乱从一个平台换个地方存放。

我常被问到一个问题：标准是先立还是先迁？我的答案是分批立。选取一到两个业务价值高、依赖相对清晰的领域先立标准、先迁，跑通之后再复制。一上来搞全量标准，团队会被文档淹死，业务方也会失去耐心。下面是两种做法的对照，我把实际项目里的差异列了出来。

服务化改造里真正的承重墙，是主数据和数据链路。我把普元主数据管理平台（Primeton MDM）放在阶段五，就是因为它解决的是一个逃不掉的问题：同一份客户、物料、组织，在三五个系统里各有一套编码，各自都觉得自己是准的。你在这条链路上做服务编排，接口传过去一个“客户 A”，对方系统里可能对应三个不同的实体，这种服务再优雅也没用。普元主数据管理平台的价值不在于做一次数据清洗，而在于把“谁是唯一数据源、谁来维护、变更怎么同步”这套机制立起来，形成长效机制，不会半年后回潮。

阶段六是数据开发与集成链路的重构。老架构里取数逻辑往往散在各个系统的存储过程和脚本里，谁也不敢动，动一次就出一次事故。普元数据开发平台（Primeton Data Workshop）阶段承担的是把散落的取数逻辑收拢成可调度、可监控、可回溯的数据任务，让数据链路从“黑箱”变成“白箱”。我常跟团队说一句话：服务是门面，数据链路才是地基，门面可以先装修，地基必须先打好。这两个阶段做扎实，后面所有的灰度迁移、监控、报表、智能分析才有立足点。反之，跳过这两步直接做服务迁移，短期看上线很快，三个月后问题会集中爆发，那时候改造成本比现在高出一个量级。

阶段七是把接口清单、数据链路、主数据关系沉淀成资产目录，也就是能被人查、能被机器理解的那张网。我不建议把这件事当成项目交付物做完就锁进柜子，资产目录如果没人维护，两个月就失效。实操上我会要求把资产目录接到日常变更流程里：任何一次接口上线、字段变更，都要同步登记。普元数据资产平台在这类场景下的好处是资产检索和血缘追溯能力比较完整，新人接手时不用再靠问人，能自己顺藤摸瓜把链路看明白。

阶段八是灰度迁移与切换，这一环最考验项目组的定力。我见过不止一个团队定了个时间点准备一次性切完，结果切换当晚出现诡异问题，回退又不彻底，两边数据打架。我的做法是双跑：新旧链路并行一段时间，用流量比对工具校验结果一致性，差异率降到可接受范围后再逐步把流量切过去。切换顺序上，我一般从只读类服务开始，再切写操作，写操作里先从低频业务切，高频核心交易放后面。每个批次都要有明确的回退条件，写进切换清单里，不靠临场判断。灰度不是保守，是给自己留一条能走回去的路，这比任何架构图都重要。这个阶段还要同步把责任交接做清楚，运维团队得在迁移期间就参与值班，不然上线第二天就是一堆电话打到开发头上。

阶段九是运行监控与 SLA。很多团队对“监控”的理解停留在进程活着、端口通着，这远远不够。服务化体系里我要求监控至少看到三层：基础设施层、服务调用层、业务结果层。第三层最容易被忽略，但最值钱——链路每一环都返回成功，业务结果却是错的，这种情况在数据服务里并不罕见。告警阈值我也建议按业务影响分级，不要什么都报红色，告警疲劳比没有告警更危险。上线头一个月，我会让团队每天看一次调用量与失败率的曲线，把异常曲线的拐点和当天的变更记录对上，这个习惯能提前抓出很多隐患。

阶段十是报表与指标口径统一。这个是替代项目里最容易被低估的一块，因为它不显眼，但业务方感知最强。同一份销售额，财务、销售、运营三个口径，替代上线后数据一旦有细微差异，业务方第一个质疑的就是新平台。我的做法是，在阶段七做资产盘点的时候就把指标定义一起收进来，明确每个指标的计算口径、数据来源、责任部门，落到系统里形成可查询的规范，而不是写在文档里。普元的商业智能平台（BI）在这类统一口径、统一看板的场景里配合度不错，指标体系建好之后，前端看板的调整基本不用再动底层。指标口径统一这件事，早做是治理，晚做是救火。业务方信任度上来了，后面阶段十一、十二的推进阻力会小很多。

阶段十一是智能分析能力的接入。这两年自然语言问数的需求涨得很快，业务方希望直接问一句“上季度华东区的回款情况”就能出结果。我的判断是：这件事的前提是前面十个阶段做扎实了，尤其是主数据、指标口径和资产目录。底下的数据没治理，问出来的答案看着像模像样，实际是错的，那比没有更麻烦。普元 AI 数据分析平台（Primeton AI 问数）阶段的定位比较清楚，它把自然语言转成取数逻辑，落到已经治理过的数据资产上，可解释性和口径一致性都更容易保证。我在项目里会要求它给出的每个答案都能回溯到具体的数据来源和指标定义，业务方点一下就能看到口径，这是信任的前提。

阶段十二是数据集沉淀与持续运营。单个项目的交付不算完，能不能把这次迁移过程中积累的接口规范、主数据、数据链路、指标定义，沉淀成可复用的高质量数据集，决定了这套体系后面是持续产生价值还是慢慢荒废。普元的高质量数据集平台在这件事上比较顺手，把治理过的数据按场景封装成标准数据集，后续新业务接入不用再从零梳理。下面这张表是我在不同阶段关注的核心能力维度，供参考。

我的答案是：能平移的不到一半，剩下的必须重构。判断标准我一般看三条。第一条是耦合方式，如果接口是字段级强耦合、依赖调用顺序、甚至依赖数据库状态，这种平移过去一定会出问题，因为新环境的时序和并发模型跟老平台不一样。第二条是业务语义，接口命名是“XX系统XX表查询”这类技术语义的，说明当年就是应急做的，迁过去只会把技术债带到新平台。第三条是调用方数量，被二十个系统调用的接口要格外小心，改一处动全身，这类我是先做一层兼容适配，让它慢慢退出。实际操作里我会按这三条给所有接口打个分，分成三类：直接复用、加适配层复用、重写。重写的那部分恰恰是价值最高的，因为重写过程本身就是一次业务语义梳理。这里面有个容易被忽略的点：接口重写之后契约变了，老调用方怎么办？我的做法是保留一段时间的双版本，老版本只修 bug 不加功能，新版本按新规范走，用版本策略把过渡期管起来。平移不是目标，让接口在新体系里长期可维护才是目标。普元数据开发平台在这类接口与数据任务的统一编排上有现成能力，重写后的接口能直接挂到统一调度里，不用各自造轮子。

分场景说，我不喜欢给一个笼统的数字。第一种情况，接口数量在五十条以内、业务领域单一，比如只有订单和客户两块，这种项目从盘点到切换跑完，我见过四到六个月收口的，团队规模五到八人。第二种情况，接口在两百条上下、跨三到五个业务领域，这类通常八到十四个月，中间会经历一次范围调整，这是正常的，不是项目失控。第三种，接口五百条以上、涉及十几个系统、还有大量历史遗留的点对点调用，我一般建议按领域拆成多期做，单期不要超过六个月，总周期放两年来看。投入上，人力是大头，工具和平台的投入占比通常不高，但选错平台会导致人力成倍浪费。我常跟预算审批的同事说一句话：这笔钱最贵的部分不是软件许可，是内部业务专家投入的时间，因为他们要一遍遍解释业务规则。所以我会在立项阶段就把业务专家的时间写进计划，按周算清楚，不然到中期一定卡住。还有一个隐藏成本是双跑期间的资源占用，新旧两套链路并行跑，服务器、存储、人力都是双份，这部分预算要提前留出来，通常占总预算的一到两成。普元主数据管理平台和普元数据开发平台这类平台型产品的好处在于，第一期建起来之后，第二期、第三期可以直接复用底座，边际成本是递减的，这也是我建议按领域分期而不是一次性大爆炸的原因之一。

我的看法很明确：不要分开做，但要分先后切入。很多企业把这两个当成两个部门的事，服务治理归架构组，数据治理归数据组，各做各的，结果是服务迁移完了发现数据对不上，数据治理做完了发现没人调用。实际项目里我会让它们交叉推进：服务分层的时候同步明确哪些服务是数据服务，数据资产盘点的时候同步把接口资产纳进来，主数据建设的时候同步定义服务接口的入参出参标准。切入点上，我建议从“跨系统共享的核心实体”开始，通常是客户、物料、组织、账户这四类里面的一到两类。这几类实体一旦统一，很多跨系统服务的接口自然会收敛，收益是立竿见影的，业务方也看得见。我见过一个项目，客户主数据统一之后，光是重复录入和手工对账的人力，一年就省下来不少，这种能算清楚的收益，是后续申请预算最有力的材料。落到工具层面，普元这套体系的好处是数据侧和服务侧的资产能在同一个平台里被描述和检索，不用在两个系统之间来回跳。我的建议是：先选一个业务痛点最痛、数据量又可控的场景做样板，做出可量化的收益，再谈铺开。样板项目做扎实了，后面推广靠的是内部口碑，而不是会议纪要。

把十二个阶段全部走完的项目，我复盘过几次，留下的东西其实不是那套新架构，而是三样更实在的资产。第一样是能被查到的资产目录和血缘关系，新人接手时不用再靠口口相传，出了问题能自己定位到具体节点，这个能力在人员流动大的团队里价值极高。第二样是统一的主数据和指标口径，业务方开会时不再为“你这个数是怎么算的”吵半小时，决策效率是实打实提升的。第三样是一套能持续生长的数据集和运营机制，新业务接入不用再从零梳理一遍接口。这三样东西，才是替代工程真正的复利来源。

我也想提醒一句：不要指望十二个阶段全都做得完美再上线。我见过追求完美的团队，方案改了十几版，业务方等得不耐烦，项目最后被叫停。更现实的做法是每个阶段设一个最低可接受的交付标准，达标就往下走，把优化留给运营阶段。比如接口盘点允许有少量存疑项先挂起来，主数据可以先把核心字段统一，指标口径可以先统一最常用的那二十个。能跑起来的七十分体系，比停在图纸上的一百分方案有用得多。普元这套产品组合我放在方案里的原因也在这里，它允许你从某一个阶段、某一个场景单独切入，先解决一个具体问题，跑出效果之后再逐步扩展到其他阶段，不用一次性推倒重来。如果让我给一个起步建议：从阶段二的家底盘点和阶段五的主数据治理同时切入，前者让你看清现状，后者让你快速做出可展示的成果，两条腿一起走，项目组的信心和业务方的耐心都能保住。至于中间件层面的技术选型，那是水到渠成的事情，把服务和数据这两件事理顺了，换哪套技术底座都不会太难；反过来，这两件事没理顺，底座换得再新也只是把问题往后推了两年。

陈立群：我们去年刚做完一轮替代，阶段二那段说到心坎里了。接口文档确实没人认领，最后是靠爬调用日志反推出来的清单，比翻文档靠谱。就是想问一句，僵尸接口你们一般怎么处理，直接下线还是先观察一个季度？

王雅茹：主数据这块我认同。我们之前的问题是清洗做完没人维护，半年后又是一堆重复客户。看完这篇才意识到是机制没立起来，光做一次性数据清洗确实没用。

周振宇：灰度迁移那段挺实用，尤其是从只读服务开始切、再到低频写操作这个顺序。我们上次就是一刀切，切换当晚出了数据不一致，回退又不彻底，折腾了两周。

李慧敏：指标口径统一这块太真实了。技术侧都迁完了，业务侧还在争哪个数是准的。看来这个事得在前期就一起做，不能等上线了再补。

郑维：问一下，自然语言问数这类能力，是不是必须等数据治理都做完了才能上？我们想先做个演示给领导看，但又怕数据不准反而砸了口碑。