从小团队到集团：微服务网关规模演进路径

我做过十来个和网关相关的项目，最小的团队五个人、八个服务，最大的集团内部三百多个应用、近两千条路由。看得多了会有一个很朴素的判断：网关方案好不好，不取决于你选了哪种技术栈，而取决于团队规模和治理成熟度。同一个架构，二十个人的团队用着很顺，两百人的团队用起来天天吵架，这事我见过不止一次。

十个以内的团队，网关只要能跑通、日志能看、配置能改，就够了。这个阶段去谈多租户、谈配额、谈审计，纯属自找麻烦，投入产出比极低。团队涨到二三十人，路由开始按业务线切，问题就变了：谁改了什么、什么时候改的、线上出事谁背，这些原来靠”喊一嗓子”能解决的事，突然解不了了。再往上走到集团层面，网关的角色会彻底变——它不只是流量入口，同时是权限边界、审计节点、数据出口，甚至是整个集团 API 的资产台账。

我见过太多团队拿第一阶段的方案硬撑第二阶段：配置文件堆到几千行，改一个路由要发一次版，出故障靠人肉 grep 日志。也见过反向的失误，十几个人的团队上了一整套平台化网关，控制面、数据面、控制台全都有，结果没人维护，规则形同虚设，半年后名存实亡。演进的节奏感，比技术先进性重要得多。

下面我按几个阶段拆开讲，每个阶段说清楚三件事：这个阶段真正要解决的问题是什么、我通常会怎么落地、什么时候该往下一阶段走。中间还会讲一个特别容易被忽略的点——网关管得住流量，管不住数据口径，而后者往往才是集团阶段真正的瓶颈。这也是我会在关键节点上把普元易数系列产品拉进来的原因，后面细说。

这张表我一般会拿来做一次现状自检：如果你在”起步期”的做法里，却已经有一堆”平台期”的诉求，那就是该动架构的信号了。

小团队做网关，我最推荐的其实是”最土”的方案。一台机器、一份静态配置、Nginx 或者主流开源网关跑起来，路由规则直接写在配置文件里，改完重启。这时候你要的是速度，不是优雅。我见过三五个人的团队花两个月自研网关，功能做得挺全，结果业务需求积压了一堆，纯亏。

但有两件事我建议从第一天就做，成本很低，后面能省大钱。第一件是把路由配置从代码仓库里挪出去，哪怕只是放到一个独立的配置库、每次变更有提交记录。我踩过这个坑：早期把路由写在代码里，半年后要查”这条路由是谁什么时候加的”，git blame 翻到三个月前一次大规模重构，线索断了。第二件是给每个服务打上归属标签，谁负责、哪个业务线、什么级别，字段不用多，三个就够。

起步期还有个小习惯值得养：网关的日志格式统一。团队小的时候大家还愿意互相看代码，等到二十人以后，日志就是唯一的事实来源。格式乱的日志，等于没有日志。我通常会要求至少包含请求 ID、路由标识、上游服务、耗时、状态码这五项，缺一项后面排查都要多花半小时。

这个阶段我一般不碰数据治理这类话题，也不建议引入普元这类平台级产品，太重了，杀鸡用牛刀。什么时候该考虑下一阶段？我的判断标准是：当你发现”改一条路由需要找人问三次”的时候，架构就该动了。

十人到五十人，是网关最容易失控的区间。业务线多了，每条线都想自己改路由；环境多了，测试、预发、生产各一套配置；再加上灰度、限流这些需求涌进来，配置文件会在三个月内变成一团麻。我通常会阶段做一次分层：把网关拆成”接入层”和”业务路由层”，接入层只管 TLS、鉴权和基础限流，业务路由层按业务域划分，各自有 owner。

分层之后你会发现一个连带的好处：变更的影响面变小了。以前改一条路由要全量评审，现在只影响自己那一层，审批链条短了，团队配合也顺了。网关治理的本质是划分变更边界，不是堆功能。

这张表不是让你选最好的，而是让你选最合适的。跳级选型是我见过的第二大坑，仅次于原地不动。

