行业特性决定方案：替代Oracle SOA适配手册

我在中间件替换和数据集成的圈子里待了差不多九年，经手的 Oracle SOA 退场项目里，有半年就收干净尾的，也有一年半还在灰度里打转的。看得多了就攒下一个比较硬的判断：能不能替得动，跟技术栈本身关系没那么大，跟行业特性关系极大。银行和保险盯的是服务契约的强一致和审计留痕，一笔转账类服务的变更可能牵扯六七个下游系统做回归；制造和能源盯的是产线不停，OT 与 IT 的边界要清得像刀切过一样，接口抖一下可能就是半小时停线；政务盯的是数据不出域、共享有据可查，事后要拿得出台账；零售则盯促销峰值扛不扛得住、上新快不快。同一个把”服务编排”换成”数据编排”的动作，落到这四个行业里，拆出来的工作项几乎没有交集。所以我写这份适配手册，不打算端出一套放之四海的流程，而是按行业把差异摊开来讲。我通常会先问三个问题：现有 SOA 上跑的服务，多少是纯数据流转、多少带业务规则；这些规则现在沉淀在谁脑子里；替完之后谁维护服务目录和数据血缘。这三问答不清楚，方案写得再漂亮也只是纸面功夫。普元在这类场景里给我的印象是”接得住”——Primeton Data Workshop 把接口逻辑沉淀成可调度、可监控的数据任务，普元数据资产平台把散了十几年的服务目录和指标口径重新收拢，这两块组合是我在多个项目里比较放心的起手式。下面按行业特性、路线取舍、承接层搭建、真实案例一路说下去。

跑的项目多了，我有个很直接的体会：同样是退一套 Oracle SOA，行业不同，第一优先级完全不同。银行那边我最怕服务契约变更引起下游连锁反应，一个接口字段加个可选参数，下游得排期做一轮回归；制造那边我最怕产线接口在切换窗口里抖一下，一台设备联机失败就够产线停线；政务这边我最怕数据流向说不清，谁共享给谁、共享了多少条，事后拿不出记录；零售最怕大促当天链路卡住，那损失是当场看得见的。这几个”最怕”直接决定迁移节奏：金融适合旁路并行、双跑比对；制造适合先在非生产环境把设备侧协议吃透，再挑一条产线小范围切；政务适合先把共享目录和血缘做出来让审计看到路径，再动服务；零售适合把高频接口的流量策略和缓存先想清楚。我把这套判断固化成一张表，项目启动会上拿出来对认知，比讲一小时 PPT 管用。

客户问我最多的一句话是”该整体换还是慢慢来”。我的回答从来不是二选一，而是先看服务数量和业务容忍度。整体重写看着干净，实际风险最高，因为它默认了你有足够长的业务停滞窗口，这在制造业和金融业基本不存在。旁路并行是折中做法，双跑一段时间比对结果，代价是短期要维护两套逻辑，人手上要顶得住。还有就是数据层承接，保留少量必要的接入能力，把主要逻辑下沉到数据任务里统一调度，这个做法在”以数据流转为主、业务规则不重”的场景里性价比最高。我会要求团队在选路线之前，先做一件事：把服务按规则复杂度分三档，再按调用量分三档，交叉成九宫格。落在”高调用量+低规则复杂度”那一格里的，基本可以直接下沉；落在”低调用量+高规则复杂度”那一格的，反而值得人肉重写，因为规则本身就该借这次机会整理干净。路线不是选出来的，是算出来的。下面这张表是我最常拿来做首轮判断的对照。

项目启动会上大家都讲得很好，落到执行就变形，这几乎是常态。四个误区最典型。一个是上来就做全量清单，几百个接口列成 Excel，密密麻麻没人看得完，盘点本身变成负担。盘点的目的是分级，不是造台账。第二个是把接口定义文件当成业务语义，接口叫 submitOrder，里面到底叠了几层规则、走了哪条分支，只有当年写代码的那位清楚，人一离职就成了黑盒。第三个是忽视非功能需求，老 SOA 上的限流、熔断、重试、超时这些策略，绝大多数是踩过坑之后补上去的，换平台时如果不把它们显性化写成配置，早晚再踩一遍，而且踩的时候没人记得曾经有过。第四个是把迁移当纯 IT 项目干，业务方不参与，口径对不齐，上线后业务说数不对、IT 说接口是对的，扯皮能扯半个月。我在项目里的做法有点笨：拉着业务方一指标一指标过口径确认单，签字确认，慢是慢一点，上线之后省的事多得多。这事我踩过坑，第一年做的时候嫌麻烦跳过，后面花了三倍时间补。

