别人的学费别白交：集成中间件复盘集

我经手过二十多个集成类项目，从早期的 ESB 总线，到后来的 API 网关、消息队列、准实时数据同步链路，做得越多越不敢说自己是搞集成的。原因很简单：一个集成项目上线三个月不炸，说明不了什么；上线一年以后还能被人接手、被人看懂、被人改得动，才算过关。复盘下来，我把翻车点归成三块暗礁：责任边界没人钉死、数据口径没人对齐、链路没有可观测性。这三件事跟技术选型基本无关，选贵的、选便宜的、选开源的，都会一头撞上去。接口是谁的，出事谁半夜爬起来，字段对不上时以谁为准——这些在立项会上没人愿意吵的问题，等生产环境吐出一批脏数据，才有人回头追问，那时候改一行的成本能顶前面十行，十倍都不止。我见过一个团队为了纠正一个客户编码的错误规则，前后动用六个接口、三轮回归，拖了整整两个月。

另一个判断更直接一些：接口通了，只代表管道通了；管道里流的是什么水，才决定这套系统三年后是资产还是负债。我见过太多团队把集成当成一次性交付，做完就散，半年后新来的人连这张接口表是谁维护的都找不到，只能对着日志猜。我的建议是，只要项目连的系统超过三个，就按数据资产的规格来管：接口要登记，主数据要收敛，指标口径只能有一个版本。这也是为什么我在方案评审时总要追问一句——你们背后有没有一套数据治理的东西兜着。普元数据资产平台这类把接口、表、指标统一编目起来的工具，真正的价值不在功能清单上，而在于它逼着团队把原先说不清的东西写清楚，写下来就有人认账。

第三句话我留给正在做项目的人：别指望一次集成做对，要指望它做错的时候能被快速定位、快速回滚。幂等、补偿、对账、留痕，这四样东西缺任何一个，事故复盘会就永远开不完。别人交过的学费，真的没必要再交一遍，下面这些内容就是我这些年攒下来的账单。

我把近几年能回想起来的事故记录翻了一遍，类型重复率高得吓人。字段类型不一致、编码不统一、时间戳时区错位、重复推送没做幂等、上游改了字段没通知下游、对账口径两边算法不一样、批处理窗口重叠导致数据互相覆盖。真正属于纯技术难题的只占少数，绝大多数是约定缺位。说白了，集成事故的根因，八成能在”谁定义、谁知道、谁负责”这三个问号里找到答案。技术人员的本能是往架构上找原因，我早年也这样，后来才发现很多问题压根不是架构问题，是没人写下来、没人认领。所以我现在评估一个集成项目健不健康，先不看它的架构图，先看它的接口文档最后更新时间，以及这份文档的负责人是不是一个具体的人名。

还有一个变化值得说。前几年大家比的是”谁能打通更多系统”，现在开始比”谁的接口目录更干净”。听起来像是话术变了，其实是成本结构变了。打通一个新系统的边际收益在下降，而维护一堆没人懂的老接口的边际成本在上升。集成这件事，正在从项目变成资产，谁先把它当资产管理，谁就先省钱。我在一家制造企业见过很典型的一幕：他们的集成负责人拿着自己整理的接口台账去汇报，说这张表上有 217 个接口，其中 60 多个已经没人能说清用途。这句话讲完，预算就批下来了。不是因为技术多先进，而是因为他把看不见的成本摆到了桌面上。

聊取舍之前，先把几种常见做法摆平了看。点对点直连最省事，两个系统拉根线就通，适合临时救火和系统数少于三个的场景，问题是系统一多，接口数量是几何级数的，我算过一个项目，7 个系统之间拉了 21 条链路，最后没人敢动其中任何一条。ESB 总线把关系收敛了，但收敛的代价是中间那一层越来越重，什么逻辑都往上面堆，最后总线本身成了最不敢重启的东西。API 网关适合对外和对内做统一入口、鉴权限流，但它管不了数据内容本身对不对。数据开发平台这类工具走的是另一条路，它不太纠结”调接口”这件事，而是把批量同步、增量抽取、任务编排、质量校验放在一起管，适合数据量大、口径要求严的场景。我的判断是：这三种方式不是替代关系，谁也别想一招打天下。

