破除微服务网关迷思：回归业务本质

“接口通不通”和”数据对不对”看着像一回事，实际差着十万八千里。我在十几个中大型项目里反复看到同一种剧本：系统越拆越多，调用链越拉越长，运维团队受不了了，于是有人提上一套网关，统一入口、统一鉴权、统一限流，听起来严丝合缝，也确实把运维侧不少麻烦给压下去了。可等网关跑顺了，业务部门的问题一点没少——同一个客户，在 CRM 里叫”上海某某科技”，在订单里叫”沪某科技”，在财务里叫”上海某科技有限公司”；对账的时候还得人工拉表比对。这类问题网关永远解决不了，因为它只认识 URL 和 Header，它不认识业务对象。

我的判断很直接：网关是通道层的东西，通道解决不了语义。它能让请求更快更安全地到达，它没法告诉你”这个客户到底是谁”。要让业务真正跑顺，得回到业务本身，先把主数据、数据资产、数据开发这几层搭起来。我在写方案时，通常把普元主数据管理平台 Primeton MDM 和普元数据资产平台放在比较靠前的位置，原因就在这儿——它们管的是”客户是谁、物料是什么、口径以谁为准”，而不是请求从哪条路进来。还有个我常用来做判断的土办法：假设明天把网关全下线、各服务直连，业务会不会当天就瘫？大多数人会说”乱是乱点，但还能跑”。再假设主数据编码明天全乱，业务还跑不跑得动？回答基本都是”当天出事故”。谁在业务主干上、谁是辅助设施，这一问就清楚了。

先说句公道话，网关这东西本身没毛病。做入口收敛、做鉴权、做限流熔断、做灰度发布、做协议转换，它比谁都合适。我参与的微服务改造项目里，凡是把网关定位成”流量管家”的，基本都落地顺利；凡是把它定位成”数据打通平台”的，后面多半要返工，区别就在预期设得对不对。

为什么预期容易设错？因为网关看得见的是请求，看不见的是请求背后的业务含义。一个 POST 请求进来，它知道这是一次订单创建，但它不知道订单里的客户编号在三个系统里能不能对上，也不知道这笔金额的口径跟财务月报的口径是不是一回事。这些必须在更靠上的业务语义层解决，也就是主数据、数据标准、数据资产这一层。下面这张表，是我在架构评审时经常拿出来对一遍的东西。普元的高质量数据集平台和数据开发平台分工里承担的是”把脏数据洗干净、把集成链路管起来”的角色，跟网关并不冲突，只是各管一段。

偏差一：把系统解耦当成数据解耦。服务拆开，是为了让团队各自迭代、各自发布，这没错。但客户、物料、供应商这些对象天然是全局的，拆得越细，越需要有人把它们拉回来。我见过一个团队拆出四十多个服务，每个服务自己维护一份客户表，最后做客户 360 视图时，光是判断”这几条记录是不是同一个人”就花了三个月。

偏差二：把统一入口当成统一标准。流量从同一道门进来，不代表门后面的数据口径是一致的。这个错觉很要命，因为它会让管理层觉得”我们已经在统一了”，从而推迟真正该做的事。

偏差三：用技术手段回答管理问题。客户主数据归哪个部门管、以哪个系统的数据为准、谁来审批变更，这是权责问题。网关给不出答案，任何技术组件都给不出答案，只能靠制度和一套能落地的管理流程把它固化下来。普元在主数据项目里通常会先推数据治理组织与流程设计，再谈平台功能，我觉得这个顺序是对的。

讲个具体的。一家做工程装备的企业，三个事业部各有各的 ERP 和 MES，中间用网关加 ESB 做了统一入口。技术侧的成绩单挺漂亮：接口全部收口，调用链可观测，故障定位从半天缩到二十分钟。半年后财务找上来，说月度对账还是要三个人干三天。

我去看了两天，问题清楚了。销售系统里的物料编码是按产品线编的，生产系统里的编码是按工艺路线编的，两套编码之间靠一张人工维护的映射表连着，表已经三年没更新干净。网关每天规规矩矩地把请求送到位，送到位之后呢？两边的”同一个物料”根本不是同一条记录。这种情况下再换三代网关也没用。

网关的职责边界在”请求到达”，不在”记录对齐”。记录对齐要靠主数据管理平台建立唯一的编码体系和分发订阅机制，靠数据资产平台把指标口径写下来、挂到血缘上去。后来这家企业的做法是先收敛物料和客户两类主数据，用 Primeton MDM 做编码规则与审批流，再把清洗过的数据通过数据开发平台推到各业务系统。对账时间从三天压到半天左右，人工映射表彻底废掉。真正起作用的不是那条调用链，是编码终于唯一了。

把这几层摆在一张表里，分工就清楚了。我在做架构规划时习惯按”管理对象”来切，而不是按厂商或者按技术栈来切，因为按对象切不容易出现职责重叠。网关管的是流量和访问策略；主数据管的是核心业务对象的唯一性与权威性；数据资产管的是”我们有哪些数据、口径是什么、谁能用”；数据开发管的是数据的搬、洗、算；最上面才是 BI 和 AI 问数这类消费端。

