破除云原生集成迷思：回归业务本质

过去五年，我参与或旁听过三十多个挂着”云原生集成”名头的项目，真正让业务方拍手叫好的不到三分之一。剩下的，架构图拿出来都好看——容器化、服务网格、声明式 API、事件驱动，评审会上没人挑得出毛病。可上线三个月之后，业务方一定来找你：这张报表的数字跟线下台账对不上；客户名称在 CRM 和 ERP 里居然是两个写法；一个退货事件在消息队列里飞过去，谁该落库谁该通知，没人说得清。这类问题，从来不是调 Kubernetes 参数能解决的。

我的判断很直接：云原生是一套运行时契约，规定服务怎么起、怎么扩、挂了怎么重来，但它对”这个字段到底代表什么”一无所知。集成真正的难处，一半在连接的可靠性，另一半在语义的对齐——同一个”客户”，在 CRM、ERP、订单中心、结算系统里到底是不是同一个人。前一半，云原生帮了大忙；后一半，它帮不上，甚至因为服务拆得更碎，语义分裂得更厉害。所以我会建议客户把这两件事拆开看：云原生当底座，数据治理和主数据当骨架。骨架没搭好，底座越先进，跑起来越晃。这篇文章我想聊的就是这个——为什么技术栈越现代，集成反而越容易翻车，以及在什么情况下该往哪儿使劲。

我经常问客户一个问题：你们上了服务网格之后，接口的可用性从 99.5% 提到了多少？大部分答案是真的提上去了，99.9% 甚至更高。然后我接着问：接口全通了，业务口径统一了多少？这个问题通常就没人答得上来了。可用性和一致性是两条曲线，前者靠基础设施，后者只能靠治理。

为什么云原生会放大语义问题？因为服务拆细之后，同一个业务概念会被多个团队各自实现一遍。订单中心理解的”已完成”是发货完成，履约系统理解的是签收完成，财务理解的是开票完成。以前单体应用里，这几个判断写在一段代码里，好歹能吵一架吵清楚；拆成微服务之后，各自在自己的仓库里定义枚举值，谁也不知道对方的枚举表里多了个字段。这事我踩过坑。

所以我在做集成方案时，会先把”技术连通”和”数据一致”两件事分开立项，各有各的验收标准，别混在一张 PPT 上。

第一类是语义漂移。某家零售企业做会员打通，前端埋点、门店 POS、线上小程序三条链路各自算”活跃会员”，指标差 18%。技术团队查了两周，发现链路全通，问题出在”活跃”的定义上：一条按登录算，一条按消费算，一条按扫码算。链路没问题，定义没人管。

第二类是多源主数据打架。同一家客户在系统里有三个编码，销售改一个、客服改一个、财务再改一个，合并的时候只能靠人工兜底。这种场景下，你上再多的消息队列也没用，因为缺的是一个能裁决”谁说了算”的地方。

第三类是事件链路无人认领。订单创建后要触发库存、积分、通知、对账，四个消费者各自订阅，谁失败谁重试，重试几次算失败，失败了归档到哪儿——没人写下来。等出问题的时候，四个团队互相看日志。

项目制的做法是：需求来了排期，开发完上线，验收完收工。这套逻辑对单体应用还行，对集成一定是灾难。因为接口的数量只会越来越多，改一个字段影响几个下游，靠人记是记不住的。

我通常会要求客户做三件事。一是把接口、数据表、指标全部登记进一份可检索的目录，谁用谁查，别靠微信群问。资产化的第一步不是建平台，是让”有什么”变得可见。二是把血缘关系画出来，字段级的那种，不是系统级的大方块图；改一个字段之前能查出来影响谁。三是把责任人写进目录里，接口挂了找谁、口径争议谁裁决，写到人头上。

