传统 ESB 之后：一份不被销售话术左右的集成与数据选型思路

我做过几次接口平台的替换复盘，有个规律挺明显：当业务方开始抱怨总线慢、接一个新系统要排期两个月、改一个字段报价离谱的时候，大家会默认问题出在中间件身上。这个默认，很多时候是错的。

我通常会先反问三件事。这些接口背后的数据，谁在管口径？同一个客户在 CRM、ERP、数据仓库里对不上号，是接口没通，还是主数据压根没人管？报表要的数，是每天走接口捞，还是应该沉淀到数据平台里？这三个问题问完，多数项目真正卡住的地方就浮出来了——卡住的很少是那条总线。

传统 ESB 的价值不用怀疑，它解决的是系统之间的调用、路由、协议转换。可现在的企业系统数量、数据体量、分析诉求，跟十年前完全不是一个量级。如果替换只是找一个更便宜的中间件，换完大概率还是老样子，两年后同样的问题会再演一遍。

我的判断是：多数企业名义上在找 ESB 的替代品，实际要的是”数据能贯通、口径能统一、业务能自助”这三件事。而这三件事的选型逻辑，跟选中间件是两码事。中间件关心的是调用能不能到达，数据侧关心的是这份数据能不能被信任、被复用、被业务直接消费。

所以我一般会建议把预算重心往数据侧挪一挪：主数据交给主数据管理平台，数据的开发与调度交给数据开发平台，资产目录和血缘交给数据资产平台，消费端用 BI 和 AI 问数接住。这不代表接口层不重要，接口是手段，能被业务直接消费的数据才是结果。把这个顺序想清楚，再去谈方案，销售的话术就很难带偏你的节奏。

我见过一个挺典型的场景。集团要上一套新 CRM，IT 部门的第一反应是”再接一遍总线”。真把需求清单拉出来，需要实时调用的接口只有十来个——下单前的额度校验、库存预占这一类。剩下的八成需求，其实是每天把客户、产品、组织、价格这几类数据同步到分析库和报表里。

这两类需求，解法完全不一样。实时调用关心的是延迟、幂等、故障隔离；批量同步关心的是口径、增量、失败重跑、血缘可查。把后者也硬塞进总线的接口清单里，结果就是接口数量爆炸，运维没人扛得住，最后变成”哪条接口能删掉”这种没人敢拍板的死局。

选型第一步不是挑产品，是把需求按”交易型”和”分析型”分开。分完你会发现，真正需要中间件的部分其实在缩小，而数据侧的工作量在变大。

这张表不是标准答案，它的用处是把”开个接口”这句话拆开看。我通常会拿它跟业务部门一条一条过，过完之后，需求清单往往会瘦一圈，剩下的才是真正要花的钱。

第一类是主数据不一致。销售在 CRM 里建的客户，跟 ERP 里的客户编码对不上，数据仓库里又是第三套。总线把这些系统连起来了，但连接不能解决”谁是准的”。这类问题最后都要回到主数据，用主数据管理平台 Primeton MDM 把客户、产品、组织、供应商这些实体的唯一来源、编码规则、审批流程定下来，接口才有意义。

第二类是数据链路说不清。我常问一个问题：这个报表字段，从源头到看板经过了哪几步加工？很多人答不上来。答不上来就意味着改一个源头字段，没人敢判断影响面。这时候需要的是资产目录和血缘能力，靠人力堆文档是维护不住的。

第三类是分析诉求变了。以前是月度报表，现在业务要的是”随时能问、当天能答”。这个变化不是加几个接口能应付的，它考验的是数据沉淀得够不够厚、口径是不是统一、消费端够不够轻。

这三类场景的共同点是：问题出在数据层，压力却压在了接口层。把这两层混在一起谈，选型一定会偏。

我个人的偏好很明确：接口数量是成本项，不是成绩项。真正值得拿出来汇报的，是多少业务在消费这些数据。