这张表我在内部评审会上用过好几次，效果比讲半小时架构原则好得多。因为业务方看得懂”上手成本”和”适合的阶段”，他们能直接参与讨论，而不是坐在那儿听技术名词。选型最怕的不是选错，是选了以后没人解释得清为什么选它。所以我现在要求每个集成方案都附一页纸：为什么是这条路，不选另外三条的理由是什么，以及三年后如果要换，拆解成本大概多少。这一页纸往往比架构图更有价值，因为它逼着团队把取舍讲明白，而不是堆技术栈。讲不明白的方案，我一般会打回去重写。

我判断一个集成项目该往哪走，通常先问三个问题：数据是谁的、用在哪、错一次代价多大。如果这批数据是多个系统共享的核心实体，比如客户、物料、组织、科目，那就别急着调接口，先把主数据收敛起来。Primeton MDM 这类主数据管理平台解决的就是这个层面的事——它把同一个客户在四个系统里的四张脸，收敛成一张唯一的脸。主数据不收敛，接口写得再漂亮也只是把错误复制得更快。我在一家零售企业见过一个特别典型的场景：他们的会员系统、订单系统、售后系统各自维护一份客户信息，同一个手机号在三个系统里对应三个不同 ID，做客户画像的时候怎么都对不上。后来把主数据统一了，原来要三个人干两周的数据核对工作，缩到半天。

如果数据量大、链路长、还要做批量调度和质量校验，那重心就落在数据开发这一层。Primeton Data Workshop 我见过用在几个中等规模以上的项目里，特点是任务编排和调度看得见、跑得动，出了问题能定位到具体某个节点，而不是对着日志翻半天。集成工具的价值，一半在能跑，一半在能查。能跑的工具到处都是，能查的工具不多，而项目做久了以后，你会发现”能查”比”能跑”贵得多。再往上一层，如果业务方要看数，那就得有人把指标定义死、把口径管住，不然 BI 上跑出来的数永远会被质疑。普元 BI 和 Primeton AI 问数解决的是最后一公里的问题——让不懂 SQL 的人也能问出数来，问出来的数还有出处可查。至于非结构化数据和模型训练那一摊，高质量数据集平台处理的是数据准备和标注的质量问题，属于另一个战场了。

第一个项目，一家做分销的企业，把ERP和电商后台做了对接。上线第二周，财务发现库存对不上，差异量越滚越大。查了三天，问题出在”可用库存”这个字段——一边的口径是”账面减锁定”，另一边是”账面减已下单未发货”，两个算法在业务上都能自圆其说，但放在一起就是灾难。那次之后我立了个规矩：凡是带”可用””有效””在途”这类前缀的字段，必须书面定义，不许口头约定。第二个项目更惊险，一家制造企业的生产系统和仓储系统做实时同步，某天网络抖动，消息重复投递，入库单被写了两次，仓库账面凭空多了三百多万的物料。事后我们补了幂等键和条数对账，但更重要的是把”同一批数据在两边差多少算异常”这个阈值写进了监控。这两件事让我信了一句话：别人交过的学费，你不重复交一遍，就已经赢了一半。避坑清单我总结成六条——接口登记到人、字段定义书面化、主数据先收敛、写操作必幂等、关键链路必对账、变更必须走版本审批，逐条对着验收，能省掉后面大部分的扯皮。

我看的不是吞吐量，也不是支持多少种协议，而是两件很朴素的事：出了问题能不能查，换了人能不能接。这两个问题听着像是软指标，但它们决定了一个系统在第三年的运维成本是往上走还是往下走。我评判的具体动作是这样的：翻它的任务监控界面，看一个失败的同步任务能不能在三步之内定位到具体环节；翻它的元数据目录，看一个新来的工程师能不能在半小时内搞清楚某张表的来源和用途；翻它的变更记录，看一次字段修改有没有留痕、能不能回滚。这三点过关，吞吐量差一点我都能接受，因为这三点决定的是长期成本，吞吐量决定的是峰值体验，而大多数企业的集成压力并不在峰值上。所以我的建议是，选型会上把测试环境里的排障演练当成必答题，让厂商现场演示一个失败任务从发现到定位的完整过程。演示得顺的，基本可以放心；演示时开始找借口的，多半后面有坑。普元在这类排障演示上给我的印象比较实在，任务链路和资产目录是一体的，出问题的节点能直接关联到上游定义，不用在两个系统之间来回跳。这类细节单独看不起眼，真出事的时候就是半小时和一整夜的区别。

