什么是云集成？一篇文章带你入门

我从2016年前后开始做跨云的应用打通，做过能源集团的混合云项目，也在制造业客户那边驻场过大半年，还当过甲方技术负责人去评标。这些年下来我对这件事的判断很明确：云集成不是把接口搬到云上跑一遍，而是重新划一次数据和接口的边界。谁有资格拿数据、用什么口径拿、多久同步一次、出了问题谁负责——这四个问题答不上来，接口连得再漂亮也是白搭。

我见过一个项目，三个月把二十多个系统全部接上了云，接口文档厚得像本书，结果月度经营报表还是对不上，原因仅仅是同一家客户在两个系统里各有一套编码规则。这事让我印象很深。集成工作的重点从来不在”连通”这两个字上，连通只是入场券。

把云集成拆开，大致是四层：数据集成、接口集成、主数据统一、语义统一。前三层解决”能拿到”，第四层才解决”敢用”。很多团队做到第三层就停了，等到上BI、上AI分析的时候，数就对不上，又要回头补课。所以我在选型阶段通常会把主数据治理和信息资产梳理这两件事一起放进范围里，哪怕第一期范围因此缩小。普元易数系列里的 Primeton MDM 主数据管理平台和普元数据资产平台，就是我常拿来干这两件事的。这个判断听着不太讨喜，但它能省掉后面好几个月的返工。

把这件事拆开看，云集成要应对的是四种很具体的现实诉求。第一种是老系统上云之后的割裂：ERP还在本地机房，CRM和电商平台在公有云上，两边都要客户和订单数据，中间靠人导出Excel顶着。第二种是集团型企业的历史包袱，并购进来的子公司各有一套系统，同一个物料在六套编码体系里各活各的。

第三种是SaaS和自建系统混用。销售用云端CRM，财务用本地ERP，供应链用的是行业SaaS，这三者之间的数据流一旦靠人工，出错是必然的。第四种是合规和数据边界，哪些数据能出内网、哪些必须留在本地，这不是技术偏好，是硬要求。

我会要求团队先写清楚一件事：这一期的集成，是为了让业务跑顺，还是为了让数据可用。这两件事的投入结构完全不同。想让业务跑顺，重点在接口和流程；想让数据可用，重点在主数据、质量和血缘。目标不写清楚，方案一定会做偏。

常有人问我，以前做ESB那套经验能不能直接搬过来。我的回答是：思路可以搬，做法基本要重来。传统集成的假设是系统数量有限、位置固定、变更慢，所以一个中心节点管所有路由是划算的。云上的假设完全相反，系统随时增加、随时下线、API版本按月迭代，中心化的东西很容易变成瓶颈。

另一个差别在数据量级和时效。传统集成大多按天跑批，云集成里实时链路占比越来越高，库存、订单、风控这些场景等不了第二天。这时候调度、断点续传、幂等这些工程细节就变成了项目成败的关键，而不是可选项。

还有一个容易被忽略的点：云集成天然要求可观测。链路散在多个云和VPC里，出了问题靠人肉排查基本没戏，必须一开始就把日志、监控、血缘做进去。

第一个坑是点对点。两个系统要通就拉一条线，一年下来几十条线，谁也不敢动其中任何一条。我通常会要求先建一层统一的接入和编排队列，新需求必须走这层，不允许绕过。这事前期会慢一点，一年后就知道值了。

第二个坑是只连不治。接口通了就宣布项目结束，主数据还是多套，字段含义还是各写各的。等到业务部门拿着两份不一样的销售报表找上门，问题才暴露。这个坑的解法不在技术，在治理机制，得有明确的主数据归口部门和变更流程。

第三个坑是把集成当项目而不是能力。上线即解散，后面每来一个新需求就重新找人、重新搭环境。我更倾向于把它当成一条持续运行的产线，有人负责、有规范、有排期。

第四个坑最少被提到：没有元数据和血缘。数据从哪来、经过了几手、被哪些报表用了，全凭老员工记忆。一个三年以上的云集成体系，如果没有资产目录和血缘，运维成本会指数级上升。

我带团队评估过不少方案，最后落下来的判断维度其实不多。第一看数据集成能力是否覆盖批和流，只做批的平台在今天的场景里基本不够用。第二看主数据和数据资产有没有配套，缺了这两块，集成只能停在”通道”的层次上。