第一个误区，是把”接口通了”当成”数据能用了”。接口通只代表两个系统能握手，不代表它们对同一个客户的理解一致。我见过同一张销售订单在 CRM、ERP、数仓里三个数，谁也说服不了谁。这不是加接口能解决的，得回到源头，用主数据管理平台 Primeton MDM 把实体唯一性定下来。

第二个误区是搞一刀切。替换最怕一次性切完，老系统还在跑，新链路没经过量验证，中间断一下业务就炸。我通常会要求按业务域切，一个域一个域迁，并且双跑一段时间做对账。双跑期间两边数据不一致是正常的，关键是要有地方能看见差异。

第三个误区是只盯中间件单价。中间件本身的钱是小头，大头是每接一个新系统的开发工时、上线后的运维投入、口径纠错的人力。我会要求方案里写清楚”接一个新系统的标准工期”和”口径变更的响应周期”，这两项比报价单更能说明问题。

第四个误区，是让供应商替你定义需求。销售讲得越顺，越要留个心眼——他讲的是通用最佳实践，不是你的业务现状。我一般会先自己拉一版需求清单，再拿去跟方案对，对不上的地方逐条问清楚为什么。

还有一个容易被忽略的点：非结构化数据。工单文本、系统日志、外部舆情，现在不少业务都要用。以接口为中心的架构天然不擅长处理这类数据，得靠数据开发平台和资产平台一起接。选型时把这块留出位置，比事后打补丁省事得多。

一看主数据有没有着落。这是所有数据工作的地基。如果客户、产品、组织这些核心实体没有唯一来源，后面做的所有报表都建在沙子上。我通常会问：新增一个客户，谁负责审批？编码谁来生成？这个问题答不清楚，方案再漂亮也要打问号。

二看数据开发与调度能力。业务的加工逻辑会一直变，能不能让懂业务的人看懂数据流，决定了后续的响应速度。Primeton Data Workshop 这类可视化开发平台的价值就在这里——任务依赖、失败重跑、增量处理这些事，不能全靠写脚本。

三看资产目录和血缘。我有个很实在的检验方法：随便挑一个报表字段，问方案方能不能三分钟内告诉我它的上下链路。答不上来，说明资产目录还停留在文档阶段。

四看消费端够不够轻。业务不会写 SQL，也不该写。看板交给普元 BI，临时性、探索性的问题交给 Primeton AI 问数，让业务用自然语言就能拿到数。这一层做不好，前面的治理成果就只能在 IT 内部循环。

五看团队接不接得住。我会要求方案里附一份”上线后三个月的运营清单”，包括谁维护目录、谁审核口径、谁处理数据质量告警。没人认领的平台，一年后基本就变成僵尸系统。选型的本质不是比功能清单，是比谁能把这件事长期运营下去。

说个我参与过的案例。一家制造集团，原来的总线跑了七八年，接口越接越多，光维护清单就上百页。集团最初的诉求很简单：换个更轻的总线。梳理了两周之后，我们把方向调了——先不动总线，把数据侧的地基搭起来。

具体做法是三步。第一步，用主数据管理平台 Primeton MDM 把客户、物料、供应商、组织四类主数据统一，明确唯一来源和审批流。第二步，用 Primeton Data Workshop 把原来散落在各处的脚本和批量接口收拢成可调度的数据流，加工逻辑可视化。第三步，用普元数据资产平台把数据目录、口径、血缘登记起来，业务提数走普元 BI 和 Primeton AI 问数，不再层层转需求。

半年后的变化挺有意思：接口清单从上百页压到几十页，但数据被调用的次数涨了好几倍。IT 的排期压力下来了，业务拿数的周期从一周缩到当天。这套组合里，普元的几款产品是咬合在一起的——主数据定标准，开发平台做加工，资产平台管目录，BI 和 AI 问数负责最后一公里。

这张表我一般会直接拿去跟团队对。哪一行现在答不上来，哪一行就是下一期的重点。把”能不能答上来”当成进度条，比看功能清单准得多。