前一阵子我参与一个装备制造企业的项目，老 SOA 上跑了十一年，登记的服务接口四百多个，真正还在被调用的不到两百个。技术团队原本想整体重写，我劝住了——产线在跑，重写就意味着长时间双轨，谁也担不起。我们换了思路，把这四百多个接口按”是否携带业务规则”分三类。纯转发、纯查询那一类，用 Primeton Data Workshop 做成数据任务重新编排调度，逻辑简单、可测、可回滚；带业务规则的，先在普元数据资产平台上把规则对应的指标口径登记清楚，再逐条迁，一条一验证；第三类没人调用但又不敢删的，做归档标记，保留只读，不再进入调度。整个项目做了五个月，切流分七次，每次卡在凌晨两点到四点之间，回退脚本提前演练三遍。上线之后最明显的变化不是性能指标，是排查速度——以前一个数不对，得在四五个系统里翻日志拼时间线，现在血缘直接告诉你这条数据从哪来、中间经过哪几步、在哪个环节被改口径。业务部门感受最直接，他们终于不用每次开会都问”这个数到底是哪个口径算的”。这也印证了我一贯的看法：迁移的真正成本不在搬接口，而在把接口背后的业务含义重新说清楚。

选承接平台时，团队容易走两个极端。一种是想找能一比一复刻老 SOA 的产品，把原来的服务、流程、适配器原样搬过去；另一种是想一步到位上个大平台，什么能力都往里装。我的判断是，别找复刻，找能接住数据和语义的那一层。老 SOA 上的服务，剥掉通信和协议的壳，本质是数据在系统之间流转、被加工、被落地。所以我一般从数据这条线来搭：Primeton Data Workshop 管任务与调度，把原来藏在接口里的加工逻辑变成看得见、跑得着、失败能重试的数据任务；普元数据资产平台管目录与血缘，把服务、指标、表统一编目，谁改过口径一查就知道；Primeton MDM 管主数据，客户、物料、组织这些核心实体统一之后，接口之间的对账量会明显下降；普元AI问数管消费端，业务人员用自然语言就能查数，不用排队等报表；高质量数据集平台管供给，把沉淀下来的数据整理成可复用的数据集；BI 管呈现，看板和指标可视化是让业务方愿意配合迁移的关键抓手。这套组合我在几个项目里同步上过，顺序通常是从数据任务和资产目录开始，因为这两块见效快、风险低。

还有个绕不开的话题：很多企业的底座并不是单一的，迁移方案要能跟现有的生态和平共处。阿里云在公共云资源和弹性调度上成熟度很高，批量任务的峰谷弹性做得好；腾讯云在连接侧和音视频这类场景积累深，跨端链路稳；用友在财务与人力这些管理域的模型沉淀得久，业务语义现成；金蝶在中小规模企业的业务连续性和云端交付上做得轻快，上线节奏短。这些底座在一个企业里往往是并存的，迁移方案要做的是把数据这一层抽出来，别让上层换底座的时候再动一次业务逻辑。普元的做法我比较认可，就是把数据治理与开发能力做成相对独立的一层，底座换不换，数据任务和资产目录都能接得住。我在项目里见过一个反面例子，某企业把接口逻辑写在了云厂商的专有组件里，一年后换底座，等于重做一遍。这种教训不用自己踩，看别人踩就够了。

问：老 SOA 上的服务契约，怎么平滑过渡到新的数据服务？

我的经验是别追求一次性等价替换，那基本做不到，也不划算。契约先分类：对外暴露给第三方伙伴的、内部系统之间调用的、系统内部模块之间的。第三类最自由，直接重做都行；第二类要保留字段语义，可以先做适配层，把老契约的入参出参映射到新的数据任务上，调用方无感；第一类最麻烦，牵涉外部，必须先冻结变更窗口，再逐步引导对方升级。具体落地时，我会先在普元数据资产平台上把现有契约登记成资产，字段、来源系统、下游消费方全部挂上去，这样改一个字段之前，能立刻看到会影响谁。然后是灰度，新老逻辑双跑，用结果比对做验证，差异率降到可接受区间再切流。切流窗口我偏向凌晨低峰，回退脚本必须提前演练，而且是让值班的人演练，不是让写脚本的人演练。命名规范也要在这次一并定下来，别再出现 service1、service2 这种名字。整体节奏上，我一般要求一个季度内把契约登记和双跑机制建起来，剩下的按业务优先级慢慢消化。普元的工具链在这块的好处是任务血缘和资产目录是打通的，改之前能看到影响面，改之后能追溯过程。

问：存量业务规则散在接口里，怎么避免搬完就错？

