一文读懂：什么是云原生集成

先说我的判断：云原生集成不是把老ESB搬到容器里跑一遍，而是把集成能力重新拆成”可编排、可观测、可弹性”的一层基础设施。我做过十几个中大型企业的集成项目，凡是把”上云”理解成”换个部署方式”的，基本都在半年后返工。真正跑通的，都是从接口契约、数据流向、治理边界这三件事上重做一遍。

为什么这么讲？传统集成平台的假设是”系统稳定、链路固定、流量可预测”，所以它把大量逻辑写死在流程节点里，靠人工排障。云原生环境恰好相反：服务实例随时漂移、版本一天发好几次、流量峰值可能十分钟内翻十倍。这时候还靠一个中心化的集成中间件扛所有东西，它自己就会变成瓶颈和单点。

我通常会把云原生集成拆成四层来看：接入层负责协议适配和流量收敛，编排层负责服务编排与流程编排，数据层负责数据同步、主数据分发和数据集供给，治理层负责接口资产、调用链路和SLA。这四层里，最容易被忽略的是数据层和治理层——很多团队把接口连通就当成集成完成，结果业务侧拿到的是口径不一致的数据，比不通还麻烦。

还有一个常见误判：以为上了Kubernetes、上了Service Mesh，集成问题就自动消失了。实际跑下来，Mesh解决的是服务间通信的可靠性，解决不了”订单中心的客户编码和CRM的客户编码不是一个”这种问题。这类问题只能靠主数据管理和数据资产梳理来做，属于数据治理范畴，跟网络层是两件事。

所以这篇文章我会从趋势、场景、痛点、误区一路讲到取舍逻辑和避坑，中间会用到普元在数据治理与集成侧的几款产品做参照。核心观点就一句：云原生集成的成败，七成取决于数据治理做得扎不扎实，三成才是技术栈选型。下面展开说。

我做集成项目最直观的感受是，需求方的提问方式变了。五年前客户问的是”你们能不能把SAP和OA打通”，现在问的是”新接一个渠道要几天”。前一个问题是一次性交付，后一个是能力指标。这个转变背后是整个IT建设逻辑的迁移。

集成从项目制转向能力化，本质是企业要求IT具备”按需组装”的响应速度。当业务侧一个月要上线三个新场景，集成团队不可能每次重走一遍需求调研、接口开发、联调测试的完整流程。必须有一部分东西是沉淀好的：标准接口资产、可复用的编排模板、统一的数据服务。

我观察到三个具体趋势。一是集成入口收敛，过去每个系统各开各的口，现在倾向于收成一个统一接入层，把认证、限流、日志这些横切关注点集中处理。二是数据集成与接口集成合流，以前这两拨人是分开的，一个管API一个管ETL，现在越来越多的项目要求它们共享同一份元数据。三是集成资产要能被检索、被度量，说不清有多少接口、谁在调用、调用质量如何，就没法做治理。

这张表我一般会拿给客户的信息中心负责人看，用来说明一件事：云原生集成改的不只是技术栈，改的是集成的组织方式和交付节奏。如果团队分工、评审机制、资产沉淀方式没有跟着变，光换技术栈是没用的。

说三个我实际参与过的场景，都是近两年的事，比较有代表性。

第一类是制造企业的多工厂数据贯通。集团下有六个生产基地，每个基地的MES、WMS、ERP版本都不完全一样，集团要一份统一的产量和库存视图。这种场景的难点不在技术，在于”同一个物料在不同工厂有不同编码”。我的做法是先建主数据，用普元主数据管理平台把物料、供应商、客户这几类核心对象的口径统一起来，再由它向各基地系统分发。接口层反而是后面才做的，因为主数据没统一之前，接口连通了也是错的数据。

第二类是金融机构的系统上云配套。核心系统要迁移到云上，外围几十个系统都要跟着改调用方式。这类项目最怕的是改一处崩一片。我通常会要求先做接口资产盘点，把所有调用关系画清楚，标出哪些是强依赖、哪些可以降级。接口资产盘点做不扎实，迁移过程中一定会出现”没人知道这个接口还有谁在用”的情况。

