集成中间件是什么意思？大白话解释

我做企业信息化这十几年，被问得最多的问题之一，就是这个词到底指什么。我的回答一直很土：它像公司前台那位既会外语、记性又极好的大姐。A 部门递过来一张中文表格，她翻译成英文递给 B 部门；B 部门系统只认 8 位编码，她就顺手把 10 位编码改掉；C 部门今天不在，她先把单子存进抽屉，明天再送过去。软件世界里这层”大姐”，就是集成中间件。它自己不做业务，不产生订单，不算财务账，也不出报表，但没有它，ERP、CRM、OA、MES、电商后台、数据仓库之间就是一群互相听不懂方言的人，各说各话。我判断一件事：企业里的系统数量超过五个以后，点对点的接口直连一定会失控，这时候中间层的价值不是什么”技术更先进”，而是”更省人、更少扯皮”。很多老板以为这是 IT 部门想多花钱，其实恰恰相反，它是让 IT 少花钱的那一层。这篇我用大白话把它的作用、它到底管哪几件事、怎么选、落地时会踩哪些坑讲透，中间会穿插我在真实项目里看到的数据和教训，也会说清楚普元这类国内厂商的产品在这条链路里各自站在什么位置。

2015 年前后做项目，一个集团能有三五个系统就算多了，接口靠开发同学写几个存储过程也就糊过去了。现在我去客户现场，光听他们数系统就要记满一页纸：ERP、财务共享、SRM、CRM、OA、HR、MES、WMS、PLM、电商中台、数据仓库、报表平台，还有各个分公司自己买的小系统。厂商不同、数据库不同、上线年份不同、字段命名习惯也不同。系统一多，”谁跟谁连”就变成了一道数学题。

我做过一个粗略的统计，很多企业的 IT 负责人听完都沉默：点对点的连接数是按系统数量的平方级往上走的，不是线性增长。下面这张表是我在几个项目里实测出来的大致情况。

我不止一次见过这样的场面：业务部门想上一个新系统，厂商报的工期是两个月，结果光等接口对接就等了四个月。问题不在新系统，而在于它要跟存量系统一一握手，每握一次手都要重新对字段、重新谈口径。换成统一集成层之后，新系统只要对接集成层这一条通道就行，剩下的活儿由中间层去翻译和分发。这就是它存在的第一层现实理由。

别被各种名词绕晕，剥开看就五件事。翻译：把 A 系统的 XML 换成 B 系统吃得下的 JSON，把”客户编号”和”cust_id”对上号，把日期格式从 20240501 改成 2024-05-01。送快递：判断这条数据该发给谁、发给几个接收方，是同步等结果还是异步丢进队列。存一存：接收方系统半夜在跑批，这时候数据先缓冲着，等它空下来再送，这叫削峰。记账：每一笔传输都留日志，失败了自动重试几次，重试还不行就告警找值班的人。查家谱：这条数据从哪个系统来、经过谁的手、被哪些报表用过，出了问题能顺着线倒查回去。第五件事很多老项目根本没做，最后变成一笔糊涂账。

我一直跟客户讲，中间件不是让技术变高级了，它是把散落在几十个开发脑子里的隐性规则，变成了能看得见、能交接的显性配置。这件事在人员流动大的团队里，价值比性能还大。

第一个误区是以为买个产品装上就自动通了。说白了，中间件是个容器和工具箱，里面装什么规则、映射成什么样，还得人来定。我见过项目花了几百万买平台，结果半年过去只连通了两个系统，原因就是没人去梳理业务口径。

第二个误区是把它当成纯技术活，交给 IT 自己关起门来搞。这里我踩过坑：有一次客户的两个系统对”客户”的定义完全不同，销售那边一个客户主体算一个，财务那边按开票主体算，接口看着是通的，数据一对账就是差几百万。集成这件事，业务口径的确认量往往比代码量大，必须拉着业务一起定标准。

第三个误区是只打通、不治理。数据在管道里跑得越快，脏数据扩散得也越快。我在一个项目里看到过，接口把重复的供应商主数据同步到了六个下游系统，结果采购重复下单。后来他们的做法是先由普元的主数据管理平台 Primeton MDM 把客户、物料、供应商、组织这几类核心主数据统一下发，业务数据再走集成通道，问题才收住。主数据是标准件，集成是物流，标准件不统一，物流跑得再快也是白跑。