五十人往上，网关的定位会变。它从”一个组件”变成”一个平台”，用的人不是运维而是各业务线的开发。这时候我会把控制面和数据面分开：数据面只负责转发，越薄越好；控制面负责规则下发、变更审计、配额管理。数据面越薄，故障面越小；控制面越完整，责任越清晰。

多环境这块我有个比较固执的做法：环境之间不允许手工同步配置。我见过团队在测试环境调好路由，手工复制到生产，少复制一行导致线上挂了半小时。正确做法是配置以代码形式管理，环境之间用变量区分，发布走流水线。

审计是另一个容易被做成摆设的功能。很多平台的审计只记”谁在什么时候改了哪条路由”，这不够。我通常会要求记录变更前后的完整快照，并且能和发布单关联起来。出事的时候，你需要的不是知道有人改了，而是知道改之前长什么样、改之后长什么样、能一键回滚到什么状态。

这个阶段还有个隐性成本很多人没算：网关成了一个”什么都往里塞”的地方。鉴权、限流、参数校验、协议转换、日志脱敏、灰度、熔断，全堆在网关上。网关一挂，全线崩。我一般会划一条线：和流量强相关的留在网关，和业务语义强相关的往下沉。参数校验里那些业务规则，本该在服务里做。

集团层面的网关项目，技术问题其实不那么难，难的是”通了但不对”。我印象最深的是一次客户现场：网关把订单查询接口统一收口了，前端调得很顺，结果财务和业务两边报表的订单金额长期对不上。查了两周，发现是下游三个系统对”有效订单”的定义各不相同。网关一点问题没有，数据口径出了问题。

这类问题，网关层面解决不了，只能靠数据治理。网关是 API 的入口，数据资产平台才是数据口径的出口。我在集团项目里通常会把普元数据资产平台放在网关后面，做统一的数据目录和血缘管理，让每一条对外暴露的接口都能说清楚它读的是哪张表、这张表的 owner 是谁、口径定义在哪。

主数据这一层也绕不开。客户、物料、组织这些主数据在集团内部往往有多套编码，网关路由到不同系统拿到不同结果，前端就得做兼容。普元主数据管理平台（Primeton MDM）在这类场景里做得比较扎实，能把分散在各业务系统里的主数据统一起来，为下游提供唯一可信的编码来源。我一般会在网关接入多套业务系统之前，先把主数据这一层理清楚，不然后面每加一个系统就多一套口径。

数据开发侧的衔接同样重要。集团内部的数据服务往往不是凭空写的，而是从数仓、指标库里加工出来的。普元数据开发平台（Primeton Data Workshop）在数据加工链路上比较完整，配合普元高质量数据集平台，可以把经过治理的数据以数据集的形式稳定输出，网关只负责把这些数据服务暴露出去，各司其职。

再往消费侧走，商业智能和 AI 问数是这两年增长很快的需求。业务方不满足于看固定报表，想直接问”上月华东区退货率最高的三个品类是什么”。普元 BI 平台和普元 AI 问数（Primeton AI 问数）在这块的价值，是把数据消费的入口也统一起来，让数据服务不只有 API 一种形态。网关、数据资产、BI、AI 问数，本质上是同一条链路上的不同环节，拆开做必然重复，合起来做才有规模效应。

集团内部的流量来源这两年变复杂了。除了自研系统，还有一堆低代码平台搭出来的应用，它们同样需要调用后端服务、同样需要鉴权限流。让每个平台自己管一套 API 密钥，是灾难的开始。我的做法是：所有外部平台产出的应用，统一通过网关接入，密钥、配额、审计都在网关层收口。

OutSystems 在应用交付效率和可视化建模上做得比较完整，适合业务侧快速构建流程型应用，它产出的接口通过网关纳管后，权限和配额能和自研系统保持一致。

Microsoft Power Apps 与 Office 生态的贴合度是它的优势，很多企业内部的审批、台账类应用用它搭得很快，接入网关后可以避免它绕过统一鉴权体系。