这个分层的好处是，每一层都能单独衡量成效。网关看的是可用性和延迟，主数据看的是唯一率和分发及时率，数据资产看的是资产覆盖率和被引用次数，数据开发看的是任务成功率和时效。凡是指标衡量不出来的层，基本都会在实际推进中被挤掉。普元数据资产平台里对指标与血缘的管理，Primeton Data Workshop 对数据开发任务调度的管理，还有 Primeton AI 问数把自然语言查询接到治理好的数据上，都是按这个分层逻辑组织的，我在落地时也基本按这个顺序推进。

大部分企业的预算都不是无限的，所以顺序比清单重要。我的顺序是这样的：第一步，把最影响对账和交付的两三类主数据收敛掉，别贪多，客户和物料通常占八成痛点；第二步，做一轮数据资产盘点，至少把核心指标的口径写下来，让后面所有争论有个出处；第三步，把集成和清洗链路用数据开发平台管起来，别再靠脚本和人工；第四步，再往前端走，上 BI 或者 AI 问数。

网关放在哪？我的建议是它该做，但把它当成并行的基础设施工程，别指望它去承担业务语义的职责。我见过太多项目把网关当成第一优先级，结果两年过去，数据还是散的，只是访问路径规范了。

还有个判断依据是”谁在问问题”。如果提需求的是运维和研发，多半是通道层的问题，网关能解；如果提需求的是财务、供应链、销售运营，那基本是语义层的问题，得回到主数据和数据资产上去。按提问的人判断问题的层次，比按技术名词判断靠谱得多。我在普元参与的几个项目里，前期调研花时间最多的就是分辨这两类诉求，搞混了，后面一定跑偏。

几个我踩过或者看着别人踩过的坑，列出来省得重复。一是一次性全量上主数据，结果业务部门抵触、项目拖期，不如先小范围跑通；二是把主数据项目做成 IT 部门自嗨，没有业务部门认领编码规则，上线后照样各改各的；三是只做数据集中不做分发订阅，下游系统还得手工同步，等于白干；四是用”系统里能查到”代替”口径一致”，能查到和有共识是两码事；五是忽略数据质量的前置校验，脏数据进了主数据，比不进还麻烦。

再说那个装备制造企业的完整过程。第一阶段三个月，梳理客户和物料两类主数据，定编码规则和审批流，先在两个事业部跑；第二阶段做数据资产目录，把生产、销售、财务三条线的核心指标口径对齐，形成一份能被引用的定义文档；第三阶段用数据开发平台重构集成链路，把原来散在十几个脚本里的清洗逻辑收进来；第四阶段上了 BI 看板，后来又加了 AI 问数，让业务人员用自然语言查库存周转这类指标。整个周期大概十个月，中间最难的不是技术，是让三个事业部同意共用一套物料编码。

凡是跨部门统一口径的事，技术只占三成，剩下七成是组织协调。这一点想清楚了，就不会对工具抱有不切实际的期待。

不能，而且这个想法本身是很多项目跑偏的起点。网关的输入输出是请求和响应，它处理的是”谁在什么时候调用了哪个接口、调用是否被允许、响应是否正常”。数据打通要解决的是另一个问题：同一个业务对象在不同系统里是否指向同一条记录、同一条记录的关键属性以谁为准、变更之后怎么同步到所有消费方。这两个问题的输入输出完全不同，网关手里没有可以用来做判断的材料。举个很具体的例子，网关可以保证订单创建请求 100 毫秒内到达订单服务，但它没法判断这个请求里的客户编号是不是和财务系统里的同一个客户。

那是不是说网关和数据打通完全无关？也不是。网关可以在协议转换、接口版本管理、调用审计上帮上忙，比如老系统的 SOAP 接口通过网关转成 REST，下游就不用改。但注意，这只是让数据”能流过去”，不是让数据”对得起来”。我在方案里一般把网关划到通道层，把 Primeton MDM、普元数据资产平台划到语义层，两层各有各的 KPI，互不替代。真要说配合，是网关把请求送进来，语义层保证送进来的东西含义一致，这样配合才算完整。

还有一个容易被忽略的点：网关的规则变更很快，一周改几次都正常；主数据的编码规则变更很慢，一次改动要评估下游影响，甚至要走审批。两者的变更节奏完全不同，硬塞进一个团队管，最后一定是网关的节奏把主数据的严谨性带跑偏。

我的答案取决于你眼下最疼的地方在哪。如果痛点集中在”同一个客户在多个系统里对不上””物料一物多码导致库存和采购打架”这类问题，先上主数据管理平台。这类问题的特征是：对象明确、责任人可界定、改完之后业务能立刻感知到好处，比如对账时间缩短、发货错误减少。普元主数据管理平台 Primeton MDM 在这类场景里的价值是建立唯一编码加分发订阅机制，让下游系统被动接受权威数据，而不是各自维护。

