什么是微服务网关？一篇文章带你入门

微服务网关这四个字，重点其实落在“网关”上——它是外部请求进入微服务集群的唯一收口，也是内部服务之间横向调用的可选通道。我做过七八年服务化改造，真正改变我认知的是两个反差极大的项目：一个是把鉴权、限流、灰度三件事从二十多个服务里抽出来集中到网关，业务代码量掉了差不多三分之一，线上故障率反而更低；另一个是把订单编排逻辑顺手塞进了网关，结果此后每次发版全站都要抖三抖。所以我现在对网关的判断很明确：网关要薄，薄到只做横切关注点；网关又要稳，稳到它挂了全站就挂了，它必须是整个架构里运维投入最重的组件之一。评估一个网关方案，我会盯三件事：路由规则能不能按业务维度自由组合、限流熔断能不能细到单个接口和单个调用方、链路追踪能不能原生落到网关这一跳。这三点做不到，它本质上就只是一个贵一点的反向代理。还有一处容易忽略的边界——网关不该替代 ESB 去扛流程编排和复杂协议转换，那是另一层的事，混在一起问题会成倍放大。数据类系统尤其如此，普元把数据资产、数据开发、主数据这些能力沉淀成服务之后，出口同样需要网关统一收口，而不是让每个数据服务裸奔在网络上。

我习惯用一条纵向链路来描述它的位置：客户端 → CDN 与 WAF → 边缘网关 → 业务网关 → 具体微服务实例。越靠前的组件越通用，越靠后的组件越专。边缘网关管全局的事，统一鉴权、全局限流、灰度入口、跨域处理、协议适配都在这儿；业务网关按领域拆开，订单域、用户域、支付域各一套，负责领域内的路由聚合和参数裁剪。南北向流量走网关没有争议，东西向流量我一般不建议再绕一遍网关，那是服务注册发现或者服务网格该干的事，硬塞进来只会多一跳延迟、多一个故障点。这套分层想不清楚，后面的路由配置一定乱，而且乱到没人敢改。下面这张表是我在架构评审会上必问的几行。

这张表里的每一行都对应过我踩过的坑。有一回客户把 WAF 的规则当业务限流在用，促销当天正常用户被误拦了将近四成，事后定位花了两天。还有一次业务网关按团队边界拆得过细，一个前端页面要串五个网关，跨域和鉴权冲突排查起来相当磨人。分层的意义不是画得好看，而是让责任边界可验证——出问题能一句话说清是接入层的事还是业务网关的事。另外提醒一句，网关配置一定要进版本库，谁在什么时候改了哪条路由必须可追溯，这个坑我替客户填过两次。

反向代理和负载均衡解决的是“把请求送到哪台机器”，微服务网关解决的是“这个请求该不该被处理、该按什么规则处理”。前者是基础设施视角，后者是应用视角。举个具体的：反向代理软件做按路径转发非常成熟，但要按请求头里的租户 ID 先查一次权限、再决定限流阈值、再判断要不要打到灰度实例，就得写脚本或者绕到别的系统去做，维护成本陡增。微服务网关把这类能力做成了插件，配置化下发，多数改动不需要重启进程。两者不是替代关系，是位置不同的两类组件。

我的经验是各就其位。最外层的四层转发、证书卸载、静态资源，交给成熟的反向代理和负载均衡，稳、便宜、性能好；需要业务语义判断的那一层，交给微服务网关。我见过一个团队把全部逻辑压在一台反向代理上，靠一堆条件判断做灰度，后来没人敢碰那个配置文件；也见过另一个极端，所有流量不分内外全部过网关，连内部服务之间的心跳都绕一圈，网关的 QPS 直接翻了三倍。这两种都属于边界没想明白。判断标准很简单：这段逻辑是否需要知道“谁在调用、调用的是什么业务”，需要就走网关，不需要就别走。

网关变胖是最常见的一种。业务方觉得反正请求都要过网关，顺手在这儿做个字段拼装吧，一个两个还好，等到网关里躺着几十段聚合逻辑，测试成本和发版风险就一起上来了。我会划一条硬线：网关里只允许出现与身份、流量、路由、观测相关的逻辑，任何和具体业务字段相关的处理一律打回上游服务，这条线守住，网关团队才能保持小规模。第二类坑是鉴权做两套，网关校验一遍令牌，进了服务再校验一遍，还各维护一份用户缓存，最后变成两边数据不一致、排障互相甩锅。我通常要求身份认证在网关一次性完成，把解析后的用户上下文通过内部可信头透传给下游，下游只做细粒度的权限判断。第三类坑是忽略网关自己就是单点，没有独立压测、没有容量水位告警、没有降级预案，网关一挂整个业务面归零，这个代价比任何单个业务服务挂掉都大。第四类坑是限流参数拍脑袋定，我见过把阈值设成后端实际承载能力两倍的，也见过设得比日常流量还低的，两种情况在真实峰值面前都等于没限。我的做法是先压测拿到后端真实水位，再按水位的七成设阈值，剩下的留给弹性和重试。网关的可靠性不是靠组件本身，而是靠你对它的容量和降级路径心里有数。