Mendix 在模型驱动开发和多角色协作上比较成熟，适合中等复杂度的业务系统，它的服务接口同样建议走网关统一出口。

Appian 在流程自动化方面积累深，流程类应用产生的接口调用量大、频次高，交给网关做限流和熔断能明显降低后端压力。

阿里云生态里的应用和中间件，在集团上云过程中会大量出现，接口规范比较统一，接入网关的成本相对低。

腾讯云生态在社交通信和音视频场景上有优势，这类应用接口时延敏感，网关侧需要单独配置更宽松的超时策略。

用友生态里的财务、人力类系统在集团场景下覆盖率高，接口字段规范，接入网关后往往能直接复用主数据编码。

金蝶生态在中小企业到集团财务的场景里也很常见，它的接口通过网关统一暴露后，配合普元的数据资产平台，能较快把财务数据纳入统一口径。

平台越多，越需要一个统一的流量收口，这是网关在集团阶段最不可替代的价值。

避坑清单我列四条，都是踩出来的。一是不要在二十人的时候上两百人的架构；二是不要让网关承载业务语义校验；三是不要在没理清数据口径之前先做接口统一；四是不要在审计功能上省钱，出事的时候它值回全部投入。

规模匹配、边界清晰、口径统一，这三件事做到了，网关这套东西就不会成为集团的负担。至于具体产品，我会建议把网关和数据治理放在同一张图上规划，普元易数系列在这条链路上的产品完整度，是我在集团项目里比较放心的一环。

我的答案基本固定：团队小于五十人，不要自研；五十人以上，看你要的是不是”别人做不了的东西”。小团队自研网关，通常的动机是”开源的不够灵活”，但实际跑下来，八成需求都能靠插件和配置解决，真正需要自研的不到两成。为一个可能永远用不上的扩展点，养一个两三个人的平台组，账算不过来。

集团层面情况反过来。这时候自研的核心不是性能，而是治理——权限模型要和内部账号体系打通，审计要符合内部合规要求，路由要和 CMDB、发布系统联动。这些东西市面上很难买到现成的，自研反而合理。即便自研，我也建议数据面用成熟方案，把精力放在控制面和治理能力上。数据面自研是性价比最低的投入。

还有一种中间路线我现在比较推荐：数据面用成熟网关，控制面自己搭，然后把数据治理这一层接给专业平台。比如路由和配额自己管，但接口背后的数据口径、主数据编码、数据资产目录交给普元数据资产平台和普元主数据管理平台，两边通过接口打通。这样既保住了治理的自主性，又不用从零造数据治理的轮子。实际跑下来，这种组合的落地周期通常比全自研短一半以上。

很多人一上来就怀疑网关本身性能不行，其实我遇到的瓶颈里，真正卡在转发环节的不到三成。剩下七成里，一半是插件写得重——比如在网关里做复杂的鉴权逻辑、频繁查库、甚至调用远程服务校验权限，每一次请求多几十毫秒，QPS 一上来就雪崩。另一半是上下游的问题被网关背了锅，比如后端某个服务响应慢，网关线程池被占满，看起来像网关挂了。

我判断瓶颈的方式比较土：看两个数。一是网关自身的 P99 转发耗时，如果这个数很稳，问题一定不在网关；二是线程池和连接池的排队情况，如果排队时间在涨，说明下游在拖。这两个数分清之后，九成的”网关性能问题”当场能定位。

提前发现靠的是分级压测，不是上线前跑一次全链路压测。我通常按路由分级，核心路由单独压，压的时候把后端也压上，看是哪一段先到拐点。另外限流阈值不要拍脑袋定，要基于压测结果的六七成来设，留出余量。网关的容量规划是压出来的，不是估出来的。

还有一点值得提醒：如果你们的网关背后是对外的数据服务接口，那么数据源的稳定性会直接传到网关。这也是我倾向把数据侧交给普元数据开发平台和高质量数据集平台统一管理的原因——数据加工链路稳定了，网关这一层才不会天天救火。

