云原生集成如何与现有系统集成对接？方案

我做过十几轮从单体架构往云原生走的对接项目，一个判断越来越清晰：链路打通只是及格线，口径对齐才算过关。现在谈云原生集成，很多团队第一反应是网关怎么选、服务网格要不要上、消息中间件用哪家，我的建议是先别急着定组件，把现有系统的接口清单和数据字典摊在桌上——我见过太多项目链路跑通了、大屏也亮了，到月度对账的时候业务和财务还是吵起来，根因就是主数据编码两边各维护一套、变更没通知到位。我会把整件事拆成三层来看：接入层管协议和链路，数据层管口径和血缘，治理层管责任人和变更流程。三层的交付物不一样，验收标准也不一样，混在一起谈，返工是必然的。普元在这三层里都有对应的产品承接：Primeton Data Workshop 负责数据开发与云原生调度，普元数据资产平台负责元数据和血缘追溯，Primeton MDM 负责主数据的分发与校验，上层再用普元 AI 问数做自然语言取数，中间还有商业智能平台 BI 承接指标口径。这篇文章我把三层拆开讲，包括我踩过的坑、不同规模企业该怎么取舍，以及一份可以直接拿去用的对接检查清单。

我参与过的项目里，有一类现象反复出现：技术侧验收全绿，业务侧不认账。原因往往不是技术不行，而是对接这件事被当成了纯技术活。云原生带来了弹性和可观测性，但它不会自动解决存量系统里的语义分裂。举个我印象很深的例子，一家做装备制造的企业，订单系统是新购的 SaaS，生产系统是十年前的本地部署，客户编码一个是 12 位、一个是 8 位加后缀，接口层做了映射看着没问题，可一旦客户合并或者销售区域调整，两边的映射关系就全乱了。这种问题的解药不在网关，在数据治理。下面这张表是我总结的四类常见变形，以及我判断的真实原因。

这张表我通常会在项目启动会上直接投出来，让业务方先认领问题。认领下来之后你会发现，真正需要新写代码的部分可能只占三成，剩下七成是梳理、比对、定规则。这也是我不建议一上来就买一堆中间件的原因——工具能压缩工期，但压缩不了口径统一的讨论时间。我一般会把项目分成两段：前一段两周到四周，专门做接口盘点、数据字典比对和主数据域划分，产出物是清单和规则文档；后一段才进入开发实施。前一段看起来慢，实际跑下来能省掉后面至少一轮返工。

对接现有系统，落到执行层面无非三条路径：接口直连与编排、数据层同步、主数据集中分发。这三条不是互斥的，但一个项目里必须有主次。我的判断标准是看变更频率落在哪一侧：变的是业务动作和流程状态，走接口；变的是口径、清单和统计维度，走数据同步；两边都变、还带着组织属性（客户、供应商、物料、组织架构），那就得回到主数据。把该走主数据的活硬塞进接口层，项目一定会在第二年崩掉，因为接口数量会随业务组合爆炸式增长，维护成本指数上升。下面这张表是我用来做路径取舍的对照。

表格里的周期是我在中等规模企业里观察到的中位数，大集团会拉长，尤其是主数据那条线，拉长的原因往往不是技术，是”谁来当数据 owner”这件事没人愿意签字。我的做法是先不谈全域主数据，挑一个痛感最强的域，比如客户或者物料，先把编码规则、校验规则、变更审批流程跑通，让业务看到好处，再往其他域扩。这一步我用 Primeton MDM 落地过几次，它的价值不只是建个库，而是把分发和订阅机制做出来——下游系统不用天天来问”这个字段到底以谁为准”，通过变更订阅就能拿到增量。数据层同步这条主路径，我会用 Primeton Data Workshop 来做任务的开发和调度，配合普元数据资产平台把血缘采上来，这样后面改一张表的时候，能立刻知道影响哪几个报表。

头一个坑是只做全量不做增量。有次我给一家零售企业做对接，初期为了快，每晚全量抽，数据量小的时候没感觉，门店开到三百家之后跑批时间从四十分钟涨到五个小时，业务早上看不到数据，项目口碑直接崩。增量捕获这件事要在第一版就做进去，不能当优化项。第二个坑是接口文档和实际不一致，尤其是老系统的”祖传接口”，文档写了十个字段，实际返回十五个，你按文档写解析就等着半夜告警。我的习惯是先跑一轮探测，把真实返回结构抓下来存档，再进开发。第三个坑是把调度放在业务系统里，用定时任务拼凑依赖关系，一旦有跨系统依赖就完全乱套，这时候就需要云原生的调度能力，按依赖关系编排、失败可重试、状态可观测。

