Go微服务不负责全局流量管控，限流、熔断、配额等必须下沉至APISIX网关层；Go服务仅专注业务逻辑，所有入口流量由APISIX统一拦截、计数、决策并转发。
直接说结论：Go微服务本身不负责全局流量管控，必须把限流、熔断、配额等逻辑下沉到 APISIX 网关层；Go 服务只专注业务逻辑，所有入口流量由 APISIX 统一拦截、计数、决策并转发。
为什么不能在Go代码里做全局限流
Go 微服务单实例的内存计数（比如用 golang.org/x/time/rate）只对本进程有效，集群部署时各实例独立计数，无法保证“每秒最多1000次调用”这类全局约束。一旦上游有10个APISIX节点+20个Go实例，rate.Limiter 就完全失效，还会掩盖真实过载点。
常见错误现象：
- 压测时QPS翻倍但没触发限流 —— 因为每个Go实例都在自己桶里算
- Redis计数器被重复写入或漏更新 —— 多个Go进程并发操作同一key未加锁
- 熔断状态不同步 —— A实例判定下游超时熔断，B实例还在重试
APISIX插件选型：limit-req vs limit-count vs api-breaker
三者不是互斥，而是按阶段协同工作：
-
limit-req放在最前：防突发，用令牌桶控制请求速率（如rate: 500,burst: 200），适合保护Go服务的CPU和goroutine调度压力 -
limit-count放中间：管配额，按时间窗口统计总次数（如count: 10000,time_window: 3600），适合SaaS场景按租户计费 -
api-breaker放最后：保可用，当Go服务HTTP响应码连续出现503或延迟 >3000ms超过阈值时自动熔断，避免雪崩
关键参数差异：
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
-
limit-req必须设policy: redis才能跨APISIX节点共享桶，否则默认local仅本机生效 -
limit-count的key可拼接多个变量，例如"$consumer_name $uri"实现“每个用户每接口每小时独立配额” -
api-breaker的failures和timeout需根据Go服务实际P99延迟设定，不能照搬示例值
Go服务如何配合APISIX识别身份与传递上下文
APISIX 限流依赖可靠的标识，而Go服务不能只靠 remote_addr（可能全是NAT后IP）。需主动透传可信字段：
- 前端调用时带
X-Consumer-ID或AuthorizationJWT，APISIX用key-auth插件鉴权后注入consumer_name变量 - Go服务在返回头中添加
X-Service-Version: v1.2.3，APISIX路由可据此做灰度，限流策略也能绑定版本维度 - 若需按业务ID限流（如订单ID），Go服务应在请求体或查询参数中显式携带
order_id，APISIX配置key: "$arg_order_id"
容易踩的坑：
- JWT payload里没放
consumer_name字段，导致limit-count的key: consumer_name取不到值，全部归到空字符串桶里 - Go服务用了gzip压缩但没设
Content-Encoding: gzip响应头，APISIX的api-breaker误判为超时（因body_filter阶段解压耗时被计入延迟）
调试与验证：确认限流是否真生效
不要只看日志，要验证行为：
- 用
curl -I http://apisix/your-api观察响应头：X-RateLimit-Limit、X-RateLimit-Remaining出现在limit-req启用时，说明计数器已接入 - 手动往Redis查键：
redis-cli keys "limit-count:*"，确认键名符合APISIX生成规则（如limit-count:consumer_name:myapp:60） - 故意触发熔断：停掉一个Go实例，连续发5次超时请求，再发第6次，应立刻返回
503 Service Unavailable而非等待
最常被忽略的点：APISIX的 limit-req 默认拒绝策略是返回 429，但很多Go客户端没处理该状态码，反而重试加剧拥塞；必须在APISIX配置里明确设 rejected_code: 429 并确保前端SDK识别它。
