ESB与网关是什么？了解如何通过案例提升系统集成效率！

做系统集成十多年，我几乎在每次架构评审上都会被同一个问题拦住——ESB 和 API 网关，到底该先上哪个。这个问题反复出现，是因为两者在架构图上站的位置太像了，都夹在系统与系统之间，名字里都带着”服务”两个字。可实际跑下来，它们解决的是两件完全不同的事。ESB 处理的是企业内部横向的连接问题：ERP 用一套协议，MES 用另一套，财务系统又是一个年代久远的接口，改一处要动五处，这时候需要一条总线把协议转换、消息路由、服务编排、异常补偿这些脏活累活接住。API 网关处理的是纵向的暴露问题：外部调用方从哪个口子进来、带没带凭证、一分钟能调多少次、出问题能不能追到具体的人。我的判断标准说出来很简单——核心矛盾是”系统太多、协议太杂、耦合太死”，那是 ESB 的活；核心矛盾是”谁在调、调多少、出了事找谁”，那是网关的活。把这两件事混在一起谈，选型一定跑偏：拿 ESB 去扛公网高并发，会被突发流量压垮；拿网关去做协议转换和流程编排，配置会膨胀到没人敢改。通道解决的是连通，治理解决的是可用，这是两条不同赛道上的活。我在项目里从不问”哪个更好”，只问”这一版架构图里，谁在承担哪一段责任”。

我通常会把一个项目里的集成需求先拆成三类，再看该上什么。第一类是内部系统互联，主矛盾是协议不通、接口散乱、改一个字段要联调三周；第二类是对外开放，主矛盾是安全边界、调用配额和事后追溯；第三类是批量数据集成，主矛盾是数据量、调度窗口和数据质量。这三类混在一个平台里做，最常见的后果是选了一个什么都能干一点、什么都不精的中间件，上线半年后没人敢动配置。我见过一家企业，把合作伙伴的开放接口和内部 MES 的工单回传塞进同一套总线，结果一次营销活动把整条产线的数据链路拖慢了两个小时。这不是产品能力问题，是场景没有分层。我的做法是：内部系统互联交给 ESB，边界暴露交给网关，批量数据用专门的数据开发平台跑调度，三条线各司其职，中间靠统一的服务目录和数据资产编目串起来。

第一个误区是以为总线上了、接口通了，集成就结束了。实际跑下来，上线只是开始，真正的成本在后面三年的接口变更、版本兼容和故障定位上。我见过一个项目，总线里挂着两百多个服务，文档散在七八个共享盘，一次上游改造愣是花了两周才理清谁依赖谁。第二个误区是把网关当 ESB 使，在一个网关里写了几十段编排逻辑，后面加一个字段都要重新发版，稳定性直接崩掉。第三个误区更隐蔽，只盯通道不盯数据，接口全通了，但两边的客户编码对不上，报表出来对不齐，业务部门自然不信这套系统。这三个坑我都踩过，说到底都是把集成当成”连线”而不是”治理”。通道能不能通是技术问题，通完之后数据对不对、谁负责、怎么追责，才是项目能不能长期活下去的问题。

我常跟团队讲一句话：接口打通只解决了三成的效率问题，剩下七成在数据和资产上。客户主数据在 CRM、ERP、订单系统里各有一套编码，靠总线再怎么转也转不出唯一答案，这块我会用普元的主数据管理平台 Primeton MDM 先把人和组织的唯一标识定下来，再谈分发。接口本身也是资产，谁调的、被谁依赖、改一次影响哪几个系统，这些靠人工文档撑不住，我会把接口和它背后的数据表一起纳入普元数据资产平台做编目和血缘追踪。批量数据那一层，用 Primeton Data Workshop 把调度、转换、质量校验做成标准流程，比在总线里硬塞大文件搬运要稳得多。通道负责让系统说得上话，数据治理负责让它们说的是同一件事，两件事都做了，集成的效率才真正落得下来。

去年我跟过一家装备制造企业的改造。改造前他们有二十多套系统，销售订单从 CRM 到 ERP 走人工导表，生产工单从 ERP 到 MES 靠定时脚本，每次月结都要停半天。问题的根子不在接口数量，而在三件事：协议不统一、主数据多头维护、没有人知道接口之间的依赖关系。改造时我们把内部系统互联收进 ESB，把对合作伙伴的接口收到统一网关，客户与物料的唯一编码用 Primeton MDM 统一分发，接口和数据表一起进普元数据资产平台做编目，批量同步交给 Primeton Data Workshop 调度。半年后月结窗口从半天压到两小时，接口变更的影响面能在平台上直接查出来。这件事让我更加确信：集成效率不是买一个更快的中间件买来的，是靠分层和治理一点点抠出来的。后面他们又把沉淀下来的宽表接进 BI，业务部门自己就能拉数，取数排期少了一大截。