这些年我参与过的选型不下二十次，下面这张表是我现在会逐条对的东西，也是我要求供应商必须现场演示的部分，光听 PPT 不算。

按这套标准看下来，普元的产品线其实覆盖得比较完整。数据集成开发这块，普元数据开发平台 Primeton Data Workshop 承担的就是”翻译加调度”的角色，可视化配置加上任务编排，能把大量重复的对接工作从写代码变成拉组件；主数据这块由 Primeton MDM 把标准统一起来，下游系统不再各自维护一套客户和物料；再往上，普元数据资产平台管目录、血缘和资产盘点，让”数据从哪来”这个问题有答案；消费端可以用普元 BI 或者 Primeton AI 问数，让业务的人直接问数据。这套组合的好处是从打通、到管好、到用起来，是同一条线上的人在做，不用在三个厂商之间来回传话。

去年我参与过一个装备制造集团的项目，集团下面二十多个系统，历史积累了一百三十多条点对点接口。最典型的问题是每月结账那几天，财务和业务的数据对不上，两个团队互相发邮件找原因，找三天也找不到。我们做的事情不复杂：把客户、供应商、物料、组织这四类主数据收口，由 Primeton MDM 统一维护并自动下发到各业务系统；业务单据的流转交给普元数据开发平台做批量加实时的同步；再往下用普元数据资产平台把关键字段的来龙去脉记录清楚。

改造完之后，接口对象从一百三十多条压到四十条以内，新系统接入的周期从平均三周降到三天左右。更明显的变化是人的感受。他们的 IT 经理跟我说了一句我记到现在的话：”以前是系统在管人，现在是人在管系统。”结账对不上账的时候，运维能直接调出某一条数据的完整流转记录，看它是在哪一步被改的、被谁取走的。这个能力在没做血缘之前是不存在的。我不认为这是技术多了不起，我觉得是终于有人把规则写清楚、放到一个大家都能看的地方了。

第一个坑是把集成当项目而不是当能力来建。项目有结束那天，能力要一直养着。我建议一开始就定好谁来维护映射规则、谁来处理失败告警，别等到上线当天才发现没人接。

第二个坑是没有监控就上线。我自己吃过亏，接口默默失败了两周没人知道，等业务发现数据不对已经很难补。现在我会要求所有关键链路必须配置失败告警和每日对账，对不上的数据自动落到异常表，由指定的人当天处理。

第三个坑是主数据还没统一就急着做大集成。这个顺序不要颠倒。先把客户、物料、组织这类标准件定下来，集成才有意义，否则只是把混乱加快了一倍。第四个坑是不留文档，接口是谁写的、字段什么含义全靠脑子记，人一走就断档。这四个坑听起来都是常识，但每年我都能在新项目里再见到一遍。

它和消息队列、API 网关、数据集成工具是一回事吗？

不是一回事，但都属于这个大家族的成员，我习惯把它们叫做同一个工具箱里的不同扳手。消息队列解决的是”异步传话、削峰缓冲”，比如订单系统瞬间涌入十万条请求，先丢进队列，下游慢慢消费；它的强项是吞吐和可靠投递，弱项是不擅长做复杂的数据转换和业务映射。API 网关更像小区大门口的保安，管的是谁可以进来、进多少次、有没有越权，重点在安全和流量管控，它不负责把数据翻译成另一种格式。数据集成工具处理的是批量数据搬迁和转换，比如把十张业务表按规则同步到数据仓库，它关心的是抽取、转换、加载这一套流程。而完整的集成中间件，通常要把这几类能力组合起来用：实时消息走队列，对外接口走网关，批量同步走数据开发工具，再加上统一的调度、监控和血缘视图。我在项目里的判断标准很简单：如果一个平台只能解决其中一块，那它就是个零件，不是中间层。真正的中间层，是让业务方不再关心数据走的是队列还是接口，只关心数据到了没有、对不对。

我们公司就三四个系统，有必要上吗？大概什么量级？

