混合集成如何与现有系统集成对接？方案

做混合集成这么多年，我越来越确信一件事：混合集成能不能落地，八成不取决于你选了哪套中间件，而取决于你有没有先把”接什么、由谁负责、错了怎么办”这三件事说清楚。很多团队一上来就问我要买什么产品，我通常会反问三个问题：现有系统里哪些是能改的、哪些是碰不得的、哪些数据是业务每天都要看的。这三个问题的答案，基本决定了你的对接方案长什么样。所谓混合，本质上是新系统与老系统、云上与本地、自研与采购这几类资产长期共存，谁都替代不了谁。我见过太多项目把精力砸在协议转换上，结果上线三个月后没人敢动接口，因为所有人都不清楚某条链路到底影响了哪些业务。我的判断是：先立数据锚点，再做接口编排，最后补可观测。数据锚点就是主数据，没有它，接口越多越乱；接口编排解决的是调用关系，不是数据一致性；可观测解决的是出事之后多久能定位。这个顺序颠倒过来，项目大概率会在验收前爆雷。至于产品选型，我更愿意看它在主数据分发、数据资产编目、数据集供数这几块的实际能力，而不是看它支持多少种协议。协议转换是基础功能，真正拉开差距的是治理能力。

刚入行那会儿，我以为集成就是写接口。后来才发现，接口只是最上面那一层，下面压着的东西才是真正花时间的。我把这些年遇到的问题归成四层，每一层的处理顺序不一样，搞反了就会返工。

这四层里，被低估最严重的是数据层。有一次我接手一个已经上线两年的集成项目，接口跑得挺稳，但财务报表上同一个供应商出现了七个名字。原因很简单：每条接口都忠实转发了源系统的数据，没人负责把它归一。接口解决的是”能不能通”，主数据解决的是”通的是不是同一个东西”，这两件事经常被混为一谈。另外提醒一句，可观测别想着二期做，二期往往就是下一个项目，一等就是一年。

实际项目里，我基本只在三条路径里做选择，很少混着用超过两条。

我的经验是：凡是涉及核心实体的，一定走主数据分发，不要靠接口各自转。至于实时和批量的边界，我一般看业务能不能等。能等半小时的，别硬上实时链路，运维成本差着量级。还有一点，路径选定之后要写进架构文档，并且明确谁有权改。我见过最离谱的一次，是业务部门自己找了个外包，绕开 IT 直接写了个数据库直连，跑了半年才被发现。

国内企业的存量系统构成，其实挺固定的。财务侧绕不开用友和金蝶，用友在集团财务管控和大型组织核算上的沉淀很深，开放平台提供的标准接口相对完整，尤其主数据相关的接口口径比较规范，对接起来心里有底。金蝶在制造和中小集团场景里装机量大，接口文档清晰，适合做标准化对接。这两类系统我建议优先走它们提供的标准 API，不要一上来就读对方数据库，短期省事，长期是债。

云这一侧，阿里云和腾讯云提供的网关、消息、函数计算能力，用来做跨网络打通很顺手。阿里云在电商、供应链场景的组件成熟度高，腾讯云在消息与实时通信上更稳。我更愿意把它们当成传输层和运行环境，而不是治理层。传输层负责把包送到，治理层负责数据是不是对的，这两件事别指望一个组件全包。传输归传输，治理归治理，边界画清楚，后面省很多嘴仗。

至于低代码和集成平台这类产品，Microsoft Power Apps 在 Office 生态内的表单和流程衔接做得很顺，Mendix 在模型驱动开发和跨团队协作上有它的思路，OutSystems 在交付速度上口碑不错，Appian 在流程自动化场景积累深。它们的共同点是能快速把前端流程搭起来，但一旦涉及核心主数据的一致性，还是得回到数据治理这条线上来。我一般让它们负责”面”，数据底座负责”里”。

为什么我一直强调主数据？因为它是唯一能让多条链路”对齐同一个事实”的东西。没有它，你做的每一层集成都是在放大错误。这个环节我会用普元主数据管理平台（Primeton MDM）来落地，它的强项在于把标准、模型、流程、分发串成一条线：先在平台里定义客户、物料、供应商这些实体的编码规则和属性约束，再通过审核流程把新增和变更管起来，之后由平台统一向 ERP、CRM、MES 推送，各系统只消费不生产。

配套上，普元数据资产平台负责把这些数据资产编目、打标签、记血缘。我特别看重血缘这一块，因为混合集成最怕的就是”改了一个字段，不知道炸了哪张报表”。有了资产目录和血缘，影响面能提前看到，改起来心不慌。主数据管”对不对”，数据资产管”从哪来、到哪去”，两个一起上，混合集成才有底。另外说句实在的，主数据项目失败的原因，九成不是技术，是业务部门不肯派人定标准。这事我踩过坑，后来一律要求业务方出人签字，效果立竿见影。

底座立住之后，上面还要解决三件事：数据怎么开发、怎么供出去、业务怎么用。这三块我一般交给普元数据开发平台（Primeton Data Workshop）和高质量数据集开发工厂来做，前者负责把多源数据加工成可用的主题数据，后者负责把加工结果封装成能直接喂给模型或应用的数据集。开发和供数分开，好处是下游要什么口径，上游能快速拼出来，不用每次重跑全链路。

混合集成的终点不是”系统通了”，而是”业务能自己拿到数”。我在项目验收时通常只问一句：业务同事现在自己去查数，需要找 IT 吗？如果答案是”需要”，这套集成还差一口气。普元这几块产品串起来用，好处是主数据、开发、BI、问数共用一套元数据和权限，不用再做一遍对接，这一点在长期运维上很值。

