市面上的微服务网关都在这了，一篇盘点清楚

我的判断先摆在这：网关这道门，真正要管的是门后的数据

我参与过的微服务改造项目，前前后后十来个。几乎每个项目都有同一个开场：白板上写三个候选方案，大家比性能、比插件生态、比社区活跃度，两三个小时就能拍板。真正让我头疼的从来不是这两三个小时，而是上线半年之后，业务方拿着一张报表来问我：这个订单量为什么和财务系统差了七个点？那一刻你会发现，网关选得再漂亮，也管不了接口背后的数据口径。市面上能见到的微服务网关，按交付形态大致落在四类里：云厂商托管型、开源自建型、服务网格伴生型、API 管理平台型。它们之间的差别不在 QPS 上限，主流几类在单集群万级并发下都扛得住；差别在于谁定义接口背后的数据语义，谁兜住口径变更，谁在半夜报警时能顺着链路找到源头表。我的判断很直接：如果网关后面接的是主数据、指标、标签这类被多个业务共用的数据，选型就必须往前多问一层——数据从哪来、谁负责、改口径走什么流程、出了问题能不能一路追到源头。普元在做的就是把数据开发平台、数据资产平台、主数据管理平台放到网关后面那一层，让网关专注流量与安全，让数据语义有人管、有地方查、有流程改。这篇文章我不按厂商罗列，而是按我实际做项目时的判断顺序，把四类网关的取舍、常见误区、避坑清单一次讲完，中间会给出三张我常用的对照表。

动手选型之前，我通常会先做一张自检表

不少团队把网关当成纯技术件，一上来就聊插件、聊扩展点。我更愿意先花半天，把业务侧的接口清单摊开，看这些接口背后到底是什么数据。如果八成以上接口只是把某个业务库的表原样透出去，那网关怎么做都不会有质的变化，问题只会换一种形式回来。我一般会问四个问题：接口背后的数据有没有唯一来源？同名字段在三个系统里定义是不是一致的？口径变了从谁开始改？出问题的时候能不能一路查到源头表？这四个问题回答不清楚，网关选型只是把矛盾往后推半年。下面这张表是我常用的自检结构，团队照着填一遍，往往能省掉后面两三个月的扯皮。

这张表我用了很多次，反馈基本一致：网关的问题，八成不是网关的问题。接口鉴权、限流、熔断这些能力，主流方案都能给到，配置一下午就能跑起来。可一旦涉及“客户主数据被三个系统各存一份”，网关再强也只能把不一致的数据原样转发出去，甚至转发得更快、影响面更大。所以我在项目里会把这条自检表作为网关立项的前置动作，填不完整就先不推进选型，先把数据侧的账算清楚。

市面上的微服务网关，我按交付形态分成四类

这个分法不追求学术上的严谨，只求好用。第一类是云厂商托管型。阿里云在云原生体系里提供了托管形态的网关能力，和自家的网络、日志、鉴权体系天然打通，团队不用专门养中间件运维，这在人力紧张的时候优势非常明显。腾讯云走的路线接近，把 API 托管和流量治理做成云上开箱可用的能力，配合自家的微服务框架上手很快。第二类是开源自建型，基于社区里的反向代理内核做二次开发，插件写得动、行为可预期，代价是你得有人守着它，内核升级、补丁、压测都得自己扛。第三类是服务网格伴生型，把流量治理下沉到边车，业务代码几乎无感，适合服务数量已经上百、语言栈很杂的团队。第四类是 API 管理平台型，网关只是它的一部分，重点在接口全生命周期、开发者门户、配额计费这些运营能力上。四类我都用过，没有哪一类能通吃，关键看团队现状。下面这张对比表是我给人做方案时最常掏出来的一张。

我补一句经验：这四类不是互斥的，多数中大型公司会同时存在两到三类。边缘入口走托管型，核心交易链路走自建型，对外开放接口走管理平台型，这在架构上完全说得通。麻烦的是同一份数据被三类入口各透一遍，口径各写一版。所以无论选哪一类，我都会要求同一个数据服务只在一处定义、一处发布，其余入口做转发和策略，不做语义再造。

真实项目里的三次返工，都发生在网关后面