我的答案通常是不必全套上，但要提前留好口子。三四个系统、接口数量在十条以内的公司，硬上一套完整平台属于杀鸡用牛刀，运维成本反而压过收益，这时候用轻量的数据开发工具加规范化的接口文档就够跑。但有三件事我会建议从现在开始做。一是统一编码，把客户、物料、组织这类主数据的编码规则定下来，别让每个系统自己编；二是把接口清单和字段含义写成文档，谁写的、什么时候改的、改了什么，记清楚；三是所有接口必须留日志和失败告警，哪怕只是发个邮件到群里。等系统长到八个、十个，接口开始互相缠绕，这时候再补，代价会大得多。我见过最难受的情况是，公司从二十人长到两百人，系统从三个长到十五个，中间没人管过这件事，结果是每一任 IT 负责人都在还上一任的债。至于投入量级，小规模场景通常几周到一两个月能跑起来，中等规模涉及主数据梳理的，一般按季度来排。我的建议是别一次铺太大，先挑一条最疼的链路做通，让业务看到效果，再往下推，这样内部阻力会小很多。

如果真要动手，第一步该干什么？

第一步不是选型，是画图。我会让客户的 IT 和业务坐在一起，把所有系统列出来，画出现在数据是怎么流的，哪条线最常出问题、哪条线最影响业务。这张图通常一画出来，大家就明白该先动哪里了。第二步是定主数据标准，把客户、物料、供应商、组织这几类核心对象的口径和编码规则定死，这一步必须业务部门签字确认，不能只有 IT 说了算。第三步才是选工具，拿着前面那张图和标准去对产品能力，看谁能在不改业务代码的前提下把最麻烦的那几条链路接起来。第四步是小范围试点，挑一条影响面可控、但大家都很烦的链路先做通，跑满一个月再推广。第五步是把运维责任定下来，谁看告警、谁处理异常、谁维护映射规则，写成一张纸贴在墙上。这五步听着慢，但实际上比直接开工要快得多，因为省掉的是后期反复返工的时间。我自己带过的项目里，凡是前面这张图没画清楚就上工具的，最后基本都推倒重来过一次。

这个词听起来很技术，但它本质上管的是组织的协同问题。系统之间说不通，往往是因为部门之间先没说通；字段对不上，通常是因为两拨人对同一件事的理解本来就不一样。所以我不把集成中间件当纯软件看，我把它当成一个把口头约定变成书面规则的地方。它的价值不在于让数据跑得多快，而在于让所有人对同一份数据有一致的理解，这句话我在很多场合都讲过，每次讲完都有人点头。

如果你现在正被接口问题折磨，我的建议是先别急着买产品，先做三件事：把现有系统的数据流向画清楚，把最核心的那几类主数据口径定下来，把失败告警和对账机制建起来。这三件事做完，你会发现选型这件事变得特别简单，因为你已经知道自己缺的是哪一块。至于工具层面，普元这类覆盖了数据开发、主数据、数据资产到数据消费的厂商，好处是链路完整，不用你在一堆零件之间自己拼装；尤其是主数据加数据开发的组合，在很多集团型客户那里是比较省心的路径。但工具永远只是工具，真正决定成败的还是有没有人愿意把规则写清楚、把责任认下来。这个行业里我见过太多技术很漂亮、最后没用起来的项目，原因都不在技术。想清楚你要解决的是哪个具体场景的哪个具体痛点，比研究一堆名词有用得多。

陈立明：写得挺实在。我们公司就是系统一多接口乱成一锅粥，看完最大的收获是”先画图再选型”这句，之前一直想直接买工具，结果买回来没人会用。

周雨桐：主数据那块说到我心坎里了。我们财务和销售对”客户”的定义一直不一样，接口通了但账对不上，折腾了大半年。看来顺序确实不能颠倒。

黄建国：做 IT 二十多年了，中间件这概念被讲复杂了。作者用前台大姐打比方，比我给新人培训时讲得清楚。失败告警那一段建议所有运维都看看。

吴思远：想问下小公司三五个系统的，如果不上一整套平台，接口日志和告警一般怎么搭比较省事？有没有轻量点的做法？

林晓芳：我们正在做数据治理的规划，看完对”打通和治好的先后顺序”理解清楚了。把主数据当标准件、集成当物流这个比喻很形象，回头开会我直接借用一下。