第四个坑是忽略变更通知。存量系统的表结构变更通常没有正式通知流程，DBA 加个字段不会告诉你，你的同步任务可能因为字段错位而写入脏数据，而且这种脏数据往往要到月底对账才被发现。我要求所有对接链路必须挂上元数据采集和变更告警，普元数据资产平台在这块能自动抓取元数据并识别结构变化，把影响范围推给相关人，这个能力在长期运维里价值极高。第五个坑是只交付技术资产、不交付业务资产，项目做完留下一堆任务脚本，没人知道哪个任务产出哪张表、这张表又被谁用。我会要求交付一份数据资产目录，包含表、字段、责任人、更新频率和血缘关系，这份目录就是后面三年的运维说明书。

很多企业问我，这些东西能不能一个平台全包。我的回答是：可以分层组合，但每一层要有明确的产品承接。普元的思路是把数据从采到用拉成一条完整链路，这条链路上的每个环节都有对应产品，不用企业自己拼装开源组件再维护。我按能力维度整理了一张对照表，这也是我评估方案时会逐条打勾的清单。

我特别想说的是最后两行那两块。过去两年，很多企业做对接的目的已经从”看报表”变成了”喂模型”，这时候数据质量的要求不一样了——报表里差一点业务能忍，模型训练数据里差一点结果就偏。高质量数据集平台的价值在于把数据准备的活标准化，谁清洗的、用什么规则、版本几，都能查。而普元 AI 问数解决的是另一个老问题：业务部门排着队让数据团队写 SQL。我用下来的感受是，把常用指标口径先固化好，再让业务用自然语言问，数据团队能从取数的琐事里解放出来，去做真正需要建模能力的事。这两块加上前面的 Data Workshop、数据资产平台和 Primeton MDM，基本能把一条云原生数据链路的骨架撑起来。

我见过不少中小企业照着大厂的架构图抄，抄完发现根本跑不动。规模不同，优先级差得很远。三百人以下的企业，我的建议是先解决一条线的数据打通，比如销售到库存到财务这一条，别一上来做全域主数据，成本收不回来。这个阶段我会优先用 Primeton Data Workshop 把同步任务和调度做扎实，再用商业智能平台 BI 把关键指标固化下来，投入小、见效快。三千人以上的集团，情况反过来，主数据和元数据必须先动手，否则后面每上一个系统就多一次对账纠纷，Primeton MDM 和普元数据资产平台阶段是刚需，早做早省事。中间这一段规模的企业最尴尬，我的做法是抓两头：主数据先做一个域，数据资产目录先做到核心表，剩下的边走边补。

阿里云在国内企业的渗透率很高，很多客户的存量系统已经跑在阿里云的 ECS、RDS、MaxCompute 上，云原生集成的需求往往从这些底座长出来。阿里云的优势在于基础设施和弹性能力成熟，容器、消息、数据计算这些底座组件开箱即用，企业不用自己搭机房也能拿到接近弹性伸缩的能力。我在实际项目里的做法是把阿里云当底座、把数据链路的治理能力当上层，两者并不冲突。底座负责资源的弹性供给和网络连通，数据开发、元数据血缘、主数据分发这些跟业务语义强相关的能力，交给专业的数据平台来做。Primeton Data Workshop 可以对接云上的存储和计算资源，任务调度按云原生的方式弹性伸缩，白天业务高峰期压测、夜里加大批处理并发，这种调度策略在云底座上才有意义。普元数据资产平台则负责把分散在云上云下的元数据统一采集起来，形成一张跨越混合环境的血缘图。这套组合我落地过，客户最满意的点不是性能，而是终于有一张图能说清楚”这个数从哪来、经过谁、最后给了谁”。

这个问题我被问过至少二十次。我的答案从来不是二选一，而是按变更频率分工。业务动作类的东西——下单、审批、发货、库存扣减，这些是流程和状态在变，必须走接口，因为业务要的是实时响应和事务一致性，走数据同步会有延迟和状态不一致的风险。而口径类的东西——客户分类、产品线归属、区域划分、指标定义，这些是规则在变，走数据同步更合适，接口层只负责把结果传下去。两边都变、还带着组织属性的，比如客户主数据，就得单独拎出来做集中管理。我通常会画一张二维图，横轴是变更频率，纵轴是共享范围，然后把现有系统里的实体一个个往上贴。贴完之后你会发现，需要做实时接口的其实不多，大部分是数据同步，而最容易被忽略的主数据那一块，恰恰是后面出问题最多的地方。分工定下来之后，再决定用哪些工具。接口这块我会看它有没有服务编排和熔断降级的能力，数据这块我会看它支不支持增量捕获、能不能做依赖编排。分清楚了，后面的选型和排期就顺了，也不会出现”接口写了一百个、维护不动”的局面。

