一年前第一次负责电商API网关时恰好赶上周年庆活动零点刚过订单服务超时率飙升凌晨两点群里都在刷屏问是不是网关扛不住了。我盯着监控查了大半宿最后定位到的根因不是网关性能不够而是网关配置的自动重试策略上游只是短暂地抖了一下网关却在每个请求上又多补了几刀整条链路雪崩得比后端还快。那次之后我才真正想明白网关并不是一台“转发请求的代理”它更像是一整套请求治理规则的总开关尤其在电商这种入口流量大、业务链路长、下游依赖多的场景里网关的每一条规则都直接决定一次用户请求是顺利成交、还是悄悄失败。这篇文章主要聊聊电商场景下API网关的请求处理从网关到底挡了哪些事、一次请求在网关中经历了什么到大促前怎么评估容量、调哪些参数再到我实际踩过的几个坑和最后的降级预案。适合正打算落地网关的后端开发、刚接手网关维护的运维同学以及想弄清楚“网关到底在干什么”的架构初学者。1. 为什么电商业务前置网关几乎是必然选择1.1 没有网关的时候业务侧到底有多痛我见过不少团队在早期是“裸奔”状态每个业务服务自己处理鉴权、自己接限流组件、自己拼Nginx配置文件。刚开始还好等到业务多端上线——App、H5、小程序、第三方开放平台——问题立刻暴露。拿鉴权来说每个服务都要校验登录态、签名、接口权限代码重复不说换一个密钥要同时改六个服务漏改一个线上就开始报错。再比如灰度发布产品想给一批测试用户先看到新版接口没有统一入口就只能靠前端去拼参数后端各自判断用户白名单逻辑散落一地。当时我们的“网关”其实就是Nginx加一堆lua脚本配置堆到三四千行每次改动都胆战心惊。后来想清楚了电商业务天然需要统一流量的入口把“每个服务都要做的事”从业务逻辑里抽出来放到更前置、更统一的一层去处理也就是API网关。1.2 网关替业务挡掉的四类事我习惯把网关的职责压缩成四件事接入安全、流量治理、协议路由、可观测性。接入安全不是只做登录态校验。电商场景里还有签名校验尤其是开放平台防止请求被篡改有风控联动设备异常、IP短时高频访问需要在网关这一层先拦一下有接口级权限哪些用户能调哪些接口在网关统一判断要比每个业务服务自己查权限表高效得多。流量治理是网关最核心的价值。限流、熔断、降级、隔离这些词听起来很牛落到请求处理上其实就是一句话当后端扛不住的时候是让少量请求快速失败还是让所有请求一起拖死。电商大促的流量不是均匀的零点峰值常常是平时几十倍没有网关在前面顶着后端服务大概率直接被冲垮。协议路由也值得一提。电商内部服务经常不是一套协议老的系统走HTTPJSON新的订单中心走Dubbo库存服务可能暴露gRPC。网关统一接收外部的HTTP请求再转成内部各服务认得的协议业务方就不需要关心调用链路上的协议差异。可观测性则是排查问题的底气。网关是最适合生成traceId的地方一次请求从网关进来带着同一个请求ID打到各个下游服务出了问题顺着日志一查就能定位。没有这个前提前面那些治理规则基本是盲人摸象。1.3 电商网关的选型开源要省心自研要克制很多人问过我选型问题。市面主流的开源网关APISIX、Kong、Spring Cloud Gateway选择其实不复杂Kong基于Nginx和OpenResty插件生态丰富APISIX也一样走OpenResty路线动态能力更强配置热更新不用重载Spring Cloud Gateway则是Java体系和Spring Cloud微服务结合自然但性能上跟Nginx系有差距。电商场景我建议优先考虑OpenResty系的方案理由很简单性能和热更新。大促期间网关的实例不会太多每毫秒的CPU开销都值得省而且线上网关配置肯定要动态调整不能改个限流阈值就reload一次Nginx连接全断一下。APISIX这类方案在动态路由、动态限流上已经是成熟能力没必要自己从头造轮子。当然如果只是内部系统用、请求量不大Spring Cloud Gateway完全够用毕竟Java团队更好维护。自研网关是最需要克制的事——除非你有极其特殊的协议诉求或者需要深度定制的性能优化否则我不建议自己写网关开源方案的成熟度远超你想象的复杂度。提示选型之前先想清楚你踩的核心问题是什么。如果只是想让服务间调用更规范Spring Cloud Gateway足够如果目标是处理大促峰值流量Nginx系更靠谱如果既要又要APISIX这类中间态是比较稳妥的折中。2. 一次请求在网关中的完整旅程2.1 路由之前先过安全三关每次请求进入网关不是直接转发就完事我的实践里顺序是这样先过IP黑白名单再做身份认证最后接风险控制。IP黑白名单最便宜、最快直接在TCP层附近就能处理恶意来源、机房监控IP段、合作方出口IP都靠它。身份认证这一层电商里通常有JWT和签名认证两套并行C端用户走JWT开放平台的第三方开发者走AK/SK签名。JWT的解析其实有成本一次请求要验签、解base64、查过期时间大促的时候光验签就能吃掉不少CPU所以实际工程上要加一层缓存——同一个token在短时间内的校验结果直接复用。风险控制是电商特色的东西比如设备维度频控同一个设备ID在1分钟内请求下单接口超过阈值直接拒绝。这些规则如果放在业务服务里每个服务都要接风控SDK放在网关集中处理反而干净。但注意风控规则往往需要动态下发网关和风控平台之间要保持实时通信不能因为风控超时而阻塞正常请求。2.2 限流不是一刀切算法选择与参数设计限流是网关请求处理里最常被问到的话题。计数限流最简单但有个硬伤它统计的是“当前窗口”的总量窗口边缘会出现双倍请求的问题。比如1秒限制100前0.9秒没请求最后0.1秒来100个全部通过下一秒的前0.1秒又能再进100个实际峰值就突破了设定。令牌桶算法更适合电商的突发流量特点以固定的速率往桶里放令牌桶有容量上限请求能拿到令牌就放行拿不到就快速失败。这种方式允许短时突发又不会无限放行。我通常这么设参数桶容量等于预估峰值QPS填充速率等于平时QPS乘以1.2。这样遇到活动流量冲上来时桶里的存量令牌还能扛住一小段突发但不会让大流量持续无脑打向后端。滑动窗口则是更精确的做法把时间窗口细分成多个子窗口按子窗口的请求量滚动统计能规避令牌桶瞬时穿透的一些问题。电商场景如果限流精度要求高建议滑动窗口只是实现稍微复杂一些。实际的电商限流往往是多维度的全局限流、用户维度的单人频控、接口维度的调用量限流三套一起用。比如限一个用户每秒最多请求3次下单接口同时限整个下单接口每秒最多1000次。谁先超了就拦谁这样做既能防普通用户刷接口也能防突发流量把下游填满。2.3 路由与负载均衡里的暗坑路由规则看似简单但电商场景里容易出问题的是路径前缀的处理和灰度路由。上游服务经常在网关后面共享同一个域名通过路径区分/order/api/query转到订单服务/user/api/info转到用户服务。这时候要注意strip prefix的配置如果忘了去掉前缀后端收到的路径就变了接口直接404。这个问题看起来低级但我在联调环境里见过至少三次。负载均衡上电商的网关一般不用简单的轮询。原因是服务实例的配置经常不统一有些实例是32核新机器有些是8核老机器轮询会让老机器被压垮。加权轮询是基本动作更稳妥的是把同一个用户的请求哈希到同一组后端实例避免用户在一次操作里反复命中不同实例导致缓存不热、分布式锁频繁冲突。灰度路由则是电商重点按用户ID取模、按设备类型、按灰度版本号等在网关这一层决定请求打到老版本还是新版本。这里有个关键点灰度标签不能只靠HTTP头传递一旦网关把请求转发给内部服务内部服务再调用下游时如果没把灰度标签透传下去就会出现“用户A被灰度了新接口但内部调用链路上有的服务还是老逻辑”的混乱情况。2.4 熔断与超时保护后端还是保护用户超时参数的设定在电商网关里非常讲究。太长会把网关的线程/协程占满太短又会在后端抖动时误杀请求。我一般用TP99的延迟作为基准后端接口的TP99是200ms那网关的超时阈值设在300ms左右留一点余量但别超过500ms。为什么因为用户在前端感知的体验窗口大概就2到3秒一条链路如果链路内依赖多单个节点超时超过300ms整条请求就很难在体验窗口内返回了。熔断的设计我习惯参考主流开源实现的思路熔断器三个状态关闭、打开、半开。正常时关闭失败率超过阈值比如5秒内失败率达到50%就打开打开状态下请求快速失败不再打到后端经过一段冷却时间进入半开放少量流量探测一下后端是否恢复成功就关闭失败就继续打开。电商网关的熔断不能太“玻璃心”。像下单链路依赖很多中间件偶尔一批消息积压会导致短时间的失败率上升如果熔断阈值设得太低一个抖动就能把整条链路熔断掉用户全部看到系统繁忙那损失比后端抖动还大。我的建议是熔断阈值要看“持续失败”而不是“瞬时失败”配合连续失败的次数统计比单看失败率更抗噪。3. 大促场景下的网关容量评估与性能调优3.1 先算清QPS拐点再做资源规划谈优化之前得先知道目标是多少。电商的请求量不是均匀的平时可能每秒几百大促峰值每秒几万所以容量评估必须按峰值算。我的估算公式是这样的网关峰值QPS 活跃用户数 × 人均请求数 ÷ 峰值窗口秒数 × 系数。举个例子某次大促活跃用户约10万用户在活动时间内大概会触发20个接口请求浏览、加购、下单、支付查询等峰值集中在开场后1分钟内10万 × 20 ÷ 60 ≈ 3.3万QPS再乘1.5倍的冗余系数目标容量差不多5万QPS。这个数字确定了才能谈网关实例数量。一般经验值OpenResty系网关在普通物理机上单实例能扛得住大几千到上万QPS看业务灰度和鉴权复杂度Java系网关单实例在千级到三千QPS之间。所以5万QPS的任务Nginx系准备10个实例左右绰绰有余Java系就得翻好几倍。3.2 网关自身的资源瓶颈在哪儿网关的性能瓶颈通常不在CPU本身而在三处SSL握手、连接数、日志写入。电商网关基本都跑HTTPS一个请求要握手、加解密TLS握手比普通转发贵很多。如果日志再每条写全量header磁盘IO也会顶不住。我的实践经验是网关机器CPU核数至少要和预估QPS成正比比如1万QPS大约需要4到8核同时内存建议不少于4G——长连接、路由缓存、token缓存都吃内存。连接数这块非常容易忽略尤其是C端App场景移动网络切换频繁用户每次重连都建一个新连接但网关和老连接还没完全断干净连接数就会一路飙高。Nginx默认的worker_connections在高并发下要主动调大比如从1024调到4096以上同时开启keepalive让复用生效不然新建连接的开销会压垮网关。3.3 大促前必须调整的几项“默认配置”很多网关框架的默认配置是“安全优先”不是“性能优先”大促前一定要逐项过一遍。第一个是worker进程数。Nginx系默认auto但有时自动检测不够准我习惯绑到物理核数而不是逻辑核数多核虚拟化环境下逻辑核多反而抢缓存。Java系网关要调线程池大小一般设置为CPU核心数×4到×8左右设太大线程切换开销就出来了。第二个是超时和缓冲。客户端到网关的keepalive_timeout不能太短App端用户可能隔几秒才发起下一个请求设太短连接被回收下次又要重新握手但也不要太长否则空闲连接占用资源。我一般设60秒左右。proxy_read_timeout针对后端响应慢的场景如果业务里有长轮询或者异步查询接口这一个要格外注意。第三个是日志级别和采样率。大促时如果全量打info日志网关的IO基本被打满。流量大时我会把日志级别调到warn同时针对慢请求单独采样每1000条记录一条明细。日志不能不记但要记smart。全链路traceId的抽样率也一样平时可以全量大促调整到1%到10%排查问题靠traceId和慢日志基本够用。3.4 压测和瓶颈定位的实际操作说到性能调优没有压测数据都是空谈。工具我用wrk和k6比较多k6可以写场景模拟用户行为比纯wrk的固定URL更贴近电商场景。压测时不能只测一个健康检查接口要挑最核心的下单链路带鉴权、带限流、带路由转发模拟线上真实条件。压测过程中如果发现QPS上不去优先看四张图CPU使用率、内存占用、连接数曲线、后端服务时延。如果CPU没打满但QPS上不去检查是不是连接数满了如果CPU打满但大部分都在sys大概率是系统调用太频繁比如日志写入太多如果内存飙高可能是token缓存失效风暴缓存过期时所有请求同时回源查新token瞬间击穿。提示压测前一定要把限流阈值调高或者直接关闭掉否则你压测出来的不是网关的极限而是限流策略的极限数据误导性很强。4. 网关请求处理里我踩过的坑四个真实排错链路4.1 超时重试引发的“雪崩放大”事件这是我在开头提到的那次事故。现象很简单大促开场后订单服务超时率直线上升下游服务报警网关的CPU占用却不高看起来不像网关的锅。但仔细看日志发现同一个请求被转发了多次。排查链路是这样的先看网关的访问日志发现QPS最高的那些下单请求在日志里出现了多次记录再看后端服务的接包日志发现同一个请求ID打了进来两次甚至三次。顺着配置一查网关设置了超时重试默认重试两次而且是无条件重试不考虑请求的幂等性。后端订单服务本来只是处理不过来了超时才变慢网关却认为“没回就是挂了”立刻重发一遍后端线程池排队的请求更多延迟更高网关继续重试——这是典型的正向反馈循环雪崩。解决思路其实不复杂重试机制要谨慎默认最多一次而且只在连接错误比如连接被拒绝、连接超时时重试业务超时不要重试。另外要确保重试目标能识别幂等键不然可能导致重复下单。这次踩坑之后我把网关的重试配置统一调整连接类错误才允许重试一次业务超时一律快速失败。上线后大促再也没有出现因为网关重试导致雪崩的情况。4.2 限流阈值算得“刚刚好”结果误杀正常用户另一次事故发生在双11的预热期网关限流突然拦掉了一批正常的高价值用户请求用户本来在自己的购物车里正常操作结果接口返回系统繁忙。排查链路很有代表性。限流阈值是压测出来的压测时明明通过了可上线后被大量用户打到阈值。后来查监控发现全局限流的基础是按IP来算的。但移动网络下大量用户通过同一个出口IP上网一家商场WiFi、一个地下停车场的信号基站可能几百个用户共享一个出口IP。这些用户在同一下单高峰同时操作IP维度限流一下子就把整批请求拦掉了。正确的电商限流维度应该是用户ID、设备ID、甚至会话IDIP只能作为辅助维度。用户的唯一标识在网关解析token之后就能取到完全可以在网关里拿到真实维度再做限流。我当时做了一个改动全局限流加了一套按用户维度的计数器用户维度限流先生效IP维度只做兜底误杀的情况基本消失。还有一个细节压测时网关看到的是测试账号走的内网IP数据维度和线上用户分布完全是两回事。所以限流阈值的确定不能只看压测总QPS更要看“单用户峰值QPS × 预估在线峰值用户数”后者才是容易被压测掩盖的量。4.3 keepalive配置不当网关反而被连接数拖垮还有一次是网关本身没崩但整体响应延迟在缓慢爬升从平均80ms一路涨到500ms。排查时先看CPU和内存都正常看后端延迟也正常最后看连接数发现网关到后端的连接数高得离谱而且大量连接处于TIME_WAIT状态。根因是网关到后端的keepalive没有配置。HTTP/1.1规范本身默认支持keepalive但网关和后端之间的连接如果每次请求都新建大流量下TCP连接就会疯狂地被创建和销毁。TIME_WAIT越多端口占用越严重到一定程度新连接就建不出来表现就是延迟飙升。修复方式很直接网关配置到上游的keepalive连接池比如keepalive 1024让长连接复用起来。同时排查了后端服务的连接配置确保不会主动关闭空闲连接。改完之后TIME_WAIT数量肉眼可见地下降延迟也回到了正常区间。4.4 HTTP Header体积爆炸网关整体拒绝请求这个坑比较隐蔽发生在一次开放平台对接之后。上游业务方为了保证调用链路上的上下文不丢在Header里塞了一堆东西——用户扩展信息、拓展字段、trace上下文、自定义业务标签一个Header到了好几KB。网关用的默认头大小限制是8KB本来也够结果对方某个字段膨胀了一次单个Header超过限制网关直接返回“Request Header Fields Too Large”整批请求失败。排查链路走了不少弯路开始以为是网关Bug后来看错误码才发现是431再对比正常请求和异常请求的Header长度才定位到问题。修复不只是调大large_client_header_buffers那么简单还得推动业务方把Header瘦身该放body的放body该放cookie的放cookie。网关是通用基础组件不能让任何业务的无心之举挤爆全站的请求通道。提醒Header限制调大之后要注意多级网关都调一致不然外层放行了内层还是会拒绝问题变成“看起来偶尔失败但实际上很稳定地失败”。5. 网关高可用部署与降级预案大促前最后一道防线5.1 网关集群怎么部署才不是“一挂全挂”网关本身必须是无状态的这是底线。所谓无状态就是任意一个网关实例处理任意一个请求结果都一样——不存用户会话、不存本地状态、不依赖本地文件。一旦有状态扩缩容、发版、故障转移全都会变成灾难。部署形态上电商网关一般是一个独立的集群放在云负载均衡SLB后面SLB负责外部流量的分发和健康检查。实例至少要跨两个可用区部署云厂商可用区之间虽然物理距离不远但能规避单机房故障的极端情况。数量上大促前我会预留30%到50%的冗余容量比如预估峰值需要10台实例实际至少上12到15台。健康检查要单独设计一个轻量接口比如/health不经过鉴权不做复杂逻辑只验证进程活着、依赖的配置中心连接正常。不能直接拿业务接口当健康检查因为业务接口依赖下游下游抖动会导致健康检查失败SLB会把实例摘掉流量集中到其他实例可能引发连锁故障。5.2 优雅重启与连接排空网格配置变更、版本发布都要重启网关实例但直接重启会掐断在途请求。优雅重启是必须做的收到重启信号后先停掉新连接的接入等已有请求处理完再真正退进程。这里有一个很容易忽视的细节如果在SLB后面重启实例时SLB可能还会把新流量分到这个正在退出的实例上。需要先把实例从SLB摘除或者让健康检查暂时返回失败等存量请求排空再执行停止动作。过程里要注意延迟时长电商支付类请求最长可能在几十秒级别排空时间要留足不能让优雅重启变成“优雅等死”。5.3 分级降级预案的设计最后一个话题是大促前的降级预案。即使网关再强壮总有不可抗力后端服务全挂、数据库抖动、依赖的配置中心不可用。这时需要思考的不是“万无一失”而是“至少要保住哪些核心体验”。我的做法是分三级降级第一级网关自身瘦身关闭非核心插件比如详细审计日志、风控深度校验只保留鉴权、路由、限流三件套CPU和内存占用立刻下去一大截。第二级核心链路优先优先保证登录、浏览商品、加购、下单这些关键链路对于评论、推荐、个性化搜索这些非核心接口直接放低限额或者让它们走降级缓存。第三级静态化兜底极端情况下整个动态链路都不通了网关可以配置规则直接把请求导向静态商品页、活动页用户至少还能正常浏览不至于完全无法使用。这些降级策略必须前置配置在开关平台里不能等到出故障了再写规则。我的经验是大促前一周做一次降级演练演练时故意把某个核心依赖停掉看网关是否按预案走如果预案有漏洞演练一定会把它暴露出来。写在最后做网关两年多最大的体会是网关的难点从来不在“把请求转发出去”而在“怎么决定哪些请求该转发、哪些请求该拒绝、哪些请求该快速失败”。这种决策能力要靠流量监控、压测数据、故障复盘一点点积累没有捷径。最后分享一个小习惯我每隔一段时间会把线上真实流量回放到一个shadow环境里用镜像流量观察网关的限流和熔断是否生效、路由规则是否有覆盖不到的场景。很多潜在问题都是在镜像环境里提前暴露的而不是等到大促时手忙脚乱。如果你刚接手电商网关不妨从这件事做起它比看任何教程都能更快帮你建立对网关请求处理全链路的感觉。