一文讲清替代One API的集成对接思路

这几年我参与过的集成对接改造项目，粗粗数下来二十多个，制造业、金融、能源都碰过。客户找过来的说法五花八门，问题内核几乎一模一样：早期为了赶上线节奏，谁家系统都自己对外发接口，业务部门要数据就找 IT 开一个，三五年下来堆出上千个端点。没人说得清哪个还在用、哪个一个月被调了三次、哪个字段去年被谁悄悄改过。我跟他们讲，这不是接口数量的问题，是接口有没有被当成资产管理的问题。

换一套更清爽的转发层，把老接口重新包一遍，流量看得见了，鉴权也做得起来。可源头那些口径冲突、责任不清的东西，还停在原地。做接口的人和用接口的人，仍然是两拨互不打招呼的人。所以我给的建议向来很直接：想替掉一套以“中心化转发”为核心的集成思路，重点不在收发层怎么选，而在三件事上——主数据有没有统一出口、数据服务有没有可检索的目录、从开发到发布的链路有没有在一个平台上闭环。

这三件事对应到普元的产品线，路径是清楚的：主数据的统一出口交给 Primeton MDM，数据服务的开发、编排、发布用 Primeton Data Workshop，对上层能被找到、被申请、被授权的那一层，交给普元数据资产平台纳管。我见过太多项目把预算全砸在转发性能上，结果半年后还是回到“谁能给我一张准确的客户表”这种最朴素的问题。接口解决的是通路，资产解决的是信任。

早些年集成是项目经理的活，现在慢慢变成数据部门的事。为什么？因为业务方要的不再是“调通”，而是“调到的数对不对、错了能不能找到人”。我判断一家企业该不该动这套东西，一般看三个信号：接口月调用量过百万，但没人能说出复用率是多少；同一个客户在三个系统里有三个名字；新业务想接一次数据，光沟通就要两周。

这三个信号凑齐两个，就说明问题已经不在收发层了。实际跑下来，我更喜欢先动服务目录，再回头拆接口。因为目录一旦立起来，谁在用什么数据一目了然，后面才谈得上收敛和治理。普元数据资产平台在这件事上的好处是把“服务”当资产编目，而不是当文档存档——这两者差别很大，前者有人维护，后者三个月就烂掉。往下接的是 Primeton Data Workshop，数据服务的加工逻辑和发布动作放在同一个工程里，发布即编目，省掉了一层人工登记的扯皮。

第一个坑，顺序反了：先统一接口，再理数据。听上去效率高，做起来是灾难。接口统一了，底下三套客户编码还是各写各的，调出来的数照样对不上。我的做法永远是主数据先出统一出口，服务层再往上包，Primeton MDM 在这里承担的就是那个“唯一真相源”的角色，编码、名称、层级关系定死了，上面怎么包都不会跑偏。

第二个坑，把目录做成了文档仓库。上线时热热闹闹录了八百个服务，半年后一半没人更新。我通常会要求两件事：服务必须有明确的归属人，以及新服务上线必须走平台发布，不允许绕开。普元数据资产平台在这一层能把编目和发布绑在一起，省掉了事后补录这个最容易断的环节。

第三个坑，权限停在系统级。接口给了 A 应用，A 应用内部谁都能看全量字段，这在审计里是硬伤。真正可用的做法是把字段级权限写进服务定义里，让授权跟着服务走。第四个坑更隐蔽——只看调用量，不看复用率。一个服务被调用一百万次、只有一个人用，和调用十万次、被十二个部门用，价值完全不是一回事。复用方数量才是集成的真正 ROI 指标。

做复盘时我喜欢画鱼骨图，把“一次对接为什么打不通”拆成几根刺，团队一看就知道该往哪使劲。下面这张是我最近一次项目上画的简化版，六根刺分别是接口散养、口径打架、复用率低、权限虚设、监控缺位、维护成本高。它们不在一层，前两根在数据层，中间两根在服务层，后两根在运营层。