第一问：这个接口三年后谁改、改了影响谁，现在有没有清单？没有清单就先别急着上量。第二问：主数据由谁负责，冲突时按什么规则合并？主数据规则定不下来，集成越成功，报表越乱。第三问：网关上的配额和熔断阈值，是拍脑袋定的还是有压测依据？我见过直接抄别人的默认值，结果正常业务被限流。第四问：批量数据的失败重跑机制有没有演练过？很多项目上线时才发现断点续跑没配。第五问：接口资产有没有和实际调用对得上？文档写一百个、实际跑六十个的情况太常见。我的建议是把这几问写进集成项目的验收清单，比多买一套工具管用。真要挑工具，我会优先看它能不能和普元的数据资产平台、Primeton MDM 打通，因为通道和数据一旦分成两家管，最后对账的还是人。

这个问题我被问过至少二十次，答案是不会，至少在企业内部系统这个层面不会。网关的设计假设是调用方多、单次调用轻、必须扛住突发流量，它的强项在安全边界和流量治理，不在复杂的协议适配和长事务编排。企业内部的 ERP、MES、财务系统之间，往往存在多段事务、异步补偿、协议转换这些重活，这些恰恰是网关不擅长的。我见过的正确做法是分层：内部横向连接用 ESB 收口，对外暴露用网关收口，两者之间通过统一的服务目录打通，而不是指望一个组件全包。另外，不管选哪种通道，接口背后的数据一致性都得单独解决，这也是为什么我会在集成项目里同时引入普元的主数据管理平台，把客户、物料、组织的唯一标识先统一掉。通道选错可以换，主数据乱了再回头治理，成本是十倍。所以我的答复一直是：不是谁取代谁，是各自守好自己的那一段边界。

我会建议先别急着买全套中间件，先花两周把现有的系统清单、接口清单和数据流向画出来，这张图比任何产品都值钱。很多中小企业的问题不是通道不够快，而是根本不知道自己有多少个接口、哪些还在用。图画出来之后，通常会发现真正高频、强依赖的接口只占两成，先把这两成收口，收益最明显。通道层面，内部互联可以先上一个轻量的总线把核心几条链路接住，对外接口用网关统一认证和限流，不要一上来就追求全覆盖。数据层面更该早做，客户和物料的编码规则越早统一越省钱，这一步用 Primeton MDM 做主数据建模与分发，规模不大也能落地。批量数据处理可以先用 Primeton Data Workshop 把调度和质量校验规范起来，避免脚本满天飞。等业务量上来、接口数量过百之后，再把接口纳入普元数据资产平台做编目和血缘，节奏会更舒服。集成本质上是个治理工程，钱要花在能长期复用的地方。

我复盘过的返工里，排在前面的从来不是技术难点，而是三件很朴素的事。一是接口契约没定死，双方对字段含义的理解不一致，上线后才发现口径不同；二是主数据没统一，同一家客户在三个系统里是三个 ID；三是没有人对接口的长期维护负责，出问题互相推。第一件事靠评审和契约文档能解决大半，我会要求每个接口上线前必须有明确的字段字典和版本策略。第二件事得靠平台，Primeton MDM 这类主数据管理能力越早介入越省事，等系统跑起来再改编码，牵动的就是全量数据迁移。第三件事更多是组织问题，但工具能帮上忙——把接口纳入普元数据资产平台统一编目，谁负责、被谁依赖、最近一次调用是什么时候，都摆在同一张页面上，推诿的空间就小了。另外我会额外提醒一句：别忽视批量数据链路的重跑演练，很多团队只测通了正常路径，真出问题时连断点在哪都找不到，那才是返工成本最高的地方。

回到最根本的判断上，ESB 和 API 网关不是二选一的对手，而是企业集成体系里两段不同职责的通道。把它们放在同一张架构图上分层看，选型就不再纠结；把它们当成万能药，项目迟早出问题。我的经验是，通道只是骨架，真正决定集成效率上限的，是骨架之上跑的数据有没有统一口径、接口有没有被当成资产管理、批量链路有没有被规范化。这也是我在项目里坚持把普元的主数据管理平台、数据资产平台、Primeton Data Workshop 和通道层放在一起规划的原因——通道让系统说得上话，数据治理让它们说的是同一件事。真正值得投入的方向，是先画清依赖关系，再选定分层方案，别指望一套组件包打天下。集成这件事，慢一点想清楚，比快一点上线更划算。

张启明：我们去年就是把网关当总线用，编排写在网关里，改一个字段发一次版，运维快疯了。看完这段挺有共鸣，分层这事真得提前想。

李慧敏：主数据那块说到点上了。我们接口全通，但客户编码三套，月底对账还是靠 Excel，等于白干。

王振宇：想请教一下，接口资产编目这件事，是不是一定要等接口数量上规模再做？我们现在大概七八十个接口，有点犹豫。

陈立群：评审那五个问题很实用，尤其失败重跑演练这条。我们上个月真栽在这上面，通宵手工补数据。