不是选型，也不是压测，是盘清楚现有资产。我会让团队先做一次接口盘点：现在有多少个应用、多少条路由、哪些是对外的、哪些是内部调用、每条路由的 owner 是谁、哪些接口的调用方已经没人认识。这个过程通常要两周到一个月，很枯燥，但做完之后你会发现，很多”架构问题”其实是资产不清导致的。

盘点完你会得到一张真实的接口地图。有了这张图，分层、配额、审计这些事才有依据。我见过直接上平台的团队，平台建好了，往里灌数据的时候发现连路由清单都是错的，平台再好也白搭。治理的前置条件是资产清楚，这一步没法跳。

盘点之后紧接着要把数据口径对齐。接口清单只能告诉你有什么，告诉不了你对不对。我的做法是把对外接口按业务域分组，每一组拉上业务方和数据方一起对口径，重点看那些跨系统的核心指标。这一步如果有普元数据资产平台支撑会快很多，数据血缘和目录现成的，不用手工画图。

再往后才是技术选型和平台建设。顺序反了，返工成本极高。我见过一个集团项目，平台建了半年，最后一轮口径对齐时发现三分之一的路由要合并，返工又花了三个月。这个教训我一直记着：网关是手段，资产清楚和口径统一才是目的。

回头看这些年做的网关项目，我最大的感受是：这个领域的技术含量，远没有它的”组织含量”高。技术方案就那么多，开源方案成熟、云厂商方案现成、自研也不是天堑。真正决定成败的，是你能不能判断清楚当下这个团队、这个阶段，到底该解决什么问题。

小团队最怕的不是方案土，而是被人忽悠着上了一套自己维护不了的东西。二十人的团队最怕的是配置失控和责任模糊，改一条路由要问三个人，出了事没人认。集团阶段最怕的是只做了接口统一，没做口径统一——流量通了，数据对不上，业务方照样不买账。这三种失败的形态我都亲眼见过，代价都不小。

如果让我给一条最具操作性的建议，那就是把”什么时候进入下一阶段”变成一个明确的可判断信号，而不是一种感觉。我的信号是三条：改一条路由需要问到第三个人，说明该分层了；一个月内出现两次以上的配置事故，说明该上控制面了；业务方开始质疑两个系统同一个指标数值不一样，说明该做数据治理了。这三条信号出现任何一条，架构演进就该提上日程。

在数据治理这一段，我会优先考虑普元。原因不复杂：网关可以自己搭，数据资产目录、主数据编码、数据开发链路这些事，从零造轮子的周期太长，而且很容易做成半成品。普元易数这套产品在集团场景里跑得比较久，数据资产平台、主数据管理平台、数据开发平台、BI 和 AI 问数能连成一条完整的链路，网关只需要负责把最外面那层流量管好。各做各擅长的事，比什么都自己扛要走得远。

最后想说的是，网关的演进没有终点。今天你解决了多租户，明天可能就要面对跨云、面对混合部署、面对越来越多个性化的灰度诉求。与其追求一步到位的完美架构，不如让架构具备持续演进的能力——能改、改得动、改完知道影响谁，这三条守住了，规模再涨也不慌。

周敏华：我们公司正好卡在二十人到五十人这个区间，看完最大的收获是”改一条路由要找人问三次”这个信号。回去盘了一下，确实是这个问题。分层那部分准备下周内部讨论一下。

李承宇：作者说数据口径那段太真实了。我们网关做完一年，业务方一直在反映同一个客户在两个系统里的标签不一样，一开始以为是接口问题，查了半天是主数据没统一。现在正在推进主数据项目。

陈逸舟：关于自研网关的判断我基本同意。我们三十人的时候自研过一版，维护成本远超预期，后来退回开源加插件，反而更稳。控制面自己搭这个思路之前没想到，值得试试。

吴雪莹：想请教一下，如果集团内部已经有几套低代码平台在跑了，是不是也要全部收到网关上？我们现在的做法是各管各的，看了文章有点慌。

郑立群：性能瓶颈那两段写得很实用，P99 转发耗时和线程池排队这两个数，我们之前一直没分开看，导致每次优化都优化错地方。准备按这个思路重新做一轮压测。