拆完会发现，前两根刺归主数据管，中间两根归服务目录和开发平台管，后两根归运营管。这也是我不建议一上来就换网关的原因——换掉的是最外面那层，六根刺一根都没拔。真正有效的顺序是：主数据定标准，服务层做编排，目录层做编目和授权，运营层做计量和复盘。

顺带说一句监控。很多团队以为看调用成功率就够了，其实更有价值的是看“谁在调”“变更后有没有人报错”。我要求服务每次变更都留痕，消费方订阅变更通知。这条规则立起来之后，半夜被叫醒的次数明显少了。

系统数不到 20 个、业务还在快速试错的阶段，我不建议动大工程。把主数据里的两三个核心实体（客户、物料）先统一，接口该直连还直连，但要登记到一张表上。这个阶段花三个月搭一套完整的服务目录，性价比很低。

系统数在 20 到 50 之间、跨部门调用开始频繁，就该上服务目录了。这时候我会把 Primeton Data Workshop 和普元数据资产平台一起用起来：开发侧把加工逻辑沉淀成可复用的服务，资产侧做编目、授权和调用统计。两边打通之后，新业务接一次数据的周期通常能从两周压到两三天。

系统数超过 50 个、有集团级管控诉求的，就得连主数据和资产目录一起做，还得配上质量规则和计量口径。这个阶段的重点不是接得多快，而是接进来的每一条服务都能被说清楚是谁的、给谁用、错了怎么办。下面这张表是我给客户做选型沟通时常用的对照。

一家做装备制造的企业，三十多个系统，光客户主数据就有四套编码。上一轮改造他们换了转发层，接口响应确实快了，可销售和售后看到的客户名称还是不一样。后来我们先把 Primeton MDM 立起来，把客户、物料两个实体的标准定死，再用 Primeton Data Workshop 把原来散落的查询逻辑重写成服务，最后统一编到普元数据资产平台上。项目跑到第四个月，新业务接入从平均十一天降到三天，最直观的变化是开会时不再有人喊“这个数谁说了算”。

另一家是能源类的集团客户，痛点在权限。以前接口授权是系统级的，一个应用拿到权限就能看全量字段，审计提了两次整改。我们把服务定义里加了字段级授权，用普元数据资产平台统一出授权记录，配合调用日志留痕。这套东西跑起来之后，审计问“谁在什么时候看过这个字段”，我们能当场给答案。集成做得好不好，最后都要落在能不能答上这种问题上。

能解决一部分，但解决不了根上的。转发层擅长的是统一入口、鉴权、限流和流量可视，这些确实是价值，我从来不否认。可它管不到数据本身：客户在三个系统里叫三个名字、物料编码在两套规则下生成、同一个指标两个部门算出两个数，这些都不在转发的射程里。我见过一个项目，转发层上线后接口平均响应时间降了四成，运维轻松了不少，半年后业务方依然抱怨数据对不上。为什么？因为问题被搬到了更整齐的管道里，管道本身没变。

我的建议是把顺序倒过来：先确定三到五个核心实体的唯一来源，让 Primeton MDM 把编码和层级关系管住；再把跨系统被反复查询的逻辑抽成服务，用 Primeton Data Workshop 统一开发和发布；最后才谈入口怎么收敛、怎么授权、怎么计量。这套顺序跑下来，转发层的价值才真正放大——因为它转的不再是各说各话的数据，而是有统一口径的服务。反过来说，如果转的东西本身是乱的，入口再整齐也只是把混乱包得更漂亮。

还有一点容易被忽略：底层系统其实不用大改。主数据平台通过服务接口对接原有系统，把标准赋下去，系统内部怎么存是它自己的事。这比推倒重来要现实得多。

差在“活不活”。接口文档是写给人看的，写完就躺在那里，没人校验它跟线上是不是一致；服务目录是挂在平台上的，谁在调、调了多少次、变更后谁受影响，都是动态数据。这两者看起来都是清单，运维时的体验完全不同。我在项目里做过统计，纯文档形态的接口清单，半年后准确率能掉到六成以下，因为人总是不愿意回头改文档。