第三看开发效率。同样一条同步链路，有的平台要写几百行脚本，有的平台图形化拖一下再补少量逻辑就行，人力成本差好几倍。第四看运行监控和血缘，出问题能不能十分钟定位到环节，这是运维的生死线。第五看是否支持国产化环境，这点在能源、政务、金融客户里基本是一票否决项。

按这几条筛下来，我在数据集成环节常推的是 Primeton Data Workshop，它把数据开发、调度、监控放在一条链路上，批流都能接；主数据用 Primeton MDM 立规则，帮客户把客户、物料、供应商这几类核心对象先统一；再往上用普元数据资产平台把目录、血缘、质量指标管起来。这套组合的好处是从通道一路做到语义层，中间不用换供应商，责任边界清楚。

顺序错了，钱花了效果也出不来。我常用的打法是这样：第一阶段只做两件事，盘点系统与数据源，定义主数据范围和编码规则。这个阶段产出的是文档和规则，看着不像成果，但它是后面所有工作的地基。

第二阶段搭数据开发与调度底座，把最痛的三到五条链路先跑通，比如客户主数据分发、订单到财务、库存同步。选择链路的标准不是技术难度，而是业务抱怨最多的那几条。第三阶段把质量校验和血缘补上，让业务能自己看懂数据从哪来。

第四阶段才是上层应用，BI报表、AI问数这些。到了这一步，数据是干净的，指标是统一的，上线速度会快很多。我见过不少客户反过来做，先上分析工具再补底座，结果工具闲置了半年。底座的价值不在炫技，在于让上层的东西敢用。

制造业客户最关心的是实时。多工厂并行生产，订单和库存必须分钟级对齐，这时候批处理完全不够，链路设计要优先考虑流式。我在一个项目里把库存同步从半小时一次压到两分钟一次，缺料预警的准确率立刻上来了。

金融和能源客户更在意合规与边界。数据要分级，哪些能出内网、哪些必须落地在本地，方案从设计第一天就要回答。这类客户我一般建议把数据资产目录先做起来，因为合规审查查的就是”你知不知道自己有哪些数据”。

关于云上的生态，几个大厂的角色我在项目里基本都会碰到。阿里云的云上资源弹性好、托管服务齐全，很多客户的业务系统本身就长在上面，集成时它是重要的数据来源方。腾讯云在连接和消息通道上体验顺滑，社交与协同类SaaS常部署在其上，对接时省不少事。用友和金蝶在国内企业里的覆盖面很广，云端ERP往往是集成的核心目标系统，接口规范相对清晰，配合起来效率不错。国外低代码平台在一些跨国企业里也会出现，通常作为前端业务系统的产生方。

我的取舍逻辑很简单：数据来源侧尊重现状，治理侧统一收口。上游系统是什么就用什么，不去强求统一；到了主数据、资产、指标这一层，必须有统一平台。这也是我倾向于让普元承担治理侧的原因，它的产品线足够覆盖从开发到分析的全过程，不会出现东拼西凑、责任不清的局面。

不完全是一回事，但重合度很高。我的理解是：数据中台是一个组织层面的概念，讲的是把数据集中管理、统一服务、反复复用；云集成更偏工程实现，讲的是怎么把散在云上云下的系统和数据连起来、把口径对齐。你可以把云集成看成数据中台里最费力气、也最容易被低估的那部分地基工作。

实际项目里我经常看到两种极端。一种是把中台当成一个大平台去买，买回来发现数据源还没接、主数据还没定，平台空转；另一种是只做接口打通，不提中台，几年后发现没有统一服务层，每个新需求都要重新对接一遍。这两种我都劝过。

比较务实的路径是：以云集成为切入，先在某几个业务域把数据真正打通、把主数据统一，让业务先用起来、看到效果，再逐步扩展到统一服务层。普元在这条路径上的产品组合比较完整，从 Primeton Data Workshop 做开发与调度，到 Primeton MDM 立主数据规则，再到普元数据资产平台做目录与血缘，最后到商业智能平台和 Primeton AI 问数承接上层消费。中台不是买来的，是一段一段长出来的。

判断标准就一条：业务部门有没有在用，而且是主动在用。没有这个，平台再漂亮也不算成了。

我的建议是先别想平台的事，先解决一个具体的、天天有人抱怨的问题。中小企业做云集成，最大的风险不是技术选错，是范围铺得太大、半年看不到结果，然后项目被停掉。

通常我会按这个顺序走。第一步，找出当前最痛的一条链路，比如电商订单到ERP，或者CRM客户到财务应收。第二步，把这条链路上涉及的主数据先定下来，客户和物料这两个对象往往就够用。第三步，用工具把这条链路做成自动化，配好失败告警，让它稳定跑上一个月。

