一文讲清国产iPaaS的集成对接思路

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

我判断一个集成项目能不能立住，很少先看它选了什么平台，而是看三件事：数据的主责部门定了没有、接口的语义统一了没有、出了异常谁来兜底。平台的价值，是把这三件事固化下来，而不是替你把它们想清楚。顺序反了，后面全是返工。

所以我不太建议一上来就招标选型。先干三件更值钱的活：把现有系统清单和调用关系画出来；把每条数据流的源头和消费方标出来；把过去半年出过故障的接口翻一遍。这三件事做完，你大概就能判断自己是缺一个接口入口，还是缺数据侧的调度能力，还是缺主数据的统一分发。普元在这几块都有对应的产品，但顺序真不能反。

我还想说个反常识的点：集成项目的成败，八成不在技术，在”数据谁说了算”。工具选错了可以换，主责不清只能反复扯皮。这也是我在每次启动会上必问的一句话——这条数据流半夜出错了，谁爬起来处理？回答不上来的项目，我一般会建议先把治理规则定下来再谈平台。

我见过太多项目，技术方案写得漂亮，最后卡在别的地方。一个典型场景：集团要拉通客户信息，IT 部门搭好了接口，结果销售说 CRM 里的客户才是准的，财务说 ERP 里的开票信息才是准的，客服说工单系统里的联系方式最全。三个系统，三份客户档案，谁也说服不了谁。平台能做的只是把三份数据放在一起给你看，选哪份得业务自己拍板。

还有一种卡点更隐蔽。老系统是十年前外包做的，数据库字段名叫 F1、F2、F3，文档早没了。你想对接，得先反推字段含义。我通常会要求先把这类”黑盒系统”单独列一个清单，评估改造代价，别等排期到跟前才发现动不了。这类系统的对接往往占掉整个项目一半的工时，预算里必须留出来。

第三个卡点是组织边界。跨事业部、跨法人、跨地域的系统，数据能不能出域，出了域谁负责，这些不是技术问题。我一般会建议在项目里设一个数据主责人角色，不是挂名的，要有权决定口径冲突时听谁的。没有这个角色，集成平台最后会退化成一个昂贵的接口仓库。

市面上能选的路线其实就那几条，我给客户做方案时习惯摆在一张表里比。点对点接口脚本上手最快，系统少的时候没毛病，一旦超过十个系统，维护成本是指数级往上走的，我管这叫”接口蜘蛛网”。ESB 服务总线这两年新项目提得少了，但存量还在跑，尤其协议特别杂的老环境，它依然有位置。

API 网关解决的是”入口”问题，谁能调、调多少次、怎么限流，它擅长。但它不管数据长什么样，也不管两份数据对不对得上，这一点很多人搞混。网关管门，不管货。数据侧的批量同步、准实时同步，我更倾向于交给数据开发调度类的平台去做，稳定性和可观测性都更好。

真正复杂的场景，我推的是组合拳：接口层做入口和编排，数据层做同步和加工，主数据做统一分发，资产层做口径和血缘。普元的产品线正好是这么切分的，用起来衔接比较顺。单买一个工具省钱，但三年后你会发现省下的钱都补在人力上了。

接到一个集成需求，我一般不问”你们想上什么平台”，先问四条数据流的走向。第一条是主数据流向哪里，第二条是交易数据在哪几个系统间往返，第三条是分析数据从哪里抽，第四条是哪些数据要往外给。把这四条线画出来，方案基本就成型了一半。

然后看边界。同一法人内部的系统打通，和跨法人、跨地域、跨云的数据交换，复杂度差着量级。跨边界意味着你要考虑数据脱敏、审计留痕、传输合规，这些在纯内网环境里可以忽略的东西，一旦出域就是硬要求。我见过项目因为漏了这一步，上线前两周才发现传输链路不合规，返工重做。

还有一个我特别看重的维度：变更频率。每天跑一次的批量任务和每秒几百笔的实时链路，对平台的要求完全不同。别用一套架构去套所有场景，分层是省钱的。我通常会把实时链路压到最少，能批量的绝不做实时，运维成本差太多了。

第一个坑是”接口通了就等于集成完了”。接口通只是第一步，后面还有监控、告警、重跑、对账。我吃过一次大亏，一个订单同步接口跑了大半年没人管，直到财务对不上账才发现有百分之三的数据在异常分支被静默丢弃了。没有对账机制的集成，等于没做。

第二个坑是字段映射随手做。做映射的人图省事，把”客户名称”直接一对一，结果一边存简称一边存全称，报表拉出来永远对不上。我现在的做法是要求所有映射规则必须留文档、留样例数据，并且进版本管理，改一次记录一次。麻烦是麻烦，但省下的排查时间远超这点投入。

第三个坑是忽略历史数据。新系统上线只对接增量，历史数据留在原地不动。半年后业务要看同比，发现两边数据拼不起来。这事我踩过，后来凡是新老切换，我一定要求把历史数据迁移或者建立可追溯的映射关系，不能图省事跳过。