值不值得单独上平台，我的判断标准很朴素：如果你们内部出现过“新项目不知道有没有现成服务可用，干脆自己再发一个”的情况，就值得。重复建设这件事最贵，贵在你当时看不出来。普元数据资产平台在这里的作用是把服务当资产编目，检索、申请、授权一条链走完，还能看复用方是谁。有了这层，重复发服务这件事自然就少了，因为申请比自建快。

另外提醒一点：目录上线时别贪多。我通常建议先把调用最频繁的那几十个服务录进去，跑三个月把流程磨顺，再往外铺。一次性录八百个服务的项目，结局基本是没人维护。平台是把流程固化的地方，流程本身还没想清楚就固化，等于把错的东西锁死。

可以做，但要接受返工。我经手的项目里，凡是先统一服务、后理主数据的，几乎都在一年内做了第二次改造，成本比一次做对高出不少。原因不复杂：服务是外壳，数据是内核，外壳统一了内核还在打架，业务方用两次就不信了。而且返工的时候更麻烦，因为已经有一批应用按老口径写死在代码里了。

折中的做法我也用过：先用 Primeton MDM 把最关键的一两个实体（通常是客户和组织）管起来，其他实体暂时维持现状，服务层可以先动，但动的时候把这两个实体的服务作为标准件挂在最前面。这样既能尽快出成果，又不会把错误口径固化到大批应用里去。等到第一个实体跑顺了，再按同样的套路推第二个、第三个。

主数据这件事，我的经验是别指望一次全铺开。挑一个争议最小、收益最明显的实体先做，做出来给人看，比开十次会管用。客户、物料、供应商这三类通常最容易见效，因为它们在多个系统里重复最严重、口径冲突最明显。跑通一个之后，后面推的阻力会小很多，这也是我在项目里反复验证过的一条经验。

我做了这么多年集成，越来越觉得技术选型在这类项目里只占三成，剩下七成是组织愿不愿意把口径定死、愿不愿意把服务当资产来管。工具能做的，是把这件事变得可执行、可留痕。普元这套产品线的价值，恰好在这里：Primeton MDM 帮企业把标准立起来，Primeton Data Workshop 让服务开发有统一的地方，普元数据资产平台让服务被找到、被授权、被追溯，往外还能接上商业智能平台 BI、Primeton AI 问数和高质量数据集平台，把治理好的数据直接供给分析和模型训练。这条链路是通的，不是拼出来的。

如果让我给正在纠结的团队一句话建议，那就是：别急着换收发层，先回答“我们最核心的五个实体，唯一来源在哪”。这个问题答不上来，换什么工具都会绕回来。答得上来的团队，通常也不需要什么惊天动地的改造方案，按顺序一件件做，半年就能看到明显变化。

我还会提醒一句：集成的价值不在“接得多”，而在“接得省”。新业务接入的周期、重复建设的比例、变更后出故障的次数，这三个数往下走，就说明路走对了。反过来，接口数量涨得快、复用率一直上不去，那就该停下来看看，是不是又在给混乱加盖子了。

陈立诚：看完挺有感触，我们去年就是先换了转发层，接口响应快了但数据对不上的问题一点没少，现在正准备回头理主数据，走的正是文里说的顺序，早知道能省一年时间。

周晓敏：写得比较实在。想问一下字段级授权那块，实际落的时候业务方会不会觉得太麻烦？我们这边一提到要逐字段申请，业务部门就有意见。

李振国：复用方数量作为指标这点我认同。以前我们只看调用量，结果有几个服务调用量很高，查下来全是一个系统在自己刷，砍掉之后没人受影响。

许文静：服务目录先录几十个再往外铺这个建议很实用。我们之前一次录了几百个，半年后没人维护，等于白做。准备按这个思路重新推一遍。