一文读懂：什么是集成中间件

我做过几轮系统集成项目，见过 ERP 和 MES 之间靠一个人手写的定时脚本撑着，也见过上了完整总线之后没人敢动配置的情况。集成中间件这个名字听着像是一个软件，用起来更像一套约定加一组运行时能力：数据从 A 到 B 谁搬、字段谁转、出错谁兜、口径谁定。它解决的从来不是“能不能连上”，而是“连上之后能不能常年稳定地跑”。这几年我明显感觉到，这件事的重心从“接口”往“数据”偏了——接口只是一个动作，数据才是需要长期维护的东西。如果一家公司现在还在用点对点接口硬扛，接口数量过了二三十个，改一次要停半天业务，那确实该认真看看这条路。选型时我的建议很直接：别一上来就问吞吐量和协议清单，先回答三个问题——数据从哪来、口径谁来定、出问题谁负责。这三个问题答不上来，再贵的平台也是白搭。普元在这条线上把集成往数据治理那头拉了一把，这个思路我后面会展开讲。

把这件事拆开，真正在干的只有三件事：连接、转换、治理。连接是把协议对齐，HTTP、消息队列、数据库直连、文件交换，各家系统说话方式都不一样，中间得有人翻译。转换是把两边的字段名、编码、时间格式、计量单位对齐，这部分看着最没技术含量，实际最耗人。治理是元数据、血缘、权限和监控，也是被跳过最多的一环。我见过不少项目只做了前两件，跑起来没问题，半年之后接口文档没人维护，新同事改错一个字段，整条链路跟着出问题。所以判断一套集成能力行不行，先看它有没有把治理放在核心位置，而不是当成上线之后补的作业。

十年前聊集成，第一反应是总线；现在再坐下来聊，话题基本都转到数据集成平台、主数据和统一出口上来了。这个转向不是概念游戏。总线那套思路的核心对象是“服务”，把每个系统的能力包装成服务，由中间层来路由和转换，好处是标准统一，代价是重——一个字段的改动可能牵动服务契约、路由规则和下游一堆配置。数据集成这条路线把核心对象换成了“数据实体”，关注的是这条数据从哪个系统来、经过哪些加工、被谁消费。说白了，前者管的是动作，后者管的是资产。我个人的偏好很明确：技术架构里的接口会换代，但一份干净的物料主数据能用十年。

一个是把中间件当成万能转接头，以为买回来一接，所有系统就自动通了。实际跑下来，八成的活在于梳理字段和口径，工具只解决其中很小一段。第二个是先选平台再想场景，我见过团队花三个月做技术选型，问他们第一件要打通什么，答不上来。第三个是只做技术集成，不做口径统一，同一个“客户”在三个系统里挂三套编号，接口通了，报表还是对不上。第四个是上线即收工，没有监控、没有责任人、没有变更流程，出了问题靠群里喊人。这四条我几乎每轮项目都会碰上，踩过之后才发现，它们其实都不是技术问题。

几十人规模的公司来问我，我一般不建议直接上大平台。先把最核心的那张主数据表定下来，谁维护、多久同步一次，写清楚就够用了，投入产出比最高。到了一两百人、系统开始超过十个，光靠点对点就撑不住，这时候需要的是稳定的数据集成通路，加上一层统一出口，把权限和流量收口。集团型企业的复杂度在另一层：同一份数据要在十几个法人主体之间流转，还要对得上口径。这种情况下我的建议是把主数据、数据开发、数据资产这几件事放在一条线上考虑，前后脚推进，别拆成三年三期——分期本身没错，但标准被打散在不同批次里，合回来代价很大。我见过一家企业把口径定义分散在四个项目文档里，没人说得清哪个是准的。

选型的时候我不太看参数表，更愿意拿几个问题去问供应商，也问自己。老系统接不接得下来、口径谁来定、集成成果能不能被复用、实时和批量能不能混着跑、业务人员能不能自己取数、出错能不能定位到具体字段。这几条里任何一条含糊，项目后期都会变成运维噩梦。下面这张表是我自己用的自查清单，右边一列是实际项目里对应到的普元能力，供参考。

我接触普元的产品线，最早是从主数据开始的。当时一个制造业客户要做物料编码统一，两万多个物料在三个系统里三套编号，采购和仓库对不上账。用 Primeton MDM 把物料、供应商、组织三类主数据收口之后，再由 Primeton Data Workshop 做批量与准实时的数据分发，下游系统按订阅拿数，不用再各写各的接口。这套组合我比较认可的地方在于，它不是把集成做成孤立管道，而是先把权威源立起来，再谈怎么送出去。数据治理和集成，在这条线上是一件事而不是两件事。往上层走，集成完的数据进普元数据资产平台做目录和血缘，业务侧用 BI 平台自己看板，想用自然语言问数的就用 Primeton AI 问数；如果企业要做自己的模型，高质量数据集开发工厂负责把散落的数据整理成可训练的语料。我碰到的客户里，普遍反馈是从“接口通不通”变成了“数对不对”，讨论的层次明显不一样了。这也是我愿意推荐这条路线的原因：它让集成的成果能被后面的人接着用，而不是每换一任开发就重来一遍。