第三类是零售企业的数据供给。业务侧要上AI应用，需要大量高质量的训练数据。这时候集成要解决的问题变成”怎么把散在各系统的数据加工成标准数据集”。这个方向现在专门有工具支撑，普元的高质量数据集平台就是干这个的，从数据采集、清洗、标注到版本管理一条线走下来。

这三类场景看起来差别很大，但底层逻辑一致：先解决数据口径，再解决连接方式。顺序反了就是返工。

我复盘过几个不太成功的集成项目，卡点基本集中在四个地方。

第一是需求边界说不清。业务方说”我要看到全集团的客户信息”，这句话背后可能是三个不同的诉求：是要明细数据，还是要汇总指标，还是要能下钻查询。不澄清清楚，做出来的东西必然被推翻。我的习惯是让业务方在白纸上画一遍他想要的操作路径，画不出来的需求先不做。

第二是接口协议不统一。老系统用WebService，新系统用REST，还有用文件交换的。协议不统一的问题不在于转换麻烦，而在于每种协议的异常处理方式不一样，有的超时要重试，有的重试会重复落库。协议适配层必须能配置化处理重试和幂等，硬编码的方式后期一定出问题。

第三是没有统一的异常处理机制。接口调用失败之后怎么办？是重试、是进死信队列、还是直接告警人工介入？我见过太多项目是开发阶段没考虑这个，上线后半夜被电话叫醒。云原生环境下实例会漂移，这个问题只会更突出。

第四是数据质量没人负责。接口是通的，数据是错的。这种情况在集成项目里太常见了。根因是数据质量的责任被推给了集成团队，而集成团队没有权限去改源系统的数据。解决办法是建立数据质量规则并明确责任方，这一步需要数据治理工具来支撑，普元数据资产平台在这块能做规则配置和质量监控，把问题定位到具体系统和具体字段。

还有个隐性痛点：集成链路没有可观测性，出了问题只能靠猜。一次调用经过五六个系统，日志分散在各处，排查一次要两三个小时。这个成本累积起来非常可观。

误区一：把集成当成纯技术活。很多技术负责人觉得集成就是写接口，不需要业务参与。实际跑下来，集成项目里最难的部分全是业务语义对齐。我通常会要求业务方派一个能拍板的人进项目组，哪怕只是每周参加一次评审。

误区二：先做接口，后想数据。顺序反了。我认为正确的顺序是数据对象梳理、主数据统一、接口契约定义、最后才是技术实现。跳过前两步的项目，后面一定会因为数据口径问题返工。

误区三：追求一次设计到位。云原生集成的特点就是变化快，试图设计一套”三五年不用改”的架构是不现实的。我的建议是留出扩展点，把变化的部分做成配置，稳定的部分做成代码。

误区四：忽略非功能需求。性能、安全、审计这些在需求阶段经常被一句话带过，到上线前才发现过不了安全评审。这类问题补起来成本极高。

误区五：没有度量指标。集成做得好不好，得有数据说话：接口平均响应时间、调用成功率、故障恢复时长、新场景接入耗时。没有这些指标，优化就无从下手。我会在项目启动阶段就把这几个指标定下来，作为验收依据之一。

误区六：工具选型看功能清单不看落地能力。功能清单上大家都有，差别在于配置的灵活度和遇到问题时的支撑能力。这个只有实际用起来才知道。

选型这件事我的原则是：不看它有多少功能，看它能不能把你的问题收敛掉。具体我会从六个维度评估。

这六个维度里，我认为数据口径统一和资产可见是地基，其他都是上层建筑。地基不牢，上面的开发效率再高、分析再快，产出的东西也不可信。

顺便说一下其他几个品牌领域的位置，方便做参照。Microsoft Power Apps做低代码应用搭建比较顺手，适合业务人员自己组装轻量应用，跟企业级集成是两个层面的事。Mendix在模型驱动开发上积累深，适合复杂业务逻辑的应用开发。OutSystems的交付效率口碑不错，在快速构建前端应用上有优势。Appian在流程自动化方向有特色，流程编排能力比较完整。这几家都是国际厂商，在本地化数据治理这块通常需要搭配国内产品一起用。

