接口网关限流：保护后端的四层防护配置

去年帮朋友的贸易公司做系统加固，起因是一次事故：一个合作方的对接程序出了故障，每秒几百次重复请求打过来，后端被打到接近瘫痪。事后复盘，最大的教训不是对方代码烂，而是我们的接口毫无防护。把自己的安全寄托在别人的代码质量上，等于把家门钥匙挂在门框上。这次加固，我在网关层配了一套四层限流体系。做全栈这些年，限流是我认为性价比最高的防护动作：配置成本以天计，防的事故以夜计。这篇把设计思路和配置细节摊开讲。配置用的是通用网关的写法，各家云厂商的语法略有差异，但四层的思路通用，照着搬只需对号入座。

一、为什么要分层限流

1.1 单层限流的困境

先试过最简单的做法：全局每秒一千次的总量限制。配上之后发现问题没解决——合作方故障程序的流量占了八百次配额，正常用户的请求反而被拒之门外。坏人没拦住，好人先遭殃。这次失败尝试反而帮我想明白了限流的本质：限流限的不是流量总量，是流量里的不公平。分层，就是给公平定规则。

这就是单层限流的困境：一把尺子量所有人，量不出差别。不同的调用方、不同的接口、不同的时段，承载能力完全不同，限流也必须分层分对象。

1.2 四层的设计思路

重新设计后，限流分四层兜底，从外到内依次收紧：

头一层按调用方限：每个接入方独立配额，A 出故障不能殃及 B。第二层按接口限：核心接口高配额，边缘接口低配额，好钢用在刀刃上。第三层按用户限：单个用户的操作频率封顶，防止一个账号刷爆系统，也顺带挡住撞库撞接口这类歪心思。第四层是全局兜底：所有流量加起来不能超过后端总承载，保护伞最后一级。这一层的配额和后端真实承载挂钩，是四层里唯一要用压测数据说话的，其他三层可以拍脑袋，这层不行。

四层是漏斗关系，流量依次穿过，任何一层拦住的请求都到不了后端。分层还有个好处：排查方便。看监控就知道请求死在哪一层——死在调用方层是对方的事，死在接口层是配额的事，死在全局层是容量的事。分层限流，顺带分了锅，出了问题不吵架。

二、配置实现

2.0 动手前的容量摸底

写配置前先做了一次容量摸底：压测出后端单机承载是每秒八百次，两台机器理论一千六，留三成余量，全局兜底线定在两千显然超了，改定一千一。所有参数都从这次压测推导。跳过摸底直接抄参数，是限流配置最常见的病根——数字本身就是错的，调优调的却是错的方向。

2.1 网关配置总览

网关配置直接上核心段：

# 头一层：按调用方限流
limit_req_zone $binary_remote_addr zone=per-client:20m rate=100r/s;

# 第三层：按用户限流（从请求头取用户标识）
limit_req_zone $http_x_user_id zone=per-user:10m rate=20r/s;

# 第四层：全局兜底
limit_req_zone $server_name zone=global:20m rate=2000r/s;

server {
  location /api/ {
    # 第二层：按接口分级
    location /api/order/ {
      limit_req zone=per-client burst=200 nodelay;
      limit_req_status 429;
      proxy_pass backend://order-cluster;
    }
    location /api/report/ {
      limit_req zone=per-client burst=20 nodelay;
      limit_req_status 429;
      proxy_pass backend://report-cluster;
    }
    limit_req zone=global burst=500 nodelay;
    limit_req_status 429;
  }
}

这段配置里，三个限流区域各自独立计数，接口分级在路由层实现，报表这类重接口的突发额度只有订单接口的十分之一。

2.2 突发额度的艺术

rate 定长期速率，burst 定突发容量，这对参数是限流的灵魂，调好了系统有弹性，调不好用户遭罪。订单接口给了一百的速率加二百的突发：正常流量平滑时按速率走，促销瞬时高峰靠突发额度缓冲。

突发额度不是越大越好。给多了等于没限，给少了误伤正常用户。我们的校准方法：拉一个月的监控数据，找正常流量的峰值曲线，突发额度设在峰值的1.5倍。有据可依，比拍脑袋踏实。还有一个细节：突发额度要跟调用方的批量行为对齐。有的合作方整点集中对账，瞬时脉冲是刚性的，额度不给够，人家的正常业务会被误伤。参数是死的，对面是活人，校准时要看见人。

