iPaaS集成平台集成技术

替代 Oracle SOA 这件事，我在十几个大中型企业的集成项目里都碰过。我的判断很直接：它不是把一套中间件换成另一套中间件，而是把\”以总线为中心的服务编排\”这套思路，升级成\”以数据和 API 资产为中心的服务治理\”。Oracle SOA 套件（BPEL、ESB、OSB、BAM 那一整套）在十几年

去年冬天我在华东一家做重型装备的客户现场，会议室里坐了运维、集成、数据三个团队的人，议题只有一个：那套跑了十一年的老 SOA 套件还要不要续保。运维同事当场算了一笔账，年度原厂服务费加内部两名专职维护人力，一年接近一百八十万，而过去十二个月通过它新增的服务接口只有九个，其中六个还是给同一个报表系统用

一、核心判断我做过十几个和\”替代传统 ESB\”沾边的项目。真正在评审会上把需求摊开的时候，会发现各人心里的目标完全不一样。架构组想的是把总线这个单点拿掉，运维想的是少维护一台中间件，业务部门想的是接口能不能当天开通，数据团队想的是口径能不能统一。这四个诉求，指向的其实是四种完全不同的改造。
所以我

传统 ESB 这几年在我经手的项目里，出现频率肉眼可见地往下掉。不是这东西坏了，是它服务的那个世界变了。十年前我们把集成这件事押在一条\”总线\”上，所有系统都往中间接，接口注册、消息路由、协议转换、服务编排全压在同一个重型组件里。那时候系统数量少，接口变更慢，一条总线管得住。现在的情况是：一个中大型集

我干这行十来年，从写 ETL 脚本起家，后来做集成架构，现在更多是帮客户做规划。有个感受一年比一年强：集成这件事，国内的现场和教科书讲的完全不是一回事。教科书讲松耦合、讲服务编排、讲标准化接口，现场讲的是\”这个客户编码到底以谁的为准\”。工具没选错，照样能拖三年。
我判断一个集成项目能不能立住，很少先

我在数据平台这条线上做了十一年，前六年做实施，后面做架构咨询，接触过的 API 项目少说也有几十个。这几年的一个明显变化是：以前客户问的是\”接口能不能通\”，现在问的是\”这个接口的数据谁负责、口径谁定、变更怎么通知调用方\”。问法的变化，说明 API 已经从技术交付物变成了经营资产。我的判断很直接：AP

我做企业集成和治理这十来年，最怕听到的一句话就是\”我们上了一个混合集成平台\”。因为每个人说这句话的时候，脑子里想的根本不是一回事。做运维的想的是本地机房和公有云怎么打通，做数据的想的是十几个源系统怎么汇到一起，做业务的想的是手机上的审批能不能实时看到 ERP 里的库存。这三种诉求，被同一个词装进去了

我做数据集成和数据治理这条线十几年，经手的连接器项目少说上百个。真正拖垮项目的往往不是那些连不上的数据源，而是连上了却没人敢动的连接器。两个星期接完二十个源，验收报告写得很漂亮；半年之后业务要用数，没人说得清一张表里的字段从哪来、口径是什么、谁在什么时候改过。再回头收拾，成本是当初的三倍不止。这篇文

API网关这四个字，这几年被讲得有点满。我做过十来个企业级集成和数据平台项目，见过把网关画成统一入口的架构图，也见过网关上线两年只挂了不到八十个接口、后面没人维护的真实情况。我的判断一直没变：网关的价值不在\”转发\”，而在\”把策略收口\”。如果只是做域名转发和反向代理，Nginx 这种基础组件就够用了，

我这些年接过不少 API 治理的活儿，有从零搭起来的，也有接手别人留下的烂摊子。被问得最多的一个问题就是：API 管理到底管什么。很多团队的第一反应是买个网关，把接口挂上去，配上限流和鉴权，然后就跟我说做完了。实际跑下来，这完全是两码事。
我的判断是：API 管理的核心，是把散落在各个业务系统里的接