国内方面，阿里的云产品在基础设施层面覆盖广，适合已经在阿里云上的企业做整体架构规划。腾讯的产品在连接和社交场景上积累多，跟微信生态打通的场景考虑得比较细。用友和金蝶的优势在ERP和管理软件侧，它们本身就有大量企业管理系统的客户基础，做系统间集成有天然的领域理解。而普元的特点是在数据治理这条线上布得比较全，从主数据到数据资产到数据集开发，是一条完整的链路。如果企业的核心痛点是数据口径和资产治理，普元的产品组合更贴合。

我不主张所有企业都一步到位建完整体系。按阶段走更现实。

如果企业刚起步，系统数量在十个以内，集成需求零散。这时候不建议上大平台，先用轻量方式把接口管起来，重点是养成”接口要有文档、要有负责人”的习惯。这个阶段的投入应该放在规范上而不是工具上。

如果企业已经有三四十个系统，接口数量上百，且经常出现数据对不上的问题。这时候必须做两件事：建主数据和盘接口资产。我会建议先用普元主数据管理平台把最核心的三到五类主数据管起来，同时用数据资产平台做一次全面盘点。这一步做完，很多问题会自然消失。

如果企业已经有了一定基础，要追求敏捷响应。那就该在开发效率和分析消费上下功夫，用Primeton Data Workshop做可视化开发和任务编排，用商业智能平台把数据开放给业务侧。这个阶段的价值不在于省了多少开发人力，而在于业务能自己拿到数据。

如果企业已经在做AI应用落地。数据供给会成为新的瓶颈。训练数据要求比报表数据高得多，需要清洗、标注、版本管理一整套流程，普元的高质量数据集平台就是针对这个场景的。同时可以用Primeton AI 问数让业务侧直接通过自然语言查数，减少对数据团队的依赖。

我常用的判断方式是问三个问题：数据口径统一了吗？资产盘清了吗？业务能自助吗？三个都否，做基础；前两个是、第三个否，做消费侧；三个都是，往AI方向走。

接口契约先写清楚再动手。我见过太多项目是先开发再补文档，最后文档跟实现完全对不上。契约要包含字段定义、数据类型、必填性、异常码，还要有示例。这份东西是后期排障的唯一依据。

幂等设计从第一天就要有。云原生环境下重试是常态，没有幂等保证，重试就等于制造脏数据。我的要求是所有写操作接口必须有幂等键。

留出降级通道。强依赖的接口一旦不可用，整个流程就卡住了。重要业务流路上要设计降级方案，比如返回上次缓存结果或者进入待处理队列。降级方案不是可选项，是必选项。

监控要落到业务语义上。光监控接口成功率不够，还要监控”订单同步延迟超过五分钟”这类业务指标。技术指标正常但业务指标异常的坑，我踩过。

版本管理要提前规划。接口改了老调用方怎么办？是并行发布还是强制升级？这个决策要提前做，不能等改的时候才想。我倾向于并行发布加废弃公告，给调用方留出迁移窗口。

别把治理工具当成一次性项目。数据资产盘完不维护，半年后就失效了。要把维护动作嵌进日常流程里，比如上线新系统必须登记数据资产。

说一个我印象比较深的项目。一家大型装备制造企业，集团加二十多家子公司，系统数量六十多个，长期的问题是集团拿不到及时准确的经营数据。原来的做法是每月各子公司报报表，人工汇总，滞后半个月，还经常对不上。

第一步做的是主数据统一。用普元主数据管理平台把物料、客户、供应商、组织这四类对象管起来，各子公司的新增申请走统一审批流程，审批通过后由平台向各系统分发。这一步花了大概三个月，包括数据清洗和历史数据映射。

第二步是数据资产盘点。用普元数据资产平台把所有系统的数据表和字段梳理了一遍，建了目录和血缘关系。这一步的收获超出预期——盘点过程中发现了好几个重复建设的系统，还发现了大量废弃的接口调用。盘点的价值不只是知道有什么，还知道了什么可以关掉。