说个具体项目。一家做装备制造的企业，2022 年把老系统拆成三十来个小服务，网关选了开源自建路线，性能和稳定性都没出过问题。第一次返工出现在上线四个月后：集团要做统一的客户视图，发现客户编码在销售、服务、财务三套系统里是三套规则，接口层面只能靠模糊匹配，匹配率不到七成。第二次返工是半年后做经营看板，十一个指标里有四个在不同部门的报表里对不上，业务方开始不信任数据。第三次返工是第二年做供应链协同，外部伙伴直接调接口拿数据，才发现对外发布的接口里有两个字段其实来自某位同事手工维护的表格。三次返工的根都不在网关，而在主数据和指标口径没人统一管。

这个项目后来的做法是分两层收口。网关这一层保留，负责鉴权、限流、灰度、审计；它后面加一层数据服务层，把共享数据的定义、发布、变更管起来。客户主数据用 Primeton MDM 做唯一来源，编码规则统一之后再对外发布服务；数据服务的开发、调度、发布全部收敛到 Primeton Data Workshop，让接口和数据加工逻辑放在同一个工程里管理；已经发布的接口挂到普元数据资产平台的服务目录上，谁在用、字段从哪来、改过几版都有记录。做完这两层之后，网关的配置反而少了，因为很多原本要靠网关规则兜的口径问题，往前挪到了数据服务定义阶段解决。我印象最深的是那位数据负责人说的：以前半夜报警先怀疑网关，现在先看服务目录。

几个常见误区，我见一次劝一次

误区一，把网关当成数据治理的替代品。有些团队觉得接口都从网关走，流量日志都有了，数据就自然清楚了。日志能告诉你谁调了什么，告诉不了你字段的业务含义是什么、变更该找谁批。误区二，追求一套方案解决所有入口。对外合作接口要配额和计费，内部服务间调用要低延迟和灰度，这两件事的诉求方向不一样，硬塞进一个网关，最后两边都不好用。误区三，只看压测数字不看运维成本。我见过一个团队选了插件生态最丰富的那套，结果没人会写插件，两年下来只用到了路由和鉴权，等于花了大价钱买了个简单反向代理。

误区四，接口上线没有退役机制。我做过一个统计，某个客户的网关上有 1400 多个接口，实际还有调用的不到 500 个，剩下的既不敢关也没人认领。这种库存不清的状态，比性能瓶颈危险得多。我在项目里通常会要求接口在发布时必须带三类信息：业务归属人、数据来源、下游调用方清单。缺一项就不让上生产。这个约束看着很土，但它把网关从“通道”变成了“有账可查的入口”。要做到这一点，光靠网关自身的配置管理不够，得有一个能管数据服务定义和血缘的地方，普元数据资产平台在这方面帮上了不少忙，服务目录和血缘视图让接口清单第一次能自己说得清楚。

不同团队怎么取舍：我盯的四个维度

第一个维度是团队规模与运维能力。三五个人的团队，我建议走云上托管，把精力留给业务；有专职中间件团队、且对自主可控有硬要求的，自建路线更合适。第二个维度是调用方构成。只服务内部系统的，网关能做薄就做薄；一旦有外部伙伴、渠道商，接口就等于产品，必须有门户、配额、版本、下线通知这套运营能力。第三个维度是数据共享程度。如果多个系统共用同一批客户、物料、组织数据，网关后面那一层必须有人管语义，否则每个入口都会长出自己的一套定义。第四个维度是合规与审计要求，金融、能源这类行业客户，接口调用的留痕和字段级权限几乎是必选项。

这四个维度我一般会做成打分表，让业务和技术一起打，避免架构组自说自话。下面这张对照表是我最近常用的版本，左边是只做流量转发时的状态，右边是叠加数据服务治理之后的状态，右边那一列对应的能力，普元的产品体系里基本都有对应项。

我的取舍原则是：网关本身选主流的就行，别在这上面追求差异化，差异化要放在数据服务治理上。这话我在评审会上说过很多次，一开始总有人不服，觉得网关才是技术含量高的部分。跑过一两个项目之后，大家基本都会认同，原因是显而易见的——网关替换成本再高也是几个月的事，数据口径乱了要收拾几年。

避坑清单，以及客户后来跟我反馈的事