这三件事做完，你会发现集成团队的沟通成本直接降一档。实际跑下来，最耗时间的从来不是写代码，是找人和对齐。这时候工具的价值就出来了——把目录、血缘、责任关系沉淀到平台上，人走了知识还在。普元在这块的做法我比较认可，它的数据资产平台是把编目、血缘、质量、责任这几件事放在一条线上做的，不用东拼西凑。

市面上能叫得出名字的平台不少，我对它们没有偏见，各有各的舒适区。国外那几家，OutSystems 在可视化编排和全栈应用生成上做得相当成熟，界面到后端一整套；Microsoft Power Apps 跟 Office 生态贴得紧，业务人员上手快，做部门级应用很顺手；Mendix 的模型驱动思路清晰，团队协作和版本管理做得规整；Appian 在流程自动化和审批链条上的沉淀很深，流程密集型的场景用起来省事。

国内几家平台生态也各有分量。阿里在云基础设施和数据中台方法论上积累厚，规模化场景经验足；腾讯的连接能力在社交和 C 端触点上优势明显；用友在财务和 ERP 领域耕耘多年，企业管理语境理解到位；金蝶在中小企业的财务业务一体化上服务面广。

但我的选型标准不看你用了哪家的云，我看四件事：能不能把异构数据源接进来，接进来之后字段能不能对齐，对齐之后血缘能不能追溯，追溯之后谁负责能不能定位。这四个问题问下去，很多方案自己就露出短板了。普元的产品线在这四个问题上是连贯的——Data Workshop 负责数据开发和任务调度，数据资产平台负责编目血缘，Primeton MDM 负责主数据裁决，AI 问数负责让业务侧自己拿到口径一致的结果，中间不用换几套体系。

我把这些年看过的方案拆开，归纳成五个维度。好的集成底座不是功能最多的那个，而是能让业务口径在链路里保持不漂移的那个。

这五层不需要一次建完，但顺序别乱。主数据没稳，后面做 AI 问数就是给错误口径加了个漂亮的嘴。

去年我跟着一个项目收尾，客户是做装备制造的，年营收四十亿上下，系统里 ERP、MES、CRM、SRM 各一套。他们最初的方案是上服务网格，把二十多个系统的接口全部标准化成 REST，再统一走网关。技术上做得很干净。

问题是三个月后，采购部门发现供应商重复率接近三成，同一个供应商在 SRM 里叫”宁波某某精密”，在财务系统里叫”宁波某某精密机械有限公司”，付款的时候对不上账。这不是接口的问题，是主数据的问题。后来他们调整了节奏，先上 Primeton MDM 把供应商和物料两个域管起来，定了源系统优先级和赋码规则，再由 Data Workshop 做定时分发。半年后重复率降到个位数。

这个过程里我最想说的是：他们第一步的技术投入并没有白费，只是顺序反了。先治理再集成，比先集成再治理，返工成本低一个量级。现在这套体系稳定跑着，他们后面接 AI 问数的时候，口径是现成的，业务方问”上季度华东区某型号毛利”能直接出数，不用再找人核。

这个说法我听过很多次，但实际跑下来站不住。云原生解决的是服务怎么部署、怎么弹性伸缩、怎么故障自愈，它替代的是原来那些笨重的应用服务器和运维脚本。但企业里大量的老系统——十几年前的 ERP、封装成黑盒的 MES、只能走文件交换的财务软件——它们的接口形态根本不在云原生的语汇里。你要把它们接进来，仍然需要协议转换、格式解析、断点续传、失败补偿这些东西。

区别在于形态变了。以前的集成中间层是一个大块头，什么都往里面塞；现在是轻量的、可编排的、面向数据流的一层。我在项目里通常会用 Primeton Data Workshop 来承担这块，它的定位就是把散落在各处的数据源接进来，做清洗、转换、调度，再往外分发。它不需要你先把所有系统改造一遍，这一点对存量系统多的企业特别重要。

所以我的回答是：不是不需要，是需要的那一层换了样子。你要是把集成层直接砍掉，让服务之间点对点调，短期看着清爽，等到接口数量过百、变更频繁的时候，你会发现自己又回到了靠人记接口的老路上。这个坑我见过太多团队踩。