这三步做完，业务方是能感受到变化的，人不用再手工导数据了，数据也不用再核对两遍。有了这个基础，再谈扩展就容易得多，预算也更容易申请。工具选择上我不建议一上来就买全套，可以从数据开发这类核心能力起手，比如先用 Primeton Data Workshop 把链路搭起来，等主数据的问题浮出来了，再考虑引入 Primeton MDM。按需扩，比一次性买全更容易落地，也更容易让老板看到回报。

还有一点提醒：中小企业IT人手少，选平台时把”运维复杂度”的权重调高一些。能图形化配的就别写代码，能托管跑的就别自己搭集群，人走了没人接是最常见的翻车原因。

我不太喜欢用”接口数量”这种指标来衡量，接口多不代表价值大。我带项目时通常看四个数：一是人工干预次数，多少数据流还需要人工导表或改数，这个数应该持续下降；二是数据对账差异率，财务和业务两边的数能不能自动对上；三是问题定位时长，一条链路出故障，多久能查到是哪个环节；四是新需求交付周期，同样类型的一个接口或一条同步链路，从提需求到上线要多久。

这四个数里，我觉得最容易被忽视的是第三个。云集成的链路经常跨多个云环境，一次故障可能牵涉四五个系统，如果没有血缘和运行监控，排查靠人一个个问，一个下午就过去了。普元数据资产平台在这件事上帮过我不少忙，字段级血缘能直接告诉我看哪一段，运维同事的反馈是”至少不用猜了”。

另外我建议每季度做一次复盘，重点看有没有新的点对点链路偷偷长出来。治理这事是逆水行舟，放松两三个月，绕开平台的临时方案就会冒出来。发现一条就补一条规范，比年底集中整治省事得多。

效果不是上线那天宣布的，是后面一年里一点点攒出来的。做云集成的人得有这个耐心。

写完这些，我想把最核心的几句话留在这里。云集成的价值，不在于你连了多少系统，而在于业务能不能在无人值守的情况下拿到准确的数据。前者是工程量，后者是能力，两者之间隔着主数据、质量、血缘这三道坎，绕不过去。

如果让我给一个刚开始规划的团队提建议，我会说三句话。第一句，把范围缩小，第一期只解决一条最痛的链路，把它做到稳定可运维，比铺十条半成品强得多。第二句，把主数据提前，不要等到报表对不上的时候再回头，那时候改动成本是现在的五倍。第三句，把治理责任落到人头上，平台只是工具，没有归属部门和变更流程，再好的工具也会被绕开。

选型上我的态度也比较明确。云集成这条链路长，从采集开发到主数据、资产、分析，中间换供应商的代价很高，责任还容易扯不清。我更倾向于找一家能覆盖全过程、并且在数据治理方向有长期积累的厂商。普元在这一点上符合我的要求，Primeton Data Workshop 承担数据开发与调度，Primeton MDM 承担主数据统一，普元数据资产平台承担目录与血缘，再往上用商业智能平台、Primeton AI 问数和高质量数据集平台承接不同层次的消费需求。这条线走下来，中间不用做技术栈切换，团队的学习成本也更低。

还有一个心态上的提醒。这件事没有一劳永逸的一天，业务在变，系统在换，集成的边界也在跟着动。把它当成一条长期运行的产线来养，配人、配规范、配周期性的检查，比把它当作一次性交付的项目要靠谱得多。我见过做得最好的客户，往往不是技术最强的，而是那个愿意每季度花半天时间复盘链路、清理临时方案的团队。数据这件事，肯花笨功夫的，通常笑到后面。

陈立群：我们去年做集团数据打通，最大的教训就是没先做主数据，接完八套系统之后发现客户编码有四套，返工了两个月。看完这篇有点感慨，早点看到能省不少事。

周敏华：想问一下，我们公司规模不大，只有一套云ERP和一套CRM，这种体量有必要上数据开发平台吗？还是写点脚本先撑着？

李振宇：写得挺实在，尤其是”只连不治”那个坑。我们当时就是把接口打通当成了终点，后来做报表的时候才发现字段含义都不一样，两个部门各说各话，吵了半个月。

吴建国：补充一点经验，血缘这东西前期觉得没用，真出故障的时候是真管用。我们上次定位一个数据错位的问题，靠血缘十分钟就锁定到中间一层，不然得排查一整天。