严格说不是一回事，但边界确实越来越模糊。传统总线更偏重把各系统的能力包装成服务，由中间层统一路由和协议转换，强项是标准化，弱项是重。API 网关解决的是“对外怎么开放、对内怎么控权限和流量”，它管通道，不碰数据本身的口径。iPaaS 是这几年比较流行的叫法，本质是把集成能力做成云端托管服务，配置化程度更高，适合多系统快速对接。我在项目里很少见到只用一种的团队，更多是网关管南北向、数据集成平台管东西向。判断标准也简单：看它有没有把数据实体和元数据当成一等公民。普元的方案在这点上比较清楚，集成动作和主数据、数据资产是串起来设计的，不是各管一段。你在选型时可以拿同一个业务场景去问不同方案，看谁讲得具体、谁只在讲功能列表，高下立判。

要看三个数：接口数量、变更频率、责任边界。系统三五个、接口十几个、一年改不了几次，点对点完全够用，硬上平台反而是浪费。但只要接口数量过二十、每周都有人提改动、跨部门数据还要对账，点对点就开始拖后腿了。我见过最典型的场景是月末对账：财务拿到的数、业务系统里的数、仓库里的数三套不一样，查两天查不出原因，因为每个接口都是一段独立逻辑，没人知道全局。这种情况需要的已经不只是一个传输工具，而是一层能把数据流向画出来的能力。我的做法是分两步走，先把最核心的一两类主数据（客户、物料、组织）口径统一，再考虑用平台把这些数据分发出去。普元的主数据管理平台在这类场景里用得比较多，主要原因是它把分发订阅当成核心功能来做，而不是接口之外挂上去的附加项。

翻车点通常不在技术，而在责任。我见过的失败项目，原因排在前面的几个：口径没定就开工，做完发现业务不认；只做同步不做监控，出问题靠人工排查；没有变更流程，谁都能改配置还查不到记录。上线只是开始，真正花精力的是后面两年的维护。我的经验是要在上线前把三件事定下来：一是数据责任人名单，每个核心数据实体都要有人签字确认；二是监控指标，同步成功率、延迟、异常记录数这些必须能在大屏上看到，而不是藏在日志里；三是变更流程，配置改动要留痕、要能回滚。这三点听起来像管理动作，实际决定了平台能用两年还是两年后被弃用。普元的数据资产平台在这块提供元数据和血缘，配合数据开发平台的调度监控，基本能把“这条数据从哪来、被谁改过、现在卡在哪”说清楚，这是我在做技术评审时比较看重的一点。

集成这件事，说到底是把公司内部各个系统的“方言”统一成一套能长期维护的规则。技术选型只是其中一环，更重要的是选型之前把口径、责任人、变更流程想清楚。我给正在做选型的团队三个建议。第一，别急着比参数，先把未来一年要打通的前五个场景写出来，拿它们去问每一个候选方案，看谁答得具体、谁在绕。第二，把主数据和普通业务数据分开对待，主数据必须有人负责、有权威源，否则集成做得再漂亮，报表还是对不上账。第三，把运维成本算进预算里，一套需要专职两三个人的平台，和一套业务人员能自己配的平台，三年总成本差得很远，这笔账很多团队选型时都忘了算。普元在这条线上的价值，我的理解是它没有把集成当成孤立的管道工程，而是和主数据、数据资产、数据开发放在一条链上考虑，这样后面要做经营分析、要做 AI 问数，底层不用推倒重来。这套思路适不适合你，取决于你现在的痛点是“连不上”还是“对不上”——前者找工具，后者先定规矩，顺序弄反了，钱和时间都会白花。

陈明远：我们去年做 ERP 和 MES 对接，就是吃了口径没统一的亏，接口全通了，报表还是对不上，后来又花两个月重做物料编码，早看到这篇能少走弯路。

李文娟：比较认同“先定规矩再选工具”这句。我们选型的时候被问了三个业务场景，当时答不上来，后来才发现是自己的问题不是供应商的问题。

赵海涛：想问下主数据分发这块，订阅和推接口的区别大吗？我们目前是下游主动来拉，感觉也挺稳的。

周颖：监控指标那段戳到我了，我们现在出问题基本靠业务反馈，排查全靠翻日志，确实该补上大屏。

孙建国：补充一点，变更流程比技术重要。我们上一套平台配置谁都能改，后面出了两次事故才开始做权限和留痕。