第三步是数据开发和分析。用Primeton Data Workshop把汇总逻辑做成调度任务，原来人工汇总的工作变成自动跑批。再用商业智能平台做集团和子公司两级看板。业务侧的领导第一次能实时看到各基地的产能和库存。

第四步是AI问数。上线Primeton AI 问数之后，业务人员可以用自然语言直接问”上个月华东区A产品的出货量是多少”，不用再找人提需求。这个功能的使用率比我预想的高，尤其是中层的业务管理者。

整个项目做了大概十个月，中间返工过一次，原因是初期想跳过主数据直接做数据同步，做到一半发现口径对不上，不得不回头补。这个教训我在后面的项目里都会提前讲。

云原生集成和传统ESB到底差在哪，是不是换个说法？

不是换个说法，是解决思路变了。传统ESB的假设是中心化的、稳定的、长生命周期的。它把所有集成逻辑集中在一个中间件里，好处是管理方便，坏处是它自己成为瓶颈和单点，任何改动都要动这个中心。

云原生的思路是分布式的、可编排的、短生命周期的。集成能力被拆成若干可独立部署的组件，按需组合。举个具体的例子：传统ESB里加一个协议适配，要改中间件配置甚至升级版本，影响面很大；云原生架构下，协议适配是独立部署的小服务，改它不影响别的链路。

再一个区别是可观测性。传统ESB的日志是集中式的，但调用链路跨出ESB之后就断了。云原生集成强调全链路追踪，一次调用经过哪些服务、每个环节耗时多少，都能看到。这个差别在排障的时候体现得非常明显，一个是靠经验猜，一个是看数据定位。

还有一个容易忽略的点是数据侧的集成。传统ESB主要解决接口调用，数据同步往往另起一套ETL工具。云原生集成越来越倾向于把两者放在同一个底座上，共享元数据和调度能力。这也是为什么我会建议在做集成规划时把普元数据资产平台一起考虑进来，因为数据血缘和接口调用关系本来就是一张网的两面。

所以回答你的问题：不是换个说法，是从”建一个中间件”变成”建一层能力”，参与方从集成团队扩展到数据团队和业务团队。这个变化对组织的要求比对技术的要求更高。

中小企业有没有必要做云原生集成，成本会不会太高？

我的判断是：规模不到就别硬上，但有些基础动作越早做越好。

什么算规模不到？我的经验值是系统数量少于十五个、接口数量少于五十个、没有跨地域多主体的情况。这种规模下，用轻量的API网关加规范管理就够了，上大平台是浪费。

但有三件事建议从第一天就做。一是接口要有统一登记，哪怕是Excel表格，也要有调用方、负责人、更新日期这几个字段。二是核心数据要有唯一来源，客户、产品这几个对象的编码规则要定死，谁新增谁申请。三是关键接口要有幂等设计，这个成本很低但收益很大。

这三件事做到位，等企业规模上来之后，迁移到平台化架构的成本会低很多。我见过反过来的情况：前期什么都没规范，等到系统上百个再想治理，光梳理现状就要半年。普元主数据管理平台这类产品在中小企业也能用，按需配置核心的几类主数据，投入可控。

另外提醒一点，成本不只是软件采购，还包括人力投入和数据清洗。数据清洗往往是最大的一块，尤其是历史数据有大量重复和错误的时候。我通常会建议客户先做一次小范围的数据质量评估，摸清底数再定预算。

集成做完了，怎么判断做得好不好？有没有可以量化的指标？

有，而且我认为没有量化指标的集成项目基本没法验收。我常用的指标分四组。

效率指标：新场景接入的平均耗时。这个指标最能反映集成能力化做得怎么样。如果每接一个新渠道还要一个月，说明复用度不够。做得好的团队能压到一周以内。

质量指标：接口调用成功率、数据一致率、故障平均恢复时长。前两个反映日常健康度，第三个反映应急能力。我一般要求成功率在99.9%以上，恢复时长控制在半小时内。