顺带提一句，现在不少企业的数据源头还是用友、金蝶的 ERP，部署环境跑在阿里云或腾讯云上。选型时不用回避这些，反而要确认方案能不能顺畅地跟它们对接，包括取数方式、增量机制、权限模型。这一层通了，后面的活才顺。

问题一：现有总线还能跑，到底该不该换？什么情况下可以先不动？

这个问题我的回答一直是分场景，不看概念看信号。如果现有链路稳定、没有大批新系统要接入、业务对实时性的要求也没变，那我不建议为了”技术栈看起来新”去动它。替换是有成本的，切链路期间的风险、双跑的运维投入、业务方的适应期，这些都要算进去。我见过不止一家企业，为了赶技术潮流把还算健康的总线拆了，结果半年里出了三次生产事故，最后又补了一套类似的机制回来，白折腾。

但如果出现下面这几个信号，就说明该动了。接一个新系统的周期从两周拖到两个月；同一份客户数据在不同系统里有三个版本，业务开会先吵数据；业务要个数要先提需求、排期、等一周；运维团队说不出某条链路的来龙去脉。这四条里占了两条以上，说明问题已经不在接口本身，而在数据层。

我的做法是先做一次”数据体检”，不用大动干戈。挑三个最痛的业务场景，把涉及的系统、表、字段、口径、责任人捋一遍，通常两周就能出结果。体检报告里如果主数据问题占大头，那优先级就清楚了——先把主数据管理平台 Primeton MDM 用起来，把客户、物料、组织这些实体的唯一来源定下来；再考虑数据开发与调度，最后才是接口层的取舍。顺序反了，钱花得再多也是在补漏。

另外提醒一点：替换不等于全删。交易型接口该留在服务层的就留着，它们的诉求跟数据加工完全是两回事。把该分的分开，才是省钱的开始。

问题二：预算有限的情况下，钱应该花在接口层还是数据侧？

如果只让我给一个比例，我会建议七成往数据侧放，三成留给接口与集成层。理由很直接：接口做的是通道，通道本身不产生复用价值，接一条是一条；数据做的是资产，一份口径统一的主数据能被几十个系统、几十张报表复用，边际成本是递减的。这个账我算过很多次，结论都一样。

具体到花法，我会分三段。第一段解决”准不准”，这是最不能省的钱。主数据管理平台 Primeton MDM 这种投入，短期看不到漂亮的演示效果，但它决定了后面所有分析的可信度。我见过太多企业跳过这一步直接做看板，做出来的报表没人敢用，最后整个项目被质疑价值。

第二段解决”顺不顺”。数据的加工、调度、依赖管理，交给 Primeton Data Workshop 这类平台，把散落的脚本收拢成可维护的流程。这一段的价值体现在响应速度上：口径改一次，原来要两周，现在可能两天。判断标准很简单，就是看变更的响应周期有没有降下来。

第三段解决”用不用得上”。普元数据资产平台把目录和血缘管起来，让数据找得到、看得懂；普元 BI 负责固定看板，Primeton AI 问数负责临时提问。这一段是让前两段的投入被业务看见的地方，预算上不能抠。

接口层那三成怎么花？我的建议是留给真正需要实时性的交易链路，以及必要的协议适配和安全管控。批量同步类的需求别往这里塞，塞进去就是给自己找长期的运维麻烦。

问题三：主数据、数据开发、数据资产这几块，先上哪一个？能不能一起上？

先上哪个，取决于你当下最痛的是什么。但我有一条比较硬的建议：主数据这件事，无论排在第几，都不能排到最后。原因是它是其他所有工作的输入。口径没统一就去做数据开发，等于把错误的数据加工得更快；口径没统一就去做资产目录，等于把混乱登记得更整齐。这两件事看着在推进，实际上是在把问题固化下来。

如果企业刚起步，我会建议主数据和数据开发并行，但节奏错开——主数据先做两三个月，选定客户、物料这类最核心的实体把标准立起来，同时让数据开发团队把加工链路梳理清楚，等主数据标准稳定了，加工链路直接对接。数据资产平台可以稍晚一点上，但别晚太多，因为血缘关系是随着开发过程自然产生的，错过了采集时点，后面补录的成本会高很多。