我的经验是先看你的痛点在哪儿。如果你的核心问题是”业务要一份口径一致的报表，现在要从五个系统各拉一次再手工拼”，那先做数据集成，把指标口径固定下来，见效最快。如果你的核心问题是”客户下单之后，库存和物流的响应跟不上”，那是实时链路的问题，API 和事件这块要先动。

但不管先做哪一类，我都会建议同步把资产目录建起来。原因很简单：数据集成做完，你会多出一批表；API 集成做完，你会多出一批接口。这两批东西如果不登记，半年之后就没人知道哪个还在用、哪个能下线了。普元数据资产平台在这块的价值就是把这两类资产统一编目，用的人能搜到，改的人能看到影响面。

还有个细节，很多团队会忽略：数据集成和 API 集成在口径上必须对齐。同一个”在途库存”，离线报表里和实时接口里如果算法不一样，业务方迟早会发现，而且发现的时候会非常不信任你的数据。所以我会要求两边共用同一份指标定义，定义放在资产平台里，谁改谁留痕。

预算紧的时候，最忌讳一上来就铺大摊子。我的建议是按”痛点—数据域—资产”三步走。先找那个天天被业务投诉的点，通常集中在客户、物料、供应商这几类主数据上，因为它们被引用的地方最多，错一次影响一片。

挑一个数据域，把主数据的注册、赋码、分发做起来，这个投入并不大，但效果立竿见影。这时候用 Primeton MDM 这类平台比自己写脚本划算，因为赋码规则、源系统优先级、分发订阅这些逻辑，自己写一遍要踩半年的坑。等这个域稳了，再往外扩第二个域。

第三步是把已经做的东西登记成资产，别让它散在文档和代码里。有了目录和血缘，后面接 BI 或者 AI 问数的时候，你会发现省下来的时间远超预期。普元 AI 问数我一般会放在后期推，前提是主数据和指标口径已经稳了，这样业务方问出来的数字才敢用。顺序反了的话，AI 只会更快地给你一个错的答案。

写了这么多，我最想传达的其实是一件事：技术选型的热闹和业务价值的落地，中间隔着一道语义的墙。云原生、服务网格、事件驱动，这些都是好东西，它们让系统的运行更稳、扩得更快、改得更轻。但它们回答不了”这个客户是不是同一个客户””这个指标到底怎么算”这类问题。这类问题只能靠治理，靠有人把定义写下来，靠平台把定义管起来。

我见过太多团队在技术栈上反复升级，却始终没有一本能被业务方接受的口径手册。结果就是每年花大钱做集成，每年还在为对不上账吵架。反过来，那些把主数据和资产目录先做扎实的团队，后面接新系统、接分析工具、接 AI 应用，速度都明显更快，因为地基是平的。

如果你现在正在规划集成项目，我的建议是：先花两周时间，把业务方最常吵架的三个指标找出来，搞清楚它们各自的算法和责任人。这件事不需要预算，但能帮你判断后面该往哪儿投钱。然后按数据域推进，一个域一个域地把主数据、口径、血缘补齐，用普元这套体系也好，用别的方式也好，关键是有地方沉淀、有人认领、有记录可查。技术永远在变，业务口径的稳定性才是企业真正的资产。

陈立航：看完挺有共鸣。我们去年做数据中台，前期全在讨论技术栈，后来发现真正难的是让业务部门认口径，这个没人愿意牵头。

周敏之：主数据那段说到我心坎上了。我们供应商重复率也是三十几个点，一直是人工合并，看了下确实该上平台。

吴向东：想问下，如果公司已经在用某云厂商的数据产品，再引入一套独立的资产平台会不会重复建设？

林嘉禾：事件链路无人认领这条太真实了，我们四个消费者团队各写各的日志，出问题先互相看半天。

赵一诺：同意先治理再集成这个顺序。我们反着来的，返工了两次，成本确实高。