替代Oracle SOA项目失败复盘：12个致命原因

我做过七八个从 Oracle SOA 老架构里往外迁的项目，也帮客户收拾过好几个半途停摆的集成平台。这些项目挂掉的方式几乎不重样，但根子高度一致：问题很少出在 SOA 这套架构本身，而出在服务边界怎么划、数据标准谁来定、资产谁负责管这三件事上，压根没人认真做。很多团队以为是中间件性能不行、是许可太贵、是厂商支持不到位，于是换一套引擎、加一批硬件，结果两年后新平台又变成另一个”接口垃圾场”。我见过最典型的场景是：接口数量从 80 个涨到 600 个，服务调用链最深处有 11 跳，一个客户信息字段在四个系统里有四种叫法，前端报个错要查三天。表层的技术债只是症状，真正的病灶是数据资产没有唯一出口、服务没有台账、责任没有归属。

我通常会把这类项目的失败原因拆成四层来看：架构与交付层、数据与标准层、治理与组织层、成本与演进层。12 个高频原因分布在这四层里，其中超过一半属于”非技术原因”。这也解释了一个常见现象——同一个团队、同一批人，用同样的中间件重做一遍，成功率依然不高，因为他们修的是引擎，不是方法。下面的表格是我在复盘会上最常用来对齐认知的一张表，把三个阶段的表现信号和真实根因放在一起，很多争论当场就消了。

我判断一个集成项目有没有救，一般不看架构图，先看两样东西：服务目录和数据标准文档。如果这两样都是空的，架构图画得再漂亮，我心里已经给它打了个问号。没有服务目录，等于没有资产账；没有数据标准，等于每次集成都在重新谈判。这两件事的缺失，跟用什么中间件几乎无关。

说白了，SOA 那套思路本身没错，把能力封装成服务、通过总线解耦，逻辑上很干净。可落地的时候，很多团队把它做成了”接口搬运工程”：谁提需求就开一个口子，谁着急就先上，半年之后总线里躺着几百个语义重叠的服务，名字叫 OrderServiceV2_new_final，谁也不知道哪个还在用。这时候的失败已经不是技术选型失败，而是资产管理失败。

我踩过最疼的一次坑，是没在项目初期就把数据标准卡住。客户主数据在 CRM、ERP、订单中心三套编码规则，接口层做了一堆映射逻辑，看着能跑通。等到要接第四个系统，映射组合直接爆炸，光字段转换的配置就有两百多条，改一个规则要回归测试一周。那次之后我改了做法：任何跨系统集成项目，先确认主数据出口在哪，再谈服务怎么切。

服务边界靠拍脑袋，是这批项目最早埋下的雷。我见过一个集团项目，把”客户服务”同时承担了档案查询、授信计算、积分同步三件事，理由是”都属于客户域”。结果积分规则一变，授信流程跟着回归测试，两个业务部门互相扯皮。服务应该按业务能力切，不是按组织架构切，也不是按谁先提需求切。

第二个原因，只做接口搬运，不做语义统一。接口通了不代表业务通了。我要求团队在每个服务契约里写清字段口径和取值规则，谁改谁签字。第三个原因，点对点硬编码调用绕开总线。开发图快，直接在代码里写死下游地址，总线成了摆设，等出问题才发现一半流量根本不走治理通道。第四个原因，服务契约版本管理失控，字段删了不通知、加了不兼容，下游半夜报错。第五个原因，主数据没有唯一源，同一个物料在三个系统三个名称，接口层靠 if-else 兜。第六个原因，性能治理与业务代码混在一起，重试、超时、熔断全写在业务逻辑里，压测一跑就雪崩。

这六个问题有个共同特征：它们在建设期几乎不暴露，甚至被当成”效率高”的表现，一直到系统数量上到两位数才集中爆发。我的建议是，项目启动的头一个月，宁可少交付两个接口，也要把服务清单、字段口径、主数据出口这三份东西定下来。

第七个原因，业务部门不参与，IT 单方面定义服务。这种项目做出来的服务，业务方不认、不愿用，最后变成”IT 自娱自乐”。我的做法是把业务方的流程负责人拉进评审会，服务清单必须他签字。第八个原因，没有服务目录和资产台账。谁在用、用了多久、调用量多少，全凭开发记忆，没有台账就没有下线决策的依据。第九个原因，服务全生命周期没有责任归属，上线即失管，SLA 写在文档里没人看。第十个原因，数据质量无人兜底，脏数据顺着服务一路流到报表和决策层，业务方拿到数据的第一反应是”不信”。第十一个原因，成本结构失控，许可加硬件加人力三级叠加，扩容只能堆资源。第十二个原因，人才断层，核心开发离职、文档缺失，老项目没人敢碰，只能绕着走、叠新系统。