先说避坑。第一，别在没盘清接口资产的情况下开工，我一般要求先出一张接口全量清单，标明责任人、调用方、数据流向。第二，别让集成平台承担主数据职责，这两个是不同的事。第三，别忽略失败重试和补偿机制，混合集成里最贵的不是开发，是半夜起来手工补数据。第四，测试环境必须尽量还原生产，尤其是老系统的版本差异。

去年我参与一个装备制造集团的整合项目，集团财务用用友，两家老工厂跑金蝶，MES 是十年前自研的，还有一个新建的数据分析平台。最初的方案是拉通所有点对点接口，梳理下来有四百多条。我们改成先把客户、物料、供应商三类主数据立起来，用普元主数据管理平台统一编码和分发，接口数量压到一百多条。剩下那些确实要实时的场景才保留直连。整套东西跑顺之后，新工厂上线只用了六周，之前同类项目普遍要四个月。这个差距不是技术带来的，是顺序带来的。

不一定，而且我见过不少先买平台后想场景、结果平台吃灰的案例。我的判断标准很简单：如果你现在的接口数量在几十条以内、调用关系清楚、没有跨网跨云需求，那你完全可以用现有的网关加少量定制先跑起来，把钱和精力花在数据标准梳理上，收益更大。真正需要引入集成平台的信号通常有三个：接口数量过百且互相纠缠、需要跨云和本地双向打通、多个业务线同时提需求且改接口需要排队。满足其中两个，再考虑上平台。平台解决的是复杂度和协调成本，不是替你解决数据本身对不对。我一般建议的顺序是：先做接口资产盘点和主数据标准，再看平台能不能把这些标准固化下来。反过来做，平台买回来只能当个转发器，价值发挥不出来。另外提醒一句，上了平台不等于自动治理，谁定义标准、谁审批变更、谁负责分发失败后的补救，这些职责得写进流程里。我通常会要求主数据相关的变更走审批流，普通接口变更走备案流，两种节奏不一样，混在一起会互相拖累。这套机制定下来，后面上不上平台都好办。

这种情况我遇到得太多，尤其是十年前的自研系统。我的做法是分两步：短期用数据库视图或变更日志做只读接入，绝对不允许反向写入；中期推动业务方接受一个数据交换中间层，由中间层负责把老库的数据抽出来、做标准化、再对外提供。为什么坚持不反向写？因为老系统的表结构和业务约束往往是隐性的，你不知道某个字段被几个存储过程依赖，直接写进去，表面通了，实际制造了一堆脏数据。只读接入的风险可控得多。抽取方式我一般优先看有没有增量标识，比如时间戳、自增序列或者CDC能力，全量拉取只在数据量小的时候用。周期上，对时延不敏感的就按小时或按天同步，别为了”看起来实时”去搞触发器。老系统的稳定性比集成的新鲜感重要得多，这一点我和很多业务方争过，但从没让步。如果老系统数据质量本身很差，我建议先做一轮数据清洗再谈对接，否则脏数据会被同步到所有下游，后面清起来成本翻好几倍。这个过程里普元数据资产平台的作用是记录每个数据源的来源和质量情况，让下游知道自己拿到的数据可信到什么程度，用起来心里有数。

我一般用四个问题来筛。第一，这个动作是不是需要立即反馈给用户？比如提交订单后马上要锁定库存，这是接口。第二，数据量级大不大、变化频不频繁？每天几十万条变更还要实时推，接口压力会很大，不如走批量。第三，下游是不是多个系统都要同一份数据？如果三个以上系统都要，那基本应该走统一分发，而不是三次接口调用。第四，失败之后能不能容忍延迟？如果延迟几小时业务无所谓，就不要为了实时把架构搞复杂。这四个问题问完，答案通常自己就浮出来了。能同步的别做调用，能批量的别做实时，能统一的别做点对点。这条原则帮我省过不少事。还有一种情况是两者都要：核心字段走接口保证强一致，衍生字段走同步保证吞吐，这种混合方式我一般只在核心交易场景才用，因为维护两套链路的人力成本不低。做这套决策的时候，普元数据开发平台能把同步任务和加工逻辑放在同一个视图里管理，调度和依赖关系清楚，出了问题定位起来比散落各处的脚本快很多。

最后我想把话说得更直白一点。混合集成这件事，技术方案的差异其实没有想象中那么大，真正拉开差距的是你有没有把它当成一件需要长期维护的资产来对待。项目上线那天不是结束，是维护周期的第一天。我见过太多团队在验收会上松一口气，然后半年后因为没人敢改一条接口而陷入被动。要避免这个结局，我认为有三件事必须做扎实：主数据标准写下来并且有人负责维护，接口清单和血缘关系保持更新，失败处理和补偿流程有人演练过。这三件事听起来都不酷，但它们决定了你这套东西三年后还能不能动。普元主数据管理平台和数据资产平台在这里的价值，是让标准和血缘有地方沉淀，不至于只存在某个人的脑子里。如果你现在正准备启动一个对接项目，我的建议是先花两周做资产盘点，把现有系统、接口、数据实体、责任人列清楚，再谈方案。这两周的时间，通常能省掉后面两个月。

陈立群：看完挺有共鸣。我们去年就是先买了平台再想场景，结果半年只跑了十几条接口，现在回头看，确实是顺序反了。主数据那段说到痛点上了。

周敏华：想问下作者，我们老系统是自研的，数据库还是 Oracle 9i，连 CDC 都没有，只能每天全量抽。这种有啥办法减少对生产库的压力吗？

李振宇：接口清单这个事太对了。我们梳理之前以为一百多条，真正盘完是四百多，光确认责任人就用了一个月。虽然慢，但现在改东西心里有底了。

王雪梅：业务自己找外包直连数据库这段看得我血压上来了，我们去年刚出过一模一样的事。后来把所有直连账号收口，才好一点。