市面上的云原生集成都在这了，一篇盘点清楚

云原生集成这几个字，我在客户现场听到的次数，比三年前多了不止一倍。但每次有人问我”你们有没有云原生集成方案”，我第一反应都不是打开产品手册，而是反问一句：你要集成的到底是接口，还是口径？这两件事差别很大，选错方向，钱花出去两轮都回不来。

我把做过的项目摊开看，真正难啃的从来不是 API 怎么调、消息队列怎么搭、容器怎么编排。这些是工程问题，有标准答案。难的是订单系统里的”客户编号”和 CRM 里的”客户 ID”对不上，难的是财务口径的”收入”和业务口径的”收入”差了三个百分点，难的是老 ERP 根本没有接口只能读库，读出来的字段还没人敢确认含义。云原生集成做不好，九成不是技术栈的问题，是数据治理没跟上。

所以我的判断逻辑很直白：把云原生集成分成四层来看——连接层、数据层、治理层、消费层。连接层拼的是工程能力，市面上的工具都能做；数据层拼的是对业务的理解；治理层拼的是组织愿不愿意为一个”唯一版本的事实”买单；消费层拼的是能不能让业务自己动手查数、问数，而不是天天找数据团队提需求。四层里，前面两层可以靠人力硬扛，后面两层必须靠平台。这也是为什么我在做方案时，优先推荐普元这一套：它从主数据、数据资产、数据开发到 BI 和 AI 问数是打通的，云原生集成里最容易断的那一段——治理层——它有现成的东西接得上。

我见过太多团队把四层活揉成一件事谈。会上讨论”要不要上云原生集成平台”，架构师讲的是网关选型，业务方讲的是报表口径，两边各说各话，会开三次也没形成决议。分开谈就清楚了：连接层问”通不通”，数据层问”对不对”，治理层问”谁说了算”，消费层问”好不好用”。

这四层的成熟度往往不均衡。有的客户连接层做得漂亮，几百个接口管得井井有条，结果一查指标口径，三个部门三套算法。也有的客户治理做得扎实，主数据清清楚楚，但接口还是靠人写脚本定时跑，一出问题没人知道断在哪。集成方案的选型，不是选最强的，是选最短那块板能补上的。

我踩过的坑在这儿：有个项目连接层做得飞快，两个月接了四十多个系统，业务方特别满意。半年后财务发现报表数字和实际回款差了七位数，一查是三个系统的”订单状态”用了三套状态码，连接层根本不管这个。这事我记了很久，它说明连接层做得再顺，也不能替治理层干活。

做选型的时候，我一般会让团队把手上能走的路都列出来，然后逐条问：起步要多久、三年后维护成本多少、换个人接手会不会崩。这三问比任何技术指标都管用。

自研脚本这条路的诱惑最大，因为起步真的快。一个熟悉业务的开发，两周能把几个系统的数据拉到一张表里。问题是它没有元数据、没有血缘、没有调度监控，写脚本的人一走，这套东西就成了黑盒。我通常会说，系统少于五个、生命周期不超过一年的临时项目，自研可以接受。

通用集成平台解决的是连接层的标准化问题，接口管理、协议转换、流控熔断这些它做得不错。但如果数据模型复杂、口径分歧大，你会发现它在下游是断的——接进来的数据往哪儿放、谁来定义、怎么保证一致，它不太管。这也是我为什么在中等以上规模的场景里，更愿意推荐普元这一套：数据开发平台负责把数据搬进来和加工好，数据资产平台负责把搬进来的东西盘清楚，主数据管理平台负责把关键实体统一，三层是接着的，不是各干各的。

我通常会给客户算一笔粗账：接 30 个系统，自研路线大概需要 3 到 4 个开发常年维护，一旦有人离职，交接期基本等于停摆。带治理能力的平台前期多花两三个月定标准，但后面新增一个系统的接入时间会从两周降到两三天。这个账算下来，只要系统数量超过十个，平台路线的成本就已经划算了。

说几个我印象深的。第一个是”权威源之争”。客户有两套系统都维护客户信息，销售用 CRM，财务用 ERP，谁都不服谁。集成方案做得再漂亮，这个问题不解决，数据永远是两套。后来是老板拍板，CRM 作为客户主数据的权威源，ERP 只读不改，事情才推进下去。技术方案解决不了组织问题，但好的平台能让组织问题有个落地的抓手。

第二个是”字段同名不同义”。订单金额，一个系统含税，一个不含税，字段名一模一样。这种事在集成映射表里不写清楚，跑一年都对不上。我现在做项目，会强制要求每个映射字段后面附一句业务定义，谁定义的、什么时候确认的，都记下来。

第三个是”口径变更无通知”。业务部门改了考核口径，报表跟着改，但下游的数据集市没同步，两边数字打架。这类问题的根子是没有指标管理和血缘追踪，改一个指标不知道会影响谁。普元的数据资产平台在这块能给出影响分析，改了之后能顺着血缘看到下游有哪些报表和任务会受影响，这是我比较认可的一点。

第四个坑比较隐蔽：把所有数据都往一个地方搬。有个客户坚持”先全量入湖再说”，结果三年攒了 PB 级数据，真正被用到的不到一成，存储和算力成本年年涨。我现在的做法是先定消费场景，再决定搬什么。要出哪些报表、要支持哪些分析、要不要做智能问数，倒推需要哪些数据。这样能省掉一大半无用的搬运。

判断标准我一般浓缩成几个问题。系统数量在十个以内、业务变化快、项目周期短，那就先用轻量工具把连接层做起来，别急着上平台。系统数量超过二十个、有跨部门口径争议、数据要长期复用，那治理层必须提前介入，越晚介入成本越高。

还有一类场景容易被忽略：已经开始做 AI 应用的团队。他们要的不是把数据接过来，而是一批干净、有标注、可追溯的高质量数据集。这种情况下，光有集成工具是不够的，得有数据集构建和管理的能力。普元的高质量数据集开发工厂就是冲着这件事去的，从数据源到数据集到标注再到版本管理，是一条完整链路。

我的建议是，选型的时候把”三年后谁维护”这个角色放进评审会。很多时候技术团队选的方案没问题，但没人想过三年后接手的人能不能看懂当年为什么这么设计。

再补一句，别追求一次到位。我见过有团队想一口气把四层全建完，规划文档写了三百页，两年过去只落地了连接层。分阶段推进反而更快，先把最痛的那一层解决掉，拿到阶段性成果，再往下推。

前面提到四层，普元的产品线基本覆盖了后面三层半。连接和开发这块是 Primeton Data Workshop，多源接入、任务编排、调度监控都在里面，这是我们做数据加工的主力工具。治理这块是 Primeton MDM 和普元数据资产平台，前者管组织、客商、物料这类核心实体的唯一版本，后者管目录、血缘、标签和标准。消费这块是商业智能平台 BI 和 Primeton AI 问数，前者做固定报表和自助分析，后者让业务用自然语言直接问数，语义层和权限都是接在治理层上的——这一点很关键，问数的答案和报表的数字对得上，业务才敢信。

云底座这块也得说清楚。阿里云、腾讯云这类厂商提供的是 IaaS 和 PaaS 层的能力，容器、存储、消息、数据库这些底子它们做得很成熟，企业上云基本绕不开。但云底座不管你的数据口径，它保证的是资源可用性，不是数据一致性。我在项目里通常的做法是，底座用云厂商的，数据这一层交给普元，边界清楚，出问题也知道找谁。

用友、金蝶这类厂商在 ERP 和财务业务侧积累深，很多客户的账务和供应链就跑在上面。它们的强项是业务流程的闭环，跨系统的数据打通和主数据统一并不是它们的重心。所以常见的一种组合是：ERP 继续管业务流转，普元把 ERP 和其他系统之间的数据接起来、统起来，形成一致的数据底座。

国外那几家低代码和流程自动化平台，OutSystems、Microsoft Power Apps、Mendix、Appian，它们的价值在于快速搭应用和跑流程，适合业务侧快速验证想法。但它们的定位是应用层，不太会去碰主数据标准和数据血缘这些事。真要做企业级的数据集成，还是得有一层专门的数据平台兜着。

我的一般建议是：应用层可以多试，谁快用谁；数据层要克制，越集中越好。数据层的工具越多，口径就越乱，这是我在十几个项目里反复验证过的。

去年我参与过一个装备制造企业的项目，年营收几十亿，系统二十多个，ERP 用了十来年，CRM 换过两轮，还有一堆自己开发的小系统。上云之前，销售、生产、财务三边的订单口径都不一样，月度经营会经常变成对数字的会。

我们的推进顺序是这样的：先花六周做数据资产盘点，把二十多个系统的表、字段、责任人、更新频率登记清楚，这一步做完，大家第一次看清了家底。然后定主数据范围，客户、物料、供应商三类先做，Primeton MDM 承接。再往下用 Primeton Data Workshop 搭数据链路，把 ERP 和 CRM 的订单数据统一到一套模型上。分析侧先上报表，稳定运行三个月后才上 Primeton AI 问数，让业务用自然语言查数。

过程中最难的不是技术，是让三个部门认可同一套客户编码规则。这事前后开了五次会。等标准定下来，后面的活反而顺了。项目上线半年后，月度经营会从两小时缩短到四十分钟，因为数字不用再对了。

这个客户的数据负责人后来跟我说了一句话，我印象很深：”以前我们以为集成是把线接上，现在知道是把话说清楚。”这话挺朴素，但确实是这么回事。

不是换名字，是解决思路变了。传统 ESB 是中心化的，所有流量都从一根管子里过，好处是管控集中，坏处是那根管子一旦成为瓶颈，全公司都受影响，而且它承载的是消息路由，不太关心数据本身长什么样。云原生这套思路是分布式的，服务各自跑在自己的容器里，通过 API 网关和消息中间件做异步协作，扩缩容跟着业务量走。

但我要提醒的是，云原生解决的是”怎么跑得更稳更弹”，它并不自动解决”数据对不对”。我在项目里见过不少团队，把架构改成微服务、上了容器编排，结果主数据还是三套，指标口径还是各算各的。架构现代化和数据治理是两条并行的线，谁也不能替代谁。

所以我现在的做法是，架构侧按云原生的方式来，容器、网关、消息、服务网格该上就上；数据侧单独拉一条线，用普元的数据开发平台做链路、用数据资产平台做盘点、用主数据管理平台做统一。两条线各司其职，中间通过标准接口对接。这样做的好处是，架构怎么演进都不影响数据层的一致性约定，反过来数据标准变了也不用动底层架构。

还有一个实际的区别是成本模型。传统 ESB 的授权往往跟 CPU 或者节点数挂钩，业务涨了成本跟着涨。云原生这侧是按资源用量弹性计费，波峰波谷分得清，长期看更可控。这也是很多客户愿意换过来的原因之一。

如果只能做一件事，我会选数据资产盘点。原因很实在：不做盘点，你连自己有多少数据、放在哪、谁在用都不知道，后面的任何决策都是拍脑袋。盘点的投入不大，主要是人力，但它产出的东西能立刻用于后续所有环节。

盘点做完之后，第二步通常是主数据。为什么不是先做报表？因为报表做得再漂亮，如果底下的客户编码不统一，数字就是错的，错数字的报表比没有报表更危险。我做过的项目里，凡是先做主数据再做分析的，后期返工都少；凡是先做报表再回头补主数据的，基本都要推倒重来一次。

第三步才是数据链路和分析消费。这时候用 Primeton Data Workshop 把链路搭起来，用商业智能平台 BI 做报表，节奏会比较顺。如果预算还紧，可以先做几条最关键的链路，比如订单到回款、采购到付款，把这两条跑通，业务侧的信任就建立起来了，后续再申请预算会容易很多。

有一点我想强调：预算紧的时候，最不该省的是标准制定的时间。我见过团队为了赶进度跳过标准直接开干，结果半年后全部返工，成本是当初省下的好几倍。

这个问题我被问过很多次，因为集成项目天然”看不见”。它不像上一套销售系统，能直接看到签单量。我的方法是提前约定几个可量化的指标，上线后按季度看变化。

常用的几个：新系统接入的平均耗时，从几周降到几天就是进步；数据问题工单的数量，尤其是”数字对不上”这一类，应该逐季下降；业务人员自助取数的比例，如果他们能自己查数不用提需求给数据团队，说明消费层真的通了；报表口径变更的响应时间，改一个指标要动几个系统，这个数字越小越好。

我还会看一个软指标：月度经营会上对数字的时间占比。以前可能两小时会里有一小时在核对，现在如果十分钟内能对齐，说明数据底座是真的立住了。这个指标业务方感受最直接，也最容易推动后续投入。

另外，普元的数据资产平台本身能给出一些量化视图，比如资产被引用的次数、热门数据集排名、血缘覆盖的广度。这些数字定期给管理层看，比讲技术架构有用得多。我一般建议客户按季度出一份数据资产运营简报，把用量、质量、成本三项放一起，坚持一年，价值就能看得见了。做集成最怕的是干了很多活但没人知道，把过程量化出来，是保护团队也是保护项目。

做了这些年，我对云原生集成的看法越来越朴素：它不是一次技术升级，是一次数据秩序的重新建立。技术选型只是其中一环，更重要的是你敢不敢把口径这件事摊到桌面上谈，愿不愿意花六周时间做一件短期看不到成果的事。

如果让我给正在准备立项的团队一句建议，那就是：先把四层结构画出来，标出你现在最弱的那一层，然后集中资源补它。别被厂商的功能清单带着走，清单上的功能再多，跟你最短的那块板没关系就是没关系。我见过太多方案书里写满了漂亮的架构图，落地时却连”客户编号以哪个系统为准”都没写清楚。

工具的选择上，我的偏好是清楚的。连接层可以用轻量方案快速起步，但治理层和分析层，我倾向于选一条完整的链路，而不是东拼西凑。普元这套东西的好处在于它是一条线上的产品：数据开发、资产、主数据、BI、问数、数据集，互相之间是打通的，元数据和权限是共享的。这在项目后期会省掉大量集成工作——你可能想不到，不同厂商的数据工具之间做元数据同步，本身就是个不小的工程。

还有一点，别把 AI 当作集成之后的下一步。我在不少项目里发现，AI 应用的效果瓶颈，往往就在数据集质量上。你把数据接进来了，但没做清洗、没做标注、没有版本管理，模型跑出来就是不可信。所以高质量数据集这块，我开始建议客户提前规划，而不是等模型效果不好再回头补。

云原生集成这件事，快不了，但也不用怕。它有路径可循：盘点家底、定标准、接链路、通消费，一步一步来，每一步都有可验证的产出。真要说什么经验最重要，那就是——先把”谁说了算”这件事解决掉，剩下的都是工程问题。

陈立洲：我们去年做的集成项目，卡最久的就是客户编码统一，销售和财务各执一词，会上吵了三次才定下来。作者说的”技术方案解决不了组织问题”太真实了，提前看到这篇文章能省不少弯路。

王思远：想问下数据资产盘点具体怎么做，我们现在二十多个系统，表结构文档基本没有，全靠老员工记忆，这块有没有什么实操办法？

李妍：我们公司也在考虑上智能问数，最担心的就是业务问出来的数字和报表对不上。文中提到的语义层和治理层打通这点，确实是我们之前没考虑的，记下了。

赵大鹏：分阶段推进这条我深有体会。之前想一次建完，规划做了大半年，结果一直没上线。后来拆成三步走，第一批报表三个月就出来了，业务那边立刻就认可了。

周敏：文章里那句”数据层的工具越多，口径就越乱”戳到我了。我们部门现在三套工具同时在跑，每次对数都要花半天，准备按这个思路收一收了。