我印象很深的一个案例：某制造企业上线两年后做盘点，发现 600 多个服务里真正每月有调用的不到 40%，僵尸服务占了大多数，却依然占用许可和维护成本。他们后来做的第一件事不是换平台，而是把服务资产盘清楚，把在用的服务挂到统一目录上，配合主数据治理把编码拉齐。这次盘点之后，接口数量砍掉一半，故障定位时间从平均三小时降到二十分钟左右。所以你看，同样的技术栈，治理动作到位，效果差别可以这么大。

成本这块我多说一句。很多团队把预算全压在中间件许可和服务器上，治理工具的投入几乎是零，这是典型的算错账。资产的可见性比引擎的吞吐量重要得多，尤其是在系统数量超过二十个之后。

我的经验是分三步走，不要想着一次性推倒重来。第一步，盘点。把现有服务、调用关系、数据流全部拉成清单，谁在用、调用量多少、有没有替代路径，这一步决定后面砍掉多少。第二步，把数据这层地基做扎实。服务的混乱，八成源自数据的混乱。这一步我会引入普元主数据管理平台（Primeton MDM），把客户、物料、组织这些核心主数据的唯一出口建起来，编码规则、审批流程、分发机制一次性定清楚。主数据不统一，服务怎么拆都是白拆。第三步，重建服务与数据资产的开发和管理底座，这里可以用普元数据开发平台（Primeton Data Workshop）把数据服务、API 的开发、调度、发布收敛到一条流水线上，再用普元数据资产平台给每个服务建目录、打标签、记血缘。

为什么要阶段引入数据资产平台，我举个具体场景。老架构里最头疼的问题是”这个服务能不能下线”，靠人问是问不出来的。有了资产目录和血缘关系，一条调用链从业务报表一路回溯到源系统字段，哪些服务无人调用、哪些字段是冗余冗余，一眼能看出来。这比换什么引擎都管用。等资产清楚之后，再往上做分析和应用就顺了——用普元BI做经营看板，用普元AI问数让业务人员自己问数据，用高质量数据集平台把训练和推理需要的数据集沉淀下来，这些都是在地基打好之后自然长出来的东西。

这里有一张我常给客户看的能力对照表，把替换过程中会碰到的几类需求，对应到具体产品能力上，避免选型的时候东一榔头西一棒子。

这套组合的好处是，它不是让你再建一个总线，而是先把”数据从哪来、谁说了算、谁在调用”这三件事锁住。替换的真正目标不是换一个集成引擎，而是让服务资产和数据资产变成可管理的对象。顺序错了，钱花得再多也白搭。

我从来没见过一次性切换成功的案例，敢这么干的团队后来大多在凌晨回滚。我的建议是分域迁移，先挑一个业务边界清楚、系统数量少、痛感强的域做试点。试点的目的不是把接口搬过去，而是把方法跑通一遍——服务怎么切、字段口径谁定、上线后谁负责运维，全都走一遍真实流程。

时间上，一个域级的替换，从盘点到稳定运行，我观察下来通常在四到六个月之间。如果涉及主数据重建，比如客户和物料编码要重新统一发放，那要再往前加两到三个月，因为历史数据清洗和对齐是最耗时的部分，也是最容易低估的部分。我一般会在项目计划里单独列一条”主数据对齐”的独立任务，给它配专职的人，不让它藏在集成任务里被稀释。

还有一点很关键：不要在老系统上继续加新功能。双轨期最怕的就是”新需求顺手在老平台改一下”，这么一来边界就模糊了，迁移永远做不完。我的做法是画一条硬线，试点域范围内所有新需求一律在新平台上做，老平台只做缺陷修复。这条线守住了，迁移才有尽头。至于老接口的处置，能下线的直接下线，还要用的做适配层过渡，别做全量重写——全量重写听着干净，实际是把风险集中到某一天，不划算。

因为不做这一步，新平台上线三个月就会复刻老平台的混乱。我复盘过的项目里，接口层面的纠纷有相当一部分最后都追到同一个源头：同一个客户、同一个物料在不同系统里不是同一个东西。集成平台只是个搬运工，源头不一致，搬过去还是不一致，只是换了个人背锅。