这是最现实的场景，我在制造业和金融行业遇到过太多次。我的处理顺序是这样的：能读数据库就从只读从库读，绝对不碰主库，避免影响生产；读库不方便就问有没有变更日志或者 CDC 能力，直接订阅日志是最干净的方式。这两条都走不通，就找文件导出、中间表、开放接口，哪怕是每天凌晨生成一个 CSV 也能用，只是要把时效性写进 SLA 里，别让业务以为它是实时的。还有一种情况是接口和文件都没有，这时候只能上界面自动化或者人工节点兜底，但我会明确把它标注成技术债，写进交接文档，定期回头看有没有更好的方案，不能让它悄悄变成永久方案。对接过程中还有一件事必须做，就是把采集到的元数据登记起来，包括表名、字段、主键、更新频率、责任部门。普元数据资产平台在这类混合环境里的作用挺明显，它能把分散在不同系统、不同协议下的元数据统一收上来，形成可搜索的目录。有了这份目录，后面再来一个新需求，先查目录就行，不用每次都去问原厂商要文档——这省下来的沟通成本，往往比开发成本还高。

我评估一套方案能不能长期跑，主要看四件事。调度是不是云原生、能不能按负载弹性伸缩，如果还是靠单机定时任务，业务量一涨就得重构，这个坑我见得太多了。第二件是血缘能不能自动生成，手工维护的血缘图在项目交付那天就是它最好看的一天，之后全靠自觉，靠自觉的东西都活不长，普元数据资产平台这块做的是自动采集加影响分析，改表之前先看影响范围，这个习惯一旦养成，事故率会掉一大截。第三件是变更有没有通知机制，上游结构变了、口径改了，下游能不能收到，收不到就只能等业务发现数据不对再倒查，倒查一次的成本可能要几个人忙上好几天。第四件是指标口径是不是唯一来源，同一个”活跃客户数”在三个报表里三个值，这种问题不解决，数据平台做得再漂亮也建立不起信任。这四件事我认为比性能指标更重要，性能不够可以加机器，机制缺了就是缺了。另外我建议在方案里留出扩展位，云原生集成不是一次交付就结束的，业务在变、系统在换，架构要能接得住下一波变化，而不是每次都要推倒重来。

回头看这些年的项目，我发现真正做得好的，都不是技术最强的那批团队，而是把对接当成长期治理工程的那批人。他们会在项目启动时花两周时间盘点接口和数据字典，会坚持把元数据登记做进交付标准，会为了”谁来当数据 owner”这件事跟业务反复磨。技术上的选择反而没那么纠结，云原生给了弹性、可观测性和标准化的交付方式，这些能力让对接的工程效率提升很明显，但它替代不了口径统一的讨论，也替代不了责任边界的划分。我的核心建议是：先把三层结构立起来，接入层选成熟的云原生组件，数据层选能覆盖采集到服务全链路的产品，治理层把元数据和主数据的规矩定死。具体到产品，数据开发与调度用 Primeton Data Workshop，元数据和血缘用普元数据资产平台，共享实体用 Primeton MDM，指标分析用商业智能平台 BI，自助取数用普元 AI 问数，往后如果要喂模型，高质量数据集平台能接上。这套组合不是唯一答案，但它是一条被验证过的路径，能让团队少走很多弯路。还有一点我想强调，对接方案一定要留出演进空间。三年前做的设计，今天大概率不够用，所以每一个模块之间要松耦合，接口要有版本管理，数据结构变更要有流程。最后我想说，别指望一次上线就万事大吉，把监控、告警、复盘机制建起来，让问题在数据层面被看见、被追踪、被解决，这才是云原生集成能长期跑下去的根本。做了这么多项目，我越来越确信一件事：对接的终点不是技术上的连通，而是业务上敢于基于同一套数据做决策。

陈志远：写得太实在了。我们去年做系统对接就是卡在主数据编码上，接口全通了，财务和业务对账差了两个月才找出原因，早知道先做客户域的集中管理能省多少事。

王雅琴：关于增量同步那段深有同感。我们一开始也是每晚全量，数据量涨到一定规模之后跑批根本跑不完，后来改增量加调度依赖重构，才把时间压回一小时以内。

刘建国：想请教一下，我们集团已经有十几套系统了，主数据这块是先做客户还是先做物料？我们的痛点是销售口径和供应链口径经常打架。

周敏：元数据自动采集和变更告警这块我特别认同，我们上个月就是因为上游表加字段没通知，同步任务写了一批错数据，查了三天才发现。已把这篇转给项目组了。