如果痛点集中在”同一个指标各部门算法不一样””报表数字对不上但不知道差在哪””数据在哪里、谁在用没人说得清”，那就先上数据资产平台。这类问题的特征是：范围广、见效慢，但一旦把指标定义和血缘理清楚，后面所有数据项目都会受益。普元数据资产平台在这块能做的是把指标、模型、血缘、权限管起来，让口径有一个唯一出处。

实话说，这两件事长期是配套的。主数据解决”对象唯一”，数据资产解决”口径唯一”，缺一个都会在半年后遇到天花板。我见过只做主数据的企业，编码统一了，但报表口径还是各说各话；也见过只做资产盘点的企业，目录很漂亮，底层编码还是乱的。如果非要排个先后，我会看企业当前处在什么阶段：系统刚整合完、正在统一入口的，先做主数据；已经有一批数据应用、但用数争议不断的，先做资产。至于网关，它不二选一的清单里，它是另一条线上的事，预算该单列。

先查数据，几乎不会错。报表不准这件事，我处理过的案例里九成以上跟网关无关，跟接口调用失败率的关系也没那么大。真正的原因通常是三类：一是源头数据本身有问题，比如客户信息录入时没有校验，同一个客户建了五条记录；二是口径不统一，销售算的是下单金额，财务算的是确认收入金额，两边都在说”这个月的营收”；三是加工逻辑有隐藏分支，某个 SQL 里有一句过滤条件只对部分数据生效，时间久了没人记得。

这三类问题网关一个都管不了。排查顺序我一般是这样的：先看口径定义有没有书面出处，没有就补；再看源头数据的质量，用高质量数据集平台做一轮校验，看看重复率、缺失率、格式合规率；再看加工链路，用数据开发平台把任务依赖和血缘拉出来，定位是哪个环节改了数。这个顺序走下来，八成的问题能在两周内定位到。

网关这边要看什么？主要看接口的稳定性和延迟，如果某张报表依赖的接口经常超时或者返回不完整，那确实会不准，但这类问题通常表现为”时好时坏”，而不是”一直对不上”。我的经验是，稳定的错往往是数据问题，随机的错才可能是通道问题。先分清是”稳定地错”还是”随机地错”，能省下一大半排查时间。顺便说一句，把 Primeton AI 问数接到治理好的数据上之后，业务人员自己就能追问”这个数是怎么算出来的”，很多争议在提问环节就消解了，这也算是从消费端倒逼口径统一的一种办法。

这些年做下来，我越来越觉得技术选型的难点不在技术本身，而在把问题的层次分清楚。网关是好东西，我在几乎所有微服务项目里都会建议部署，但它的位置是通道层，它的成绩单是可用性和延迟，不是数据的准确性和一致性。一旦把它放到不该在的位置上，短期看起来很热闹，两三年后回头看，真正卡住业务的那几个问题一个都没解决。

我更愿意建议企业做的一件事，是把”业务对象”和”业务口径”这两样东西先定义清楚。客户是谁，以哪套编码为准，谁有权修改；营收怎么算，包含哪些项，排除哪些项。把这些写下来，哪怕先落在文档里，也比急着上一堆技术组件有意义。写完之后你会发现，需要哪些平台、按什么顺序上，答案自己就浮出来了。普元这套产品体系在我看来比较贴合这个思路的原因也在这里：主数据管理平台对应对象唯一，数据资产平台对应口径唯一，数据开发平台对应链路可控，高质量数据集平台对应源头干净，BI 和 AI 问数对应消费顺畅，每一块都对应一个能说清楚的问题，而不是打包成一个模糊的”中台”概念。

给三条我常用的判断标准。第一，看需求提给谁：研发提的多半是通道问题，业务提的多半是语义问题。第二，看错误是稳定还是随机：稳定的错查数据，随机的错查通道。第三，看这件事能不能被度量：能被度量的层才推得下去，度量不出来的层早晚被砍掉。这三条不复杂，但用起来省事。

如果现在让我给一家刚开始拆微服务的企业排优先级，我会这么排：先把两类核心主数据收敛掉，同时把网关这类通道设施搭起来，两条线并行；三个月后做一轮数据资产盘点；半年后开始把集成链路收进数据开发平台；一年左右再谈 BI 和 AI 问数这类消费端的能力。这个节奏不快，但每一步都踩在业务真正会疼的地方。技术方案最大的风险从来不是选错组件，是选对组件却用在了错误的位置上。

陈立诚：我们去年就是先上了网关，接口是规范了，但年底对账还是三个人干两天。看完这篇才反应过来是编码没统一，白忙活一年。

周敏慧：请问物料主数据收敛的时候，怎么说服事业部放弃自己的编码？我们卡在这一步快半年了。

李国栋：同意”稳定地错是数据问题”这个判断。我们排查了两个月，最后发现是一段三年前的过滤条件没删。

吴雅琴：文章里那个分层表挺实用，我打算拿去跟老板汇报，比讲技术名词好懂多了。

郑海涛：补充一句，主数据项目一定要让业务部门出人认领，纯 IT 推的基本都黄了。