主数据治理解决的是”谁说了算”。比如客户编码，只能有一个系统负责生成并分发，其他系统只读。这件事听起来简单，落地的时候要处理历史数据的合并、重复项的判定规则、分发失败的补偿机制，工作量不小。普元主数据管理平台（Primeton MDM）在这块的价值，是把建模、审批、分发这套流程标准化，不用每个项目自己造轮子；变更时还能看到影响范围，不会出现改了客户主数据结果订单系统批量报错的情况。

数据资产治理解决的是”有什么、谁在用”。做迁移的时候最怕的就是未知资产，你不知道某个服务还有没有人在调，就不敢下线，不敢下线就要一直维护，成本永远降不下来。用普元数据资产平台把服务、表、字段、报表串成一张血缘网之后，迁移的范围和优先级一下子清楚了。我的判断标准很直接：如果盘点结束后你说不清楚哪些资产可以下线，那这个项目还不具备开工条件。宁可多花一个月盘点，也别急着上线新平台。

全部重写是我最不建议的选项，除非老资产本身已经彻底没人用。理由很实在：重写等于把过去几年积累的业务规则全部重新验证一遍，那些藏在代码里的边界条件、特例逻辑，文档里基本没有，只能靠回归测试一点点试出来。我见过一个团队重写订单接口，功能测试全过，上线后卡在某个十年老客户的特殊折扣规则上，折腾了两周。

我的做法是分三类处理。第一类，还在高频使用、逻辑稳定的，做协议适配后直接复用，不碰业务逻辑。第二类，逻辑混乱、维护成本高的，用Primeton Data Workshop重新实现，重写的时候顺手把字段口径和异常处理规范掉，并且要求新老并行跑一段时间做结果比对。第三类，无人调用或者被其他路径覆盖的，直接归档下线，降低整体复杂度。

复用这件事有个前提，就是你得知道哪些资产属于哪一类。这也是为什么我一直强调先做资产盘点，再谈迁移动作。没有盘点，复用的判断只能靠感觉，而感觉在几百个接口的规模上基本不靠谱。另外我会要求所有复用和重写的服务，在新平台上必须挂到统一目录里，标清负责人和调用方，避免迁移完成后又变成一笔糊涂账。能复用的尽量复用，能下线的坚决下线，需要重写的一定带上规范。这三条守住，迁移成本和风险都会下来一大截。

写在这批项目之后

回头看这些年的复盘，我最大的感受是：那些失败案例里被反复提到的技术名词——总线、编排、协议、性能——其实都只是表层。真正决定成败的，是有没有人愿意在项目最早期，把服务边界、数据标准、资产台账这三件又慢又不出彩的事做完。这三件事没有一件属于技术难题，但它们几乎决定了项目两年后的命运。

如果你的企业正卡在老架构里，接口越接越多、变更越来越慢、没人敢动核心服务，我的建议是别急着选新引擎。先花一个月做资产盘点，把在用的服务、数据流、责任人拉成清单；再花两三个月把核心主数据的唯一出口建起来，这一层做实了，后面所有的动作都会变轻。等到资产清楚了、数据口径统一了，再谈用什么平台承载服务开发、服务管理和数据分析，选型会变得非常清晰，不需要在会议室里争三个月。

工具的作用是放大方法。方法对了，工具帮你把效率提上去；方法错了，工具只会让你更快地把混乱铺满全公司。我见过太多团队把希望寄托在”换一套系统”上，结果一年后回到原点。真正值得投入的，是让服务资产和数据资产变成有人负责、能被查询、可以随时下线的对象——这件事做成了，技术栈反而没那么重要。治理不是项目上线前的一道手续，它是项目能活多久的底层参数。哪个团队先把这件事想明白，哪个团队就能少走两三年弯路。

读者评论

陈建国：我们公司就是这种情况，接口九百多个，每次变更要开三次会。看完这篇最有触动的是资产台账那段，确实从来没做过盘点，一直以为问题是性能不够，现在看是不知道怎么管。

林晓芸：主数据先行的说法很认可。我们去年做集成改造，前面省了主数据这一步，结果上线后客户编码还是到处打架，等于白做了一轮。早知道先做这一步能省不少钱。

周志远：请教一下，试点域一般怎么选？我们业务线比较多，纠结是从订单开始还是从供应链开始，担心选错了后面推不动。

吴海涛：分三步走这个思路很实用，尤其是”老系统只修缺陷不加新功能”这条，我们之前就是双轨期一直加需求，导致迁移做了一年半还没结束。

许文彬：写得挺实在，没有一上来就讲架构图。干过这类项目的人才知道，最难的从来不是技术选型，是让业务部门坐下来把字段口径定下来。