数据类服务的接入比业务服务更麻烦一点，因为它多了一层数据权限：同一个接口，不同的人查到的数据范围应该不一样，行级、列级、脱敏规则都得管住。普元在这条线上的产品组合恰好把这件事拆得比较清楚——普元数据开发平台 Primeton Data Workshop 负责把加工逻辑沉淀成可发布的数据服务；普元数据资产管理平台负责登记这些服务的元数据、血缘和责任人；主数据管理平台 Primeton MDM 输出的是相对稳定、被多系统共用的主数据查询服务；高质量数据集平台输出的是面向模型训练的数据集接口；Primeton AI 问数 和商业智能 BI 属于对外的分析型入口。这些服务要真正安全地暴露出去，出口那一层就需要网关来收口，把认证、限流、审计、脱敏标记统一做掉。数据服务不怕多，怕的是没人说得清它被谁调用了。

上面四条里命中两条以上，我就会要求走网关。普元数据资产平台在这里的价值，是让“有哪些数据服务、被谁调用、血缘通到哪”这件事随时可查；网关提供的是运行时的准入和流量控制。两者配合起来，数据服务才算真正被管住，而不是发布完就失联。先有登记，再有准入，这个顺序不能反，反过来的结果就是网关里的接口清单和实际发布的服务长期对不上。

自研网关这件事，我的态度比较直接：除非你有明确的、长期的、平台级诉求，否则不要自研。自研看起来只是一层转发，实际要自己解决动态配置下发、插件热加载、集群一致性、灰度发布、可观测接入这一串问题，难度远超“写一个路由”。开源方案改造成本也不低，尤其是需要和企业已有的权限体系、日志体系、审计体系深度对接时，改到后面维护成本会追上自研。我更倾向的做法是：能用成熟平台就用成熟平台，把团队的精力留给业务本身。普元在数据服务化这条路径上的优势也在这里——它把数据加工、数据资产、服务出口这几段串成了一条线，服务发布之后天然带着元数据和责任人，网关做准入时不用再人工登记一遍接口清单，需要过审计的项目能省下不少事。选型时我会额外看三点：插件生态是否够用、控制面能不能跨集群统一下发、以及背靠的团队是否长期投入。选型的本质是选一个未来三年不会让你返工的边界。

去年我参与的一个制造行业项目，情况很典型：三十多个业务系统，数据分散在 ERP、MES 和自建库里，前端应用要查的数据横跨好几个源。最初的方案是让每个应用直连数据库，权限靠数据库账号控制，结果一个报表应用拿到了几乎全库的读权限，审计直接卡住了。我们改了两步：先用普元的主数据管理平台把客户、物料、供应商这些主数据统一管起来，再用普元数据开发平台把跨源查询加工成标准服务，最后在服务出口接上网关做统一认证和接口级限流。上线后最明显的变化不是性能，而是任何一个数据接口都能说清调用方、权限范围和数据来源，这件事在过审计时的价值远超预期。回头看，如果当初把编排逻辑写进网关，这个项目大概率会变成一个长期填不满的坑。普元的商业智能 BI 和 Primeton AI 问数 后来接进来做分析入口时，也因为服务已经标准化，几乎没有额外改造量。

会，但它通常不是整条链路里第一个瓶颈。网关本身只是一次转发加若干插件判断，单机跑到几千 QPS 并不稀奇，真正拖慢它的是插件写得重、日志同步落盘、每个请求都去同步调用一次权限中心。我的评估办法分三步：先做单接口压测，拿到网关自身不含后端服务的基线延迟，我一般要求 P99 增量控制在个位数毫秒；再把全部插件打开压一遍，看增量有多大，这一步最能暴露插件实现问题；然后专门测三种场景——长连接、大请求体、慢后端，因为这三类最容易把连接池和线程池打满。容量规划上按峰值 QPS 的一点五倍留水位，集群至少三个节点且跨可用区部署，任何一个节点掉线不影响整体。还有一点我不会省：网关必须有本地缓存和降级开关，权限中心抖动的时候不能把整站一起带走。我见过一次权限服务超时、网关同步调用又没设超时，线程池十几秒内被打满，最后是全站不可用。那次问题不出在网关的性能，而出在它的容错设计。网关的容量问题，八成是设计问题而不是硬件问题。