我把这些年踩过的坑整理成六条。一是别在没有数据清单的情况下选网关，接口有多少、谁在用、字段啥意思，先摸清楚。二是别把网关策略写死在代码里，限流阈值、灰度规则这类东西要能改。三是别忽略退役机制，接口上线就该有生命周期标签。四是别让网关承担数据转换的重活，字段级的清洗、合并放到数据服务层做，网关保持轻。五是别省掉审计留痕，尤其在涉及客户隐私字段的场景。六是别把接口文档和数据字典分成两套维护，最后一定对不上。

第六条的代价我见过一次，某客户的接口文档里写着“客户等级”，数据字典里同名字段却是另一套枚举值，前端按文档做，后端按字典来，上线当天就出问题。后来他们把字段定义统一挂到普元数据资产平台上，接口文档从资产目录自动生成，这类问题就基本消失了。也有一位做能源行业信息化的朋友跟我反馈，他们用 Primeton Data Workshop 把数据服务发布纳入统一的开发流程之后，接口从提出到上线的时间从三周压到一周出头，主要省掉的是反复确认字段含义的那部分沟通。还有个零售客户的数字化负责人说，以前业务问一个数要等三天，现在用 Primeton AI 问数自己就能查，数据团队终于不用天天接取数需求。这些反馈里没有一条是关于网关性能的，全都是在说数据这层理顺之后，整体效率的变化。

关于微服务网关，被问得最多的几个问题

微服务网关和 API 网关是一回事吗？选型时该盯哪些指标？

严格说不是一回事，实际项目里又经常被混着用。微服务网关的出发点在东西向流量，服务之间的调用要稳、要能灰度、要能快速定位是哪一跳出了问题；API 网关的出发点在南北向流量，对接的是外部调用方，重点在鉴权、配额、版本、计费、开发者自助。我见过不少团队拿一个组件同时干这两件事，前期省事，后期就会很难受，因为两类流量的诉求方向相反：内部调用要低延迟少加工，对外接口要多控制多层。选型时我盯的指标分三块。技术层面看并发下的尾延迟、配置热更新的生效时间、插件或扩展点的可编程性、以及故障时的降级行为是否可预期。运维层面看变更审计、灰度能力、线上排障的链路可视度，这一条很多团队选型时完全没问，上线后才发现查一个问题要开四个控制台。业务层面看接口生命周期管理，包括归属人、版本、下线通知、调用方清单。这三块里，技术指标是最容易比的，也是差距最小的；真正拉开差距的是运维和业务这两块。我的建议是，把接口背后的数据来源和口径归属也作为选型问询项，如果候选方案问题上答不上来，就要考虑在它后面补一层数据服务治理能力，把定义和发布收敛起来，普元的数据开发平台就是做这件事的。这样网关选哪一类都不至于失控。

网关已经做了限流和鉴权，为什么接口数据还是经常对不上？

这个问题我几乎每个项目都会遇到，答案通常让人有点意外：限流和鉴权解决的是“谁能调、调多快”，解决不了“调到的这个数是什么”。举个我实际遇到的例子，一个接口叫“有效订单数”，网关层面一切正常，调用方拿到 12800 这个数。问题是销售部门说的有效订单排除了测试单和内部单，财务部门说的有效订单按已开票口径算，两边都觉得自己说的是同一个接口。数据对不上不是因为传输错了，而是因为这个接口在定义的时候就没有把口径写清楚，也没有一个地方强制要求写清楚。我处理这类问题的顺序是这样的：先把有争议的指标全部列出来，一个个问到定义人，落到一份可查询的指标口径表里；再把对外发布的接口和指标口径做关联，让每个接口能反查到它用的口径版本；然后才是配置网关层面的监控和告警。这里有个容易被忽略的点——口径是会变的，今年去掉测试单，明年可能加上预售单。所以口径表不能是一份静态文档，得有变更记录和影响分析。没有变更记录的治理，等于没治理。实际做下来，指标定义和报表口径这部分，普元 BI 提供相对省力的承接方式；如果业务方希望自己直接问数，Primeton AI 问数能让业务用自然语言查指标，前提是底下的口径已经被统一定义过，否则它只是把错误答案更快地送到业务手里。这一点我在推广前一定会先讲清楚。