2.3 被限流的请求怎么办

请求被拒不能一拒了之。返回码统一用四二九，响应体里带上三个信息：当前限额、重试等待秒数、限流层级标识。调用方拿到这些信息，能实现礼貌的重试退避，而不是蒙头猛撞。

给合作方的对接文档里，专门写了一节限流行为说明，附上推荐的重试策略代码。把规则说在明处，比让对方猜要体面得多，也减少了大半的对接扯皮。上线后真有合作方工程师专门发消息说，这是他们见过写得最清楚的限流文档。敌意往往是模糊造成的，把规则摊开，对方就从对手变成了队友。

2.4 监控与告警

限流配置不是设完就完。网关日志里限流触发次数接入监控：按调用方的触发数单独看板，某一方频繁触线，要么是对方异常，要么是配额该调了，两种情况都值得跟进。

告警规则定了两条：单调用方五分钟内触发超过一千次，告警；全局限流连续触发十分钟，告警。前者抓坏人，后者防自己——后端真出性能问题时，限流触发是头一个信号。第二条告警上线头一个月就响过一次：后端一条慢查询拖垮了响应，请求堆积触线。顺着告警找到病根，比用户投诉倒逼排查体面太多。告警不只是保安，还是啄木鸟。

三、实战检验

3.1 再次面对故障流量

配置上线两个月后，同类事故重演：另一家合作方的程序又失控了。这次的差别是：故障方的请求在头一层就被拦住，配额外的请求全部收到四二九，正常业务流量零感知。后端负载平稳，我是在告警短信里才知道又有人失控了。

从事故响应变成看一条告警，这就是防护体系的价值。朋友知道后感慨：上次事故全员加班一晚上，这次连茶都没凉。技术防护做到位，最大的变化是人的心态——从时刻准备救火，到相信防火墙真的在防火。

3.2 促销大考

年底促销是第二次检验。订单接口流量冲到日常六倍，突发额度接住了头三分钟的洪峰，之后调用方按重试策略匀速回放，全天零故障。限流不只防坏人，也帮系统扛住了好人的热情。事后复盘数据很有意思：促销六倍流量里，被突发额度缓冲掉的占三成，被调用方礼貌重试摊平的占五成，真正压到后端的峰值只有日常两倍。限流体系像一套太极拳，把猛劲全卸掉了。

3.3 意外收获：流量画像

跑了一个季度后，限流监控数据沉淀出一份流量画像：哪家调用方流量增长最快、哪个接口是真正的热点、高峰时段怎么分布。这些画像反过来指导了配额调整和容量规划。限流体系顺手当了流量分析的数据源，意外之喜。基于画像还做了一次配额回收：三家低用量调用方的富余配额砍半，腾给高增长的一方，资源跟着业务走，配额也要流动起来。

四、几点心得

4.0 分层别贪多

四层是这个项目的合适量，不是普适答案。见过有人一上来配七八层，层层叠加后没人说得清一个请求会被哪层拦住，排查成了玄学。层数以够用为度：每层都要能回答为什么需要它，答不上来就删。防护体系的首要美德是可理解，其次才是严密。

4.1 限流是保险，不是能力

要分清楚：限流保护的是后端不被打死，不能提升后端的承载能力。该扩容扩容、该优化优化，限流只是给这些动作争取时间。把限流当能力用，等于把保险当收入。配好限流后的正确动作清单：盯监控看拦截率，拦截率高说明容量或配额要动，而不是庆祝防护生效。保险的作用是出事时兜底，不是让人开车不看路。

4.2 拒绝也要有礼貌

被限流的请求是客户，不是敌人。清晰的错误码、明确的等待时间、文档化的重试建议，这些礼貌能把限流的伤害降到最低。再补一个实践细节：限流响应走独立格式，和业务错误区分开，让调用方的代码能明确识别这是限流而非业务失败。混淆这两者的系统，重试逻辑一定是一团糟。系统间的体面，都在这些细节里。

4.3 配置要定期回看

业务在长，配额是死的。我们把配额回 Review 定成了季度动作：拉流量趋势，调配额参数，删过时规则。限流配置和花园一样，不修剪就荒。季度回看坚持了一年，砍掉过时规则七条、调整配额十二次，配置文件始终保持一个新人十分钟能读懂的状态。防护体系的可维护性，最终决定它的寿命。