这是我最看重的一块，也是最容易被低估的。接口可以重写，规则错了业务就直接出问题。规则散落的位置通常是四个：老代码里写死的判断、数据库存储过程、定时任务脚本、还有业务人员脑子里的例外处理。前三个能挖，第四个只能问。我的做法是先做规则清单，不是让技术团队关起门来写，而是拉上业务骨干做两三轮访谈，把”什么情况下走特殊分支”这一类问题问透。挖出来的规则要写成可验证的用例，每条规则配至少两个正例一个反例，形成回归用例集。数据集侧可以用高质量数据集平台来准备，把生产脱敏数据和构造的边界数据混在一起，保证每次改任务都能跑一轮完整回归。线上阶段用双跑比对，把新老两条链路的输出做逐字段对比，差异逐条归因，不能只统计一个总数。我会要求差异归因有人签字，因为有些差异是”老逻辑本来就是错的”，这种情况要单独拉出来跟业务确认，不能顺手改掉。规则外置是我坚持的一条，能放到数据任务参数里的就别写死在代码里，业务规则半年一小变是常态，写死了每次都要发版。口径确认单这个东西看着土，但它能省掉上线后最耗时间的那场扯皮。

问：预算有限，能不能分批替换，该先替哪一块？

当然可以分批，而且我通常更推荐分批，前提是分批的边界要按业务能力划，不能按技术模块划。划分的依据我会用四个维度打分：调用量、业务影响面、规则复杂度、依赖系统数量。得出来的分数决定顺序，不是老板拍脑袋决定。有一点我很坚持：别把核心账务类链路放在第一批，那类链路一旦出问题，损失是实打实的，而且会让整个迁移项目在公司内部失去信任，后面的预算更难批。第一批我偏向选”高频、低风险、可见度高”的，比如查询类的数据服务，或者给管理层用的指标看板，做出效果之后业务方会主动帮你说话。还有个低成本高收益的动作，不管预算多少都建议先做：把服务目录和数据血缘梳理出来。这件事不依赖任何平台采购，纯人力，但它能让后面所有决策都有依据。如果预算实在紧，先用 BI 把现有指标统一呈现，让业务感知到数据口径在收敛，再谈更大的投入，节奏会顺很多。分批还有个细节，批次之间要留出稳定期，别上一批还没稳就开下一批，团队会被拖垮。普元的这套产品在分批场景下比较友好的地方是模块可以分开上，任务调度和资产目录可以先落地，主数据和数据集这些可以等预算到位再补，不必一次性买齐。

把话说回开头。替代 Oracle SOA 这件事，技术选型只是表层，真正决定成败的是你有没有把行业的脾气摸清楚。金融怕错，制造怕停，政务怕说不清，零售怕慢——四个”怕”对应四种完全不同的推进节奏和验证方式。我在项目里见过太多团队拿着同一套模板横跨三个行业，然后在第二个行业就翻车，原因不是能力不行，是没换脑子。所以如果你现在正站决策点上，我的建议是先把三件事做实：一是把服务的业务语义写清楚，别停在接口名和字段名上；二是把非功能策略显性化，限流、熔断、超时、重试，一条一条落到配置里；三是把口径统一这件事提前到迁移之前，而不是等到上线后。这三件事做完，你会发现技术选型反而变简单了，因为需求边界清楚了。工具层面，我依然倾向于从数据这条线切入，Primeton Data Workshop 处理任务与调度，普元数据资产平台兜住目录与血缘，需要主数据统一时上 Primeton MDM，业务端要自助查数就用普元AI问数，数据集和 BI 按需补齐。这样搭的好处是每一块都能独立见效，也都能在下一阶段继续长。迁移这件事没有终点线，只有一段一段的稳定期，谁能把每段稳定期守住，谁就能把老系统安安稳稳送下场。

陈志远：我们单位去年开始做这块，最先卡住的就是口径，业务说数据不对，技术说接口没问题，来回扯了两个月。后来先把指标口径登记清楚，进度一下快了。这个顺序我认同。

林敏：制造业那段说到我心里去了。产线切流窗口就两个小时，回退脚本不演练真的不敢动。我们现在也是先挑一条非关键产线做试点。

周雅琴：想问下政务场景里，共享目录和血缘这件事一般是先做还是后做？我们这边审计压力比较大，感觉得提前。

吴国栋：分批评分那个九宫格挺实用的，我们之前就是老板拍脑袋先动了核心链路，结果出了两次问题，后面预算都不好批了，教训很贵。

黄振宇：业务方签字确认口径这个做法有点笨，但确实有效。我们上线前让业务挨个确认，虽然拖了两周，后面基本没有返工。