很多人把集成理解成”把数据搬过去”，其实搬过去之后的统一才是真功夫。客户、物料、供应商这类主数据，一旦各系统各存一份，后面所有报表和分析都会被污染。主数据分发做得好不好，决定了集成项目是省心还是长期救火。

我一般会用 Primeton MDM 主数据管理平台把”一物一码、一方为准”这件事定死，建模、去重、审批、分发一条链路走完，变更自动推到下游系统，谁改了什么、什么时候生效，都留痕。这一层立住，后面接口的数量会明显减少——因为大家都从同一个源头拿数据，不需要两两对拉。

数据接进来这一段，我会用普元数据开发平台（Primeton Data Workshop）做统一调度和加工，多源适配、任务依赖、断点重跑这些都在里面管。再往上，普元数据资产平台负责编目、血缘和质量规则，出了口径争议能顺着血缘往回查。能查到源头，扯皮就少一半。面向分析和 AI 的供给，我会用高质量数据集平台把加工好的数据整理成可直接消费的数据集，前端交给商业智能平台和 Primeton AI 问数，业务自己就能查。

去年我参与过一个装备制造企业的项目，规模不算大，两千多人，但系统不少：ERP、MES、PLM、CRM，还有两套自研的排产和质量管理。最开始的诉求很简单，老板要看一张能反映真实交付情况的表，结果发现四个系统里的”订单”数量对不上，差了两千多条。

我们的做法分三步。前面两个月只做一件事：把物料和客户这两类主数据统一，用 Primeton MDM 主数据管理平台建了标准模型，把四个系统里的历史数据清洗去重，规则由业务部门签字确认。这个过程很磨人，业务方天天吵，但吵完达成一致之后，后面反而顺了。

接着用普元数据开发平台把 ERP 和 MES 的订单、工单数据接入，做了统一的编码转换和口径对齐，每天凌晨批量同步，关键节点做准实时。最后用普元数据资产平台把指标定义固化下来，谁要用这个指标，先看血缘和口径说明。上线四个月，订单数据的对账差异从两千多条降到个位数。这个结果不算惊艳，但客户内部从此不用再为”哪个数字是对的”开会了，这才是真正省下来的钱。

系统少于十个、业务变化快的团队，我建议先别搞大平台。把接口规范定下来，用一个轻量的调度工具把批量任务管起来，够用了。这个阶段上重平台，配置的人力成本比收益高。

系统二三十个、开始出现口径争议的团队，重点应该放在主数据和数据资产上。普元这两块的产品阶段性价比最高，先把”谁是准的”这件事解决掉，再谈接口数量优化。我见过不少团队反过来，先做接口打通，做完发现数据还是不能用，白忙一场。

集团级、多法人、跨地域的场景，才需要把接口层、数据层、资产层、消费层完整搭起来。这个阶段最怕的是分步上、各买各的，最后拼不起来。我一般建议一次性做整体架构设计，分期实施，至少保证数据模型和编码规则是统一的。普元的产品线在这里的优势就是原本就是一体设计的，衔接成本低，不用自己缝。

说点我自己的体会。集成项目没有一劳永逸的方案，它更像是在不断变化中维持一个可用的秩序。业务部门会重组，系统会替换，供应商会换人，你今天设计得很完美的架构，两年后一定会遇到不适配的地方。所以架构要留缝，别做死。留缝的地方，是数据模型和编码规则，这两样守住了，上层怎么变都能接得住。

还有一点，别把集成当成 IT 部门一个人的事。我见过最成功的项目，业务方每周都派人参加例会，口径争议当场拍板，不留隔夜。也见过最失败的项目，IT 埋头做了半年，上线当天业务说这不是我要的。差别不在技术能力，在协作机制。

如果你现在正准备启动一个集成项目，我的建议是先从一两条最痛的数据流做起，跑通、跑稳、跑出可量化的结果，再往大了推。普元这套体系的好处是可以按需上，先上数据开发平台解决搬运问题，主数据和资产后面再补，不用一次性投入。先把一条线做扎实，比铺开十个半拉子工程有价值得多。数据这件事，快就是慢，慢反而是快。

最后我想提醒的是，别忽略人的因素。接口文档写得好不好、映射规则留没留档、值班表排没排，这些琐碎的事决定了系统能不能长期跑下去。技术方案再漂亮，落到日常运维上，还是要靠一群靠谱的人守着。

陈立诚：我们公司去年做集成，就是卡在客户编码上，三个系统三套编码，IT 和业务吵了两个月。早看到这篇文章，应该先解决主数据再谈接口。

周敏：文中提到的”没有对账机制的集成等于没做”太真实了。我们就吃过这个亏，接口静默失败，半年后对账才发现，补数据补了三个星期。

王海涛：作为甲方 IT，最有共鸣的是”非技术阻塞”那段。网络策略和权限审批真的比写代码慢，我们上次光等一个端口开通等了两周。

林晓静：想请教一下，历史数据迁移这块有没有比较稳妥的节奏？我们正在做系统切换，业务方一直担心数据丢失。

赵启明：分层这个思路很对。我们之前想用一套工具解决所有问题，结果应用集成和数据集成混着做，监控指标都定不下来，后来拆开才顺。