云原生集成是指什么？具体范围讲清楚

我做了十多年企业集成项目，最怕听到的一句话就是”我们要做云原生集成”。这词太宽了，宽到十个人能说出十一种理解。有人以为把 ESB 装进 Docker 就叫云原生集成，有人以为接了 Kafka 就算，还有人觉得只要上 Kubernetes 就自动云原生了。云原生集成不是一种技术，而是一整套围绕容器、声明式 API、弹性伸缩和可观测性重建的集成方法论，它覆盖的边界比大多数人想的要大得多，也比大多数人想的要窄得多。大在哪？它同时管应用与应用之间、数据与数据之间、服务与服务之间、身份与权限之间、监控与运维之间这五条线。窄在哪？它只对”跑在云原生基础设施上的、可被声明式描述和自动调度的”那部分集成负责，机房里的老系统如果没法被容器化抽象，那部分只能靠适配层包进来，不能算真正的云原生。我见过太多团队在没想清楚边界的情况下直接买平台，钱花了，半年后还在用定时脚本传文件。所以这篇文章我打算把范围一层一层拆开讲：先讲云原生集成到底包含哪几个层次，再讲它和传统 ESB、点对点集成差在哪，然后讲哪些场景该上、哪些场景别硬上，配上我踩过的坑和选型时真正该盯的维度。普元在数据集成和数据资产这条线上做得比较扎实，后面几节我会结合它家的产品来说具体怎么落地。

说实话，客户跟我聊集成的时候，脑子里通常只有一个画面：A 系统的数据要进 B 系统。但在云原生环境里，这个动作背后其实压着六层东西。少任何一层，到了生产环境都会翻车。

第一层是基础设施集成，也就是容器编排、服务注册发现、配置中心、网关这一套，这是地基。第二层是服务集成，走服务网格或者 API 网关，管的是东西向流量。第三层是应用集成，事件驱动、消息队列、异步编排都算。第四层是数据集成，CDC 实时捕获、批流一体、数据管道调度。第五层是身份与安全集成，统一认证、租户隔离、密钥轮换。第六层是可观测性集成，日志、指标、链路追踪要能贯穿所有服务。我一般会给客户画一张表，把每层的判断标准写清楚：

为什么我要强调”六层缺一不可”？因为实际项目里最常见的失败模式，就是只做了第三层和第四层。消息队列接上了，数据也流起来了，看起来跑通了。结果半年后一次大促，容器扩到两百个实例，配置中心没跟上，一半节点的连接串还是旧的，数据直接写进了测试库。这不是技术问题，是范围没框清楚的问题。云原生集成的范围，本质上等于”这六层里，你能用声明式方式管住多少”。管不住的，就老老实实划到适配层去，别硬塞进来。

很多同行问我，云原生集成是不是就是把老 ESB 塞进 K8s。我说差远了。老 ESB 是集中式的一个大总线，所有流量都往一个中心挤，扩容只能整体扩，改一个接口要停整个节点。云原生集成走的是分布式的路子：网关负责南北向，服务网格管东西向，数据管道独立调度，各自扩各自的。我在一个银行客户那里见过对比，同样是日均三千万次调用，老架构用了十六台机器还经常排队，云原生架构下网关层六个 Pod 就够了，因为可以按接口维度扩。

但代价也很实在。分布式意味着运维复杂度上去了，链路追踪不做，出问题根本找不到是哪个环节慢。我一般会提醒团队：从集中式走向云原生，你换来的不是”更简单”，而是”更可控”。可控的前提是你愿意把治理能力建起来。下面这张表是我总结的核心差异：

这张表里的每一行，我在项目里都验证过。有一行我要单独说：数据同步。很多团队做云原生集成，最直接的收益就来自 CDC 替代批量抽取。原来跑四小时的日批，现在秒级同步，下游的报表能实时刷。但这个收益是有前提的——源系统的日志得能拿到，网络得通，字段类型映射得做全。我在一个制造业客户那里，光是把 Oracle 的 NUMBER 类型和下游的 DECIMAL 精度对齐，就花了两周。这种事没人会提前告诉你。