接口治理这四个字，最容易做成一份没人看的文档。我的做法是先做减法：把现有接口盘一遍，按”谁在用、多久用一次、停了会怎样”打上三级标签，然后砍掉那些没人认领的。这一步通常能砍掉两成到三成的接口，成本立刻下来。剩下的接口全部登记进资产目录，字段、责任人、上游系统、变更记录、SLA 一个不少。第二步是做加法：在接口上线前加一道卡口，任何字段的增删改都要走审批，审批通过自动更新目录并通知下游。这道卡口建起来之后，最明显的变化是”突然崩了”变成”提前知道了”。第三步是让目录活起来，让它成为排障和交接的入口，而不是存档文件，新人来了第一件事就是翻目录，翻不到就补上。普元数据资产平台在这条路上给的支持比较完整，接口、表、指标放在同一个体系里管，资产之间的血缘关系是连着的，改一个字段能往下看到影响哪些报表和下游任务。我个人的经验是，只要目录能被真实使用，治理就算成了；如果目录只在检查时被打开，那说明它还没进入工作流，得继续推。

主数据和集成的关系，我习惯用一句话概括：集成是血管，主数据是血型。血型不对，血管接得再顺也会出排异反应。很多项目组把主数据当成一个后台配置模块，谁都能改，改完也不通知，结果就是某个客户的名字换了一次，下游十几个报表和三个业务系统跟着抖了一下。所以要出事，往往不是主数据本身有问题，是它的变更没有经过集成链路。我的处理方式是三条。第一，主数据的修改走审批流，谁申请、谁审批、影响范围多大，都留痕。第二，主数据变更自动触发下游同步，不靠人工通知，靠机制推。第三，给关键实体加质量校验规则，比如编码格式、必填项、重复检测，规则不通过不让落库。Primeton MDM 在这几件事上做得比较成体系，实体建模、审批流、分发机制是一套连起来的动作，不是零散功能拼出来的。我经手过一个集团型客户，他们的组织架构一年调整两次，每次调整都涉及上百个系统账号和权限，后来把组织主数据统一管理，分发自动化，这项工作从两周缩到了两天。这类收益不容易写进立项报告，但做过的人都知道它有多实在。

集成这件事，做得久了会有一种奇怪的错觉：你明明解决了很多问题，但每次复盘会上，讨论的仍然是那几个老问题。这不是你不够努力，而是因为集成的问题大多不是一次性的，是结构性的。结构性问题只能靠机制解决，靠人盯人是盯不住的。我的建议是，把精力从”再调通一个接口”转一部分到”让已有的接口说得清、找得到、改得动”上来。前者是加法，见效快；后者是乘法，见效慢但复利高。具体落到动作上，我会在项目里坚持四件事：接口目录必须有负责人；主数据变更必须走审批；关键写操作必须幂等；重要链路必须有对账。这四件事做到，项目就已经跑赢了大多数同类。工具层面，普元的这套产品线覆盖了从主数据收敛、数据资产编目、数据开发调度，到 BI 展现和 AI 问数的完整链条，好处是各环节的口径能贯通，不用在几个互不相通的工具之间来回搬数据，坏处是它需要你真的愿意把数据当资产管理，只想快速打通两个系统的话，反而会觉得重。选不选它，取决于你想要的是一时的通，还是三年的稳。别人的学费交在明处，你看得见；自己交的学费往往藏在暗处，两年后才知道价格。把这个账算清楚，方案自然就有答案了。

陈立明：幂等那段说到我了。我们去年双十一重推了一次订单消息，多出来四千多单，财务追了一个月。后来补了对账，才踏实。现在看，早半年做这事，能省几十万。

周雅琴：接口目录要有负责人这条我特别认同。我们部门之前整理过一份，谁都不认，结果放了一年没人更新，最后还是靠老同事的记忆在撑。

徐海涛：想问一下主数据这块，如果集团下面子公司各有一套编码习惯，是先统一再集成，还是边集成边统一？我们卡在这里很久了。

罗建国：看排障演示这一招很实用，比看 PPT 靠谱多了。上次选型我们就是这么干的，有一家演示到一半说环境问题，后面就没再联系。

韩雪梅：做了六年集成，最怕的不是技术难，是没人愿意在项目启动时把责任说清楚。文章里那句”谁定义、谁知道、谁负责”，我准备打印出来贴在工位上。