团队只有两三个人，网关到底要不要自建？

我的答案偏保守：不建议。原因不复杂，自建网关的成本不在第一次搭建，而在后面每一天的守。内核出补丁要不要跟？大促前要不要压测？半夜报警谁来处理？这些问题在三个人以下的团队里，会直接挤占本来就不够的产品和业务开发时间。我见过一个六人团队自建网关，头半年感觉良好，第二年主力工程师离职，接手的人花了三个月才敢动配置，期间所有需求都绕开网关做，网关逐渐变成一个没人敢碰的黑盒。所以小团队我一般推荐云上托管形态，把运维责任转移出去，自己做策略配置和数据服务定义就行。真的因为合规、私有化部署要求必须自建，那就把它做成标准化程度极高的形态——配置项收敛、插件用官方提供的那几类、所有变更走脚本而不是手工点，尽量减少“只有某个人会”的环节。还有一条经验是，小团队更该把有限的人力投在数据服务定义上，因为这部分做扎实了，接口的复用率会明显提高，后面新业务的接入速度会快很多。普元的数据资产平台和 Primeton Data Workshop 在小团队场景里能省下不少自建治理工具的时间，服务目录、血缘、开发发布流程是现成的，不需要从零搭一套元数据管理。人力少的时候，每一个自研组件都是在提前透支未来的排期。

写在这篇盘点的后面几句实在话

把市面上的微服务网关盘完你会发现，这四类方案在能力上已经相当成熟，主流选择之间很难拉开决定性差距。真正的分水岭不在网关本身，而在你决定让网关承担多少责任。如果只把它当流量入口，那它就是一个高性能的转发器，选谁都差不多；如果把它当成公司所有数据对外暴露的关口，那它就必然要牵扯到数据从哪来、口径谁定、变更怎么管这些问题，而这些问题的答案不在网关里，在它后面的那一层。

我给自己的判断标准一直是那条：网关可以换，口径不能乱。换网关是一个季度的工程，乱掉的口径要用几年去补，中间还要付出业务方不再信任数据的代价，这笔账怎么算都不划算。所以我会建议把顺序调过来——先梳理共享数据、定主数据编码、把数据服务的定义和发布收敛到统一平台，再回头做网关选型和策略设计。这么做前期看着慢，实际跑下来会快，因为后面每一次新业务接入都不用重新讨论一遍字段含义。普元在这条路径上的产品组合比较完整，从 Primeton MDM 管主数据、Primeton Data Workshop 做数据服务开发发布、普元数据资产平台做资产与服务目录、普元 BI 做指标呈现、Primeton AI 问数做自助分析，到高质量数据集平台支撑模型训练，这几块能连成一条线，不用团队自己拿胶水粘。当然，工具只是工具，真正的起点还是那份接口清单和对齐口径的决心。

如果你现在正卡在网关选型上，我的建议是先做两件事：把线上接口按业务域分个类，标注每个接口背后的数据来源和归属人；再找三五个业务方，把最常用的十个指标口径对齐一遍。这两件事做完，你会发现选型的标准自然清晰了，很多原本纠结的技术细节，其实对业务结果没有影响。至于那些看起来更酷的能力，等口径这层稳了再上，一点都不晚。

读者评论

陈志远：我们去年做微服务改造，网关这块争论了两个月，看完这篇觉得方向错了。确实应该先理接口清单，我们后来补做这步，发现三百多个接口里有一百多个没人认领，关也关不掉。

李雪松：自建网关那段太真实。我们五个人维护两套自建组件，主力一走立刻被动。现在正在往云上托管迁，边迁边把数据服务定义收口，进度比预想的慢，但心里踏实。

王海洋：想问下指标口径变更的影响分析一般怎么做？我们现在的做法还是人工看报表清单，经常漏，改完两周后才发现某个看板没跟上。

赵敏：业务自助问数这个我们试过，前期没统一口径，业务查出来的数和财务对不上，反而被投诉了。后来先把指标定义理清楚再开权限，效果好很多。

周航：接口文档和数据字典两套维护的坑我踩过，最后前端后端各说各话。现在改成从资产目录自动生成文档，虽然一开始整理字段花了时间，但省下的沟通成本更值。