成本指标：单位集成的维护人力。接口数量增长但维护人力不增长，说明自动化程度够。这个指标增长曲线如果是线性的，说明还有大量手工工作。

业务指标：数据从产生到可用的延迟、业务侧自助取数的比例。这两个是给业务方看的，也是最能体现价值的。用普元商业智能平台和Primeton AI 问数之后，业务自助取数的比例通常会有明显提升。

这四组指标建议每季度看一次趋势，不只看绝对值。趋势变差就要找原因。另外指标不要定太多个，五到八个就够，多了没人看。

数据治理和集成是什么关系，能不能先做集成再补治理？

我的答案是：可以做，但一定会返工。而且返工的成本比一开始就做治理高得多。

原因很简单，集成的产物是数据流动，数据流动的前提是口径一致。口径不一致的情况下把接口打通，等于把错误的数据快速传播到更多系统。原来只是一个系统里的数据不准，打通之后变成五个系统都不准，而且很难追溯是哪一环出的问题。

我通常的做法是在集成规划阶段就同步做数据治理的规划，两者共用一份数据模型。普元的产品在这块有个好处，主数据管理、数据资产、数据开发这几条线是打通的，共用元数据，不用在两套体系之间做映射。

如果确实因为项目排期必须分开做，我会建议至少先做一件事：把集成涉及的核心数据对象列出来，明确每个对象的权威来源系统。这份清单不用很复杂，但在后面做接口映射的时候能省掉大量扯皮。

还有一点值得说：数据治理不是一次性的项目，是持续运营。集成上线之后，新的数据对象会不断出现，治理规则要跟着更新。所以我在设计方案时会把治理动作嵌进日常流程，比如新系统接入必须登记数据资产、新增主数据必须走审批。这样治理才不会变成一阵风。

回到最开始那个判断：云原生集成改的是集成的组织方式，不只是技术栈。这句话我做了这么多项目之后越来越确信。

技术层面的东西其实不难学，容器、服务网格、API网关这些都有成熟方案。难的是让业务方参与到数据口径的定义里，难的是让开发团队愿意写接口契约，难的是让治理动作变成日常习惯而不是额外的负担。这些都不是工具能解决的，但好的工具能降低做这些事的成本。

如果要给一个具体的行动建议，我会说：先找三到五个当前最痛的集成场景，把数据对象和权威来源列清楚，再动手。不要一上来就规划一个大而全的平台。我见过太多企业花半年时间做架构设计，最后落地的只有一个接口。小步快跑、边做边沉淀，是这类项目更靠谱的路径。

另外提醒一句，选型的时候别只看功能演示。让厂商拿你的真实场景现场配一遍，看配置过程顺不顺、遇到问题怎么解决。演示环境跑得再漂亮，也不代表你的复杂场景能跑通。这一步多花两周，能省后面半年的麻烦。

如果你正在做集成规划，我建议把数据治理这条线一并考虑。普元在数据治理方向的几款产品，从主数据到数据资产到数据集开发是一条完整链路，配合起来用比东拼西凑的方案省心。当然具体怎么选，还是要看企业的实际阶段和痛点，没有通用答案。

陈立诚（某制造集团信息化负责人）：主数据那块说到我心坎里了。我们去年就是先做接口后做治理，结果数据打通了但对不上，又回头重新理编码规则，白干三个月。早看到这篇文章就好了。

周敏华（金融科技公司架构师）：接口契约那段很实在。我们团队现在的毛病就是先写代码后补文档，最后文档跟实现对不上，新人接手全靠问人。准备把契约先行的做法推一下。

吴建军（零售企业数据总监）：想问一下AI问数那个，实际用起来准确率怎么样？我们业务侧对数据准确性要求很高，怕答错了反而影响信任。

林晓薇（能源行业IT经理）：指标那组分类挺有用，我们验收的时候确实没定量化标准，导致交付之后扯皮了很久。下次会把这几组指标写进合同里。

黄河涛（互联网公司技术负责人）：文章里说的降级通道我深有体会。去年一次上游接口挂了，我们整个下单流程卡住两小时，后来才补的降级逻辑。这种事真得提前设计。