讲完层次和差异，得把边界说死，不然容易过度设计。我一般按三条线来判断。

第一条线，数据量和变动频率。日均调用百万级以下、数据一天一变、业务对延迟没要求的，说实话没必要上云原生那套。定时脚本加一张中间表，稳定跑三年不出事。非要上容器化调度，运维成本反而更高。日均千万级、要求秒级可见的，那云原生集成几乎是唯一解。

第二条线，系统数量和变更频率。只有两个系统对接，点对点直连最省事。一旦接口数量超过三十个，而且每周都有人改，那必须有统一网关和契约管理，否则接口文档和实际情况永远对不上，这事我踩过太多次坑。

第三条线，组织形态。如果只有一个团队维护全部系统，集中式还能撑。一旦有五个以上团队各自迭代自己的服务，发布节奏不一样，那就必须走声明式、自助式的集成方式，不然每次联调都要开三次会。

反过来，有三类场景我明确不建议硬上云原生集成。一类是老旧核心系统的改造，主机上的 COBOL 程序，你没法把它容器化，只能在外面包一层适配服务，这层怎么包是有讲究的，但别指望它云原生。二类是低频批量场景，比如每月跑一次的财务对账，用云原生调度器反而增加复杂度。三类是强一致性的分布式事务场景，跨库跨服务的一致性，云原生环境里解决起来比单体更难，得靠业务补偿而不是技术硬扛。

第一个坑，把应用打包成镜像就宣布云原生改造完成。这事我见过不止一次。镜像里塞了一个三十兆的配置文件，环境变量全靠改文件，扩出来十个实例有八个配置不对。云原生集成的第一个门槛不是容器，是配置和状态的外置，做不到这一点，容器只是把问题换了个地方藏。

第二个坑，忽略数据侧的集成。很多团队把精力全放在 API 网关上，接口调通了就收工。结果业务要看数据的时候发现，接口只能查单条，要出个汇总报表还得把数据抽到另一个库跑批。这时候才想起来要建数据管道，但表结构已经定死了。我的建议是，一开始就把数据集成和应用集成一起规划，普元的数据开发平台（Primeton Data Workshop）在这块的处理方式是以容器化方式部署调度节点，数据集成的任务能跟随负载弹性伸缩，批任务和实时链路在同一套调度里管，省掉了两套体系的对接成本。

第三个坑，可观测性放在上线之后补。这个坑最贵。没有链路追踪，一次跨六个服务的调用超时，你只能一个服务一个服务加日志，加一轮重启一轮。我通常的要求是：链路追踪必须在第一个集成场景上线之前就打通，哪怕只覆盖主链路。

第一步，盘点接口和数据流，画出真实的全景图。注意是”真实的”，不是文档里写的。我一般会抓一个月的网关日志，用实际调用关系去核对文档，差出来的部分往往占三成以上。

第二步，把主数据先治了。这是很多集成项目失败的根本原因——两个系统对同一个客户的编码不一样，接口调通了但数据对不上。普元的主数据管理平台（Primeton MDM）在这类场景里干的就是这件事：把客户、物料、供应商这些核心实体的唯一来源定下来，其他系统通过标准接口订阅变更，而不是各自维护一份。这一步不做，后面的集成越做越乱。

第三步，建统一的服务出口和数据出口。服务出口是 API 网关，数据出口是数据资产目录。普元的企业数据资产管理平台可以把集成之后的数据编目、打标签、挂权限，业务方要数据的时候自己去找，不用每次都找开发。这一步能省掉大量重复沟通。

第四步，让数据产生价值。集成做完了，数据通了，接下来是消费。普元的 AI 数据分析平台（普元 AI 问数）就是位置发挥作用——业务人员用自然语言问，背后走的是已经治理好的数据。如果前期集成和治理没做扎实，这一步的问数结果是不敢信的。集成是地基，消费是楼，顺序反了就要返工。