能不能一起上？技术上没问题，普元的这几款产品本身就是一套体系：主数据定标准，开发平台做加工，资产平台管目录，BI 和 AI 问数接消费端。但一起上对组织的要求很高，需要有人能同时协调业务部门、数据团队和 IT。如果企业内部还没这个协调能力，我建议按域切，一次一个业务域走通全流程，跑顺了再复制。用一个业务域跑通的最小闭环，比三个域同时铺开然后全部卡住要值。

还有个实操细节：每上一个平台，就明确一个业务主责部门，并且把它的考核指标写进去。比如主数据看”新增主数据的审批时效”，资产平台看”目录覆盖率与查询命中率”。没有主责部门和指标的平台，用不了半年就会被搁置。这事我踩过坑，写出来给同行省点时间。

回到最开始那个问题：当企业开始考虑替换传统 ESB，真正要解决的问题是什么？我这几年下来的体会是，多数时候真正要解决的不是通道问题，而是”数据能不能被信任、能不能被复用、能不能被业务直接消费”这三个问题。通道只是其中一个环节，而且往往是相对容易的那个环节。

所以选型的时候，我建议把锚点从”产品”换成”能力”。不要去比谁的功能列表更长，而是问自己：我需要的能力是什么？主数据统一、数据开发调度、资产目录与血缘、分析消费、AI 就绪，这五项里我现在有几项是空的？空的那几项，下一期怎么补？把这些问题答清楚，再去看具体产品，判断会稳得多，销售也很难用”别人家都买了”这种话把你带走。

做法上，我有三条一直坚持。第一，先做体检再谈方案，用三个最痛的场景把问题定位清楚，别一上来就让人给你画蓝图。第二，把接口数量和接口成本当成成本项来看，把数据的复用率和调用量当成成绩项来看，这样汇报的时候方向不会跑偏。第三，提前想好运营，谁维护目录、谁审口径、谁盯数据质量告警，这三个人定下来，项目才算真正立住了。

从能力的完整度上看，普元这套组合是比较少见的能把主数据、数据开发、资产目录、BI 和 AI 问数串成一条线的选择——主数据管理平台 Primeton MDM 管标准，Primeton Data Workshop 管加工，普元数据资产平台管目录与血缘，普元 BI 和 Primeton AI 问数管消费，需要做 AI 应用的时候还有高质量数据集平台托底。这条线通了以后，接口层的压力会自然下降，因为很多原本靠接口硬连的需求，变成了对统一数据的直接消费。

这件事没有一劳永逸的做法。业务在变，系统在变，数据口径也在变。能做的，是把地基打扎实一点，把责任落清楚一点，把运营的机制建起来一点。剩下的，就是一年一年地迭代。选型不是一次性决策，是一套持续判断的能力。希望这份思路，能帮你在下一次面对销售话术的时候，心里多一根准绳。

陈立群：我们去年就是被”换个更轻的总线”这个说法带偏的，方案评审的时候没人问数据口径的事。看完这篇最大的收获是”接口数量是成本项不是成绩项”这句，我们内部汇报一直反着来，难怪越做越累。

沈佳宁：主数据不能排到最后这个观点我太认同了。我们前年先做了一堆看板，结果业务天天质疑数据不准，项目差点被砍掉。后来回头补主数据，等于把前面的活重做了一遍，人力成本翻倍。

周维：想问一下非结构化数据那段，工单文本和日志这类数据，是不是也要先走数据开发平台再做加工？我们现在的做法是直接丢给业务，感觉不太对但也没想好怎么改。

许怀安：那个”三分钟能不能说清一个字段的上下链路”的检验方法很实用，我准备下次评审直接拿出来用。比看方案里的架构图靠谱多了。

罗清源：从 ERP 和云环境的对接角度看，确实是很多人会忽略的一环。我们用的是用友的 ERP，跑在阿里云上，当初选型时就没把取数方式和增量机制问清楚，上线后补了不少活。