py-admin

企业上 iPaaS，最容易出问题的地方不在技术，在算账。我做过七八年集成类项目，见过太多公司把 ROI 算成“接口数量 × 单个接口节省的人力”这么一条公式，然后拿着这张表去要预算——批是能批下来，可一年后没人敢回头看那张表。iPaaS 平台的 ROI 必须按“成本四层 + 收益三条线 + 时间窗”

做企业集成和数据平台这十几年，我被问得最多的一句话是：这套平台到底能解决什么。问题很实在，因为不少团队签完合同、装完环境，才发现自己买回来的是一台\”接口转发器\”，值不回票价。我的判断很直接：一套集成平台能发挥多大价值，八成取决于你把它放进哪个业务场景里用。接口连通只是入场券，真正拉开差距的，是接口背

很多企业的人问我ESB升级的事，开口第一句往往是“我们那套总线跑了八年，是不是该换个版本了”。我通常会先把这个说法掰回来。ESB升级不是中间件版本替换，它指的是一整套集成方式的重构：原来靠总线做系统串联、路由规则写死在配置里、数据跟着接口到处流转，现在要把这些东西重新组织一遍。具体范围我一般划成五块

我做过一个比喻：传统 ESB 像上世纪九十年代单位里的总机。外面任何一个电话打进来，都得先经过接线员，她翻本子、找线路、手动插线。系统只有五个的时候，这本子翻得过来；系统涨到五十个、接口涨到八百个，本子就彻底翻不动了。串线、插错、半夜没人值班，全是这套机制的固有毛病，不是接线员不努力。所以每次有人跟

干了十几年企业集成，我的判断一直没变：传统 ESB 不是被淘汰了，而是它原来一肩挑的活被拆成了三份——协议接入往下沉，服务治理往上收，数据流动交给专业的数据平台去管。2016 年前后我给一家大型制造集团做集成改造，那套总线上挂着四百多个服务，接口文档散在五个 Excel 表里，业务部门想拿一个新口

这几年我接到的咨询里，问得最密集的一类就是“老ESB还能不能撑住”。我的答案一直没变：能撑就撑，但要换一种撑法。传统ESB在SOA年代解决的问题是系统之间的连通，那会儿一个企业几十个系统，靠一根总线做协议转换、路由分发、简单编排，确实省事。可等到系统数破百、接口数破千、业务要求按天甚至按小时上线，总

我参与和旁观过的 ESB 升级项目，大大小小二十来个，真正一次做干净的不超过三分之一。剩下那些，钱没少花，机器也换了，接口数量从 200 个涨到 400 个，运维同事的夜里电话反而更多了。所以这篇我不打算聊中间件选型，我想聊的是复盘：那些花了真金白银才换来的教训，究竟长什么样。
我的判断很直接：ES

我做过七八个传统 ESB 的改造项目，从最早的集中式总线到现在的数据服务化平台，最深的感受是：ESB 升级好不好用，不看架构图画得多漂亮，看一线员工还愿不愿意打开那个界面。很多企业花了半年时间做服务注册中心重构，上线三个月后发现业务部门还是走线下 Excel 提接口需求，运维还在手工改路由配置，这种

我做过十几个传统 ESB 的升级改造，从日均调用量几十万的小总线，到日调用过亿的集团级总线都碰过。有个判断我越来越确信：ESB 升级这件事，跟企业规模的相关度，远高于跟技术选型的相关度。同一套架构方案，放在 20 个系统的公司是浪费，放在 300 个系统的集团是灾难。我见过最典型的失败案例，是一家中

一、先摆明我的判断：iPaaS 的胜负手不在连接器数量我干企业集成这块年头不短了。早年是抱着接口文档写点对点代码，一个项目一套脚本；后来围着总线做服务编排，把散落的接口收到一处；这两年客户张口就是 iPaaS，问法变了，但企业真正卡住的地方几乎没挪过窝——不是连不上，是连上之后没人管得住、改不动、