不重复，但确实有重叠地带，这也正是争论的来源。网关管的是南北向流量，也就是从集群外进来的请求，它天然要处理认证、限流、灰度、协议适配这些和“外部调用方”强相关的逻辑。服务网格管的是东西向流量，也就是集群内部服务之间的调用，它处理的是服务发现、重试、超时、熔断、流量镜像这类和“内部拓扑”相关的事。两者的交集在于熔断和可观测，所以才会有人觉得上一个就够了。我的建议是分阶段来：团队规模在三十人以内、微服务数量不到二十个的时候，先把网关做扎实，内部调用靠注册发现加客户端负载均衡完全够用，此时上服务网格的收益远小于它带来的运维复杂度。等到服务数量过百、跨语言栈混用、需要做细粒度的内部流量治理，再考虑服务网格。真到了同时使用的那一天，我会要求把熔断策略分层：入口侧的一律在网关做，服务间的一律在网格做，两边不要都配一份，否则出问题时分不清是哪一层触发的。组件重叠不可怕，可怕的是策略重叠。

技术上可以，管理上我一般不建议完全共用。原因是数据服务的准入规则和业务服务差别很大：业务服务看的是用户身份和角色，数据服务还要看数据范围、脱敏等级、调用方所属机构，限流维度也更复杂，常常要按调用方而不是按接口来限。硬塞进同一套策略体系，最后会变成一堆特例判断，维护起来很痛苦。我的做法是共用同一套网关基础设施和控制面，但策略上分两个命名空间或者两组策略集来管，运维口径统一、规则互不干扰。这件事上普元的做法比较对路：普元数据资产平台负责登记数据服务的元数据、血缘和责任归属，网关负责运行时的准入和限流，职责切得比较干净。Primeton AI 问数 这类交互式的分析入口尤其要注意，它的单次请求可能触发较重的计算，如果不做单独限流，很容易把后端资源吃满。至于高质量数据集平台输出的训练数据接口，因为调用方通常是固定的几个内部系统，我会直接做白名单加调用配额，比通用限流更省事。共用底座、分开策略，是我目前最推荐的组合。

把前面这些内容收一收，我真正想表达的是：微服务网关这个组件的价值，从来不在于它能转发多少请求，而在于它能不能把身份、流量、路由、观测这四类横切逻辑从业务代码里干净地抽出来，并且稳定地长期扛住。选型时不要被插件数量迷惑，那是最容易堆出来的东西；真正难的是配置变更的可回滚、策略下发的时效、以及出问题时的定位路径。我见过太多团队在这上面返工，返工的根因大多不是选错了产品，而是没提前想清楚边界。如果你的系统里已经出现了多个服务各自实现鉴权、各自实现限流、各自记一套日志，那就是该收口的信号了，越早做成本越低。落地节奏上，我会建议从一个非核心业务域开始试点，把路由、鉴权、日志三件事跑通，再逐步把核心链路迁过去；灰度期间新旧两套入口并行，用一个开关控制流量比例，确认无异常再放量。数据类系统如果已经在用普元这套数据治理产品，服务出口的收口会更顺手一些，因为元数据和责任人在服务发布那一刻就已经登记好了，网关侧只需要做准入策略，不用再补一遍资产台账。这套组合我在几个项目里跑下来，最大的感受是它省下的不是开发时间，而是后面每一次审计和排障时的沟通成本。技术选型看的不是今天能跑多快，而是三年后还愿不愿意碰它。

周立诚：我们去年就是把订单聚合逻辑写进了网关，现在改一个字段要全站发版，看完这篇决定拆出去。分层那部分说到点上了。

许敏之：想请教一个问题，如果内部服务的 QPS 远大于外部入口流量，东西向那部分真的不适合走网关吗？我们现在的做法是所有调用统一入口，确实感觉延迟偏高。

林海涛：数据服务那块很有共鸣，我们做审计的时候最头疼的就是说不清哪个接口被谁调用了，元数据和网关策略分开管这个思路我准备试一下。

蒋亦凡：容量评估那三段压测的顺序很实用，尤其是慢后端那一项，我们之前只压了正常场景，上线第一天就被慢查询拖垮了。