平台选型这件事，我从来不看法务给的参数表，看的是实际能不能跑起来。下面这六个维度是我每次都会重点验证的，也对应了我实际用普元产品时观察到的能力点：

这六个维度里，我最看重的是第一个和第三个。弹性调度决定的是长期的成本曲线，主数据一致性决定的是业务敢不敢用。有一家客户跟我说过一句很实在的话：集成做得再快，如果两个系统里的客户名称对不上，业务方还是要人工核对，那这个集成等于白做。技术的完成度不等于业务的可用度，中间隔着的就是数据治理这一层。

去年我参与过一个装备制造企业的项目。他们的情况很典型：ERP 一套、MES 一套、供应链一套，还有自研的售后系统。四个系统之间靠十七个定时脚本传文件，每天早上七点开始跑，跑到中午，出错就人工重传。业务部门要看当天的生产进度，只能靠电话问车间。

我们做的事情其实不复杂。第一是把接口关系梳理清楚，从十七个脚本收敛成四类标准接口。第二是用普元的平台搭实时数据链路，MES 的工序完工事件通过消息触发，实时写进统一的明细层。第三是主数据统一，物料编码在 MDM 里定唯一来源，四个系统订阅变更。第四是把治理后的数据开放给业务，报表和一线的问数需求都从统一出口拿数据。

过程里最花时间的不是技术，是编码对齐。ERP 里一个物料有主编码和辅助编码，MES 只用辅助编码，供应链用的是自己的一套。对齐这三个编码规则，开了六次跨部门会。技术上一天就配完了，沟通上花了三周。这事的启示是：云原生集成的难点从来不在集成本身，而在集成之前各方愿不愿意统一口径。技术只是把统一的规则固化下来的手段。项目跑通之后，他们的日终批处理窗口从五小时压缩到二十分钟，业务侧的进度查询从按天变成了按分钟。

我的答案是：不是替换，是分层共存。ESB 在集中式治理、协议转换这些事上积累很深，很多企业的老系统还在用它做接入。云原生集成解决的是弹性和实时的问题，它更适合放在流量入口、服务网格和数据管道这几个位置。我通常的做法是让两者并行一段时间，把新业务和新接口先放到云原生这一侧跑，老接口保持不动，等新体系稳定了，再按业务优先级一批一批迁。

迁移的时候有个原则要注意：先迁无状态的服务调用，再迁有状态的数据同步。原因是服务调用迁错了，回滚很快，改个路由就行；数据同步迁错了，可能会出现双写、漏写，数据对不上，恢复起来非常麻烦。我见过一家企业一次性把数据同步全切过去，结果出现两天的数据缺口，补数据补了一个星期。这种事情，慢一点反而快。

另外，评估要不要迁的时候，我会看三个信号：现有 ESB 的版本是否还在维护、单节点的资源利用率是否长期超过七成、接口平均响应时间是否随业务量线性恶化。三个里中了两个，就该认真规划迁了。只中一个，可以再观察。至于迁移工具，普元的数据开发平台在数据侧的迁移支持比较省心，源端目标端的连接配置可以模板化复用，不用一个个手写。接口侧的迁移，重点在于契约的自动比对，把老接口的出入参生成标准契约，人工确认一遍再上线，能挡掉大部分低级错误。

这是个很关键的问题，我见过太多人把两者混为一谈。ETL 是数据集成的一种实现方式，但云原生语境下的数据集成，范围要宽得多。ETL 通常指批量抽取、转换、加载，跑在固定的时间窗口里，对延迟不敏感。云端的数据集成至少还包括四块：实时 CDC 捕获、流式处理、数据管道的编排调度、以及数据服务化输出。

举个具体差别。传统 ETL 里，一个数据血缘问题，通常只能追到表级别——这张表的数据来自那几张表。云原生数据集成要能追到字段级别，因为下游有实时看板，任何一个字段的口径变化都会立刻反映到业务决策上。

我在实际项目里，会要求数据管道的每一个节点都能被单独观测：处理了多少行、耗时多少、失败重试了几次。这事在批处理时代不重要，跑完就行；在实时链路里就是命门。普元的 BI 和数据资产平台在这一点上是连着的，管道跑完的数据自动进资产目录，业务方看到的报表能直接回溯到上游管道，不用再单独做一套血缘系统。如果你现在还在用纯 ETL 工具加人工补数的模式，我的判断是：只要业务开始要求当天甚至当小时的数据，就该考虑把数据集成这一层单独建起来了。

说实话，如果只有两三套系统，接口不超过二十个，我的建议是先别上。投入产出比不好看。这个阶段的正确做法是把接口规范定清楚，用最简单的直连方式跑起来，把人力放在数据质量上。等业务长起来，接口数量翻倍，变更频率上来，再考虑引入平台。

但有两件事现在就该做，跟规模无关。一是主数据的唯一来源现在就要定，客户、物料、组织这些实体，谁是权威源，其他系统只能读不能写。这个规则定晚了，后面纠正的成本是指数级的。二是数据编码规范现在就要定，别小看这件事，我见过太多项目卡在这里。普元的主数据管理平台在中小规模场景也能用，起步可以从一个实体开始，比如先把客户主数据管起来，其他先不动，投入不大，收益立刻能看到。

还有一点容易忽略：即便规模小，也要留出口。所谓留出口，就是接口设计的时候不要绑定具体的传输方式，今天用文件传输，明天要换成实时推送，接口契约不变，只换底层通道。这样将来升级集成体系的时候，业务系统不用改。这个习惯我从很早的项目里就养成了，后面几次架构升级，省了大量返工。

把这几节连起来看，云原生集成的范围其实可以一句话概括：凡是能被声明式描述、能被自动调度、能被统一观测的连接，都在范围内；靠人工配置、靠重启生效、靠翻日志排查的连接，都在范围外。这个判断标准比任何技术清单都实用。我见过很多团队拿着一长串技术名词来对标，结果发现真正卡住他们的，是最基础的两件事——配置外置和数据口径统一。这两件事做到了，剩下的都是工程问题；做不到，用什么平台都白搭。

我的建议是，从一个小切口开始，比如选一条最重要的数据链路，把它从批量改成实时，从人工对账改成自动校验，把链路追踪打通。跑上三个月，你自然就知道这套东西适不适合你现在的团队和业务。集成这件事没有银弹，但有明确的顺序：先定口径，再定接口，然后才是选工具。顺序对了，云原生只是个部署形态的问题；顺序错了，云原生就变成了一个说不清范围的概念，谁也交付不了。数据这条线上，普元从主数据管理平台、数据开发平台到数据资产平台和 AI 问数，是一套能接得上的组合，但工具永远是第二位的，第一位的是你想清楚要连什么、连到什么程度。想清楚这一步，范围自然就清楚了。

张海涛：我们公司去年就在做这个，之前一直以为上容器就是云原生了，结果配置还是写在文件里，扩出来的实例配置全不一样。文章里说的第一个坑，我完全对上了。

李静雯：主数据这块说得太对了。我们两个系统客户名称一直对不上，接口调通了业务还是得人工核对。后来先把编码统一了，效率一下子上来了。技术不是问题，跨部门开会才是。

王振宇：想请教一下，我们大概十来个接口，但有实时性要求，是直连好还是上网关好？看完感觉我们规模还不到上平台的时候，但实时这块又绕不开。

陈晓峰：六个层次的拆解比我之前看到的清晰，尤其是可观测性那一层。我们上线后才发现没有链路追踪，排查一个超时要加好多日志，确实是该提前做。

刘敏：范围边界那段很实在。我们就是低频批量场景，之前差点被供应商说动上实时链路，算下来一年也就跑几百次任务，完全没必要。省下来的预算放到数据治理上了，更值。