Nginx与Java分层协作实现限流降级：Nginx负责入口侧速率/连接数限制及静态降级、健康检查，Java层聚焦业务语义限流、方法级降级与熔断，二者结合形成网关级（面）到服务级（点）的立体防护。
Nginx 本身不运行 Java，但它作为反向代理和网关层，与后端 Java 应用协同工作时，能分担限流、健康检查、故障转移等关键职责。真正的限流降级逻辑需由 Java 层（如 Spring Cloud Gateway、Sentinel 或 Hystrix）实现，Nginx 则在入口侧做轻量级兜底与分流。二者配合不是替代关系，而是分层防御：Nginx 拦第一波洪峰，Java 层控业务级流量与状态。
限流策略的分工协作
Nginx 可承担基础速率与连接数限制，适合应对突发流量或恶意请求：
- limit_req：按 IP 或 key（如 token）限制每秒请求数，配合 burst 和 nodelay 实现平滑削峰
- limit_conn：限制单个 IP 或 upstream 连接总数，防止连接耗尽（如 Tomcat 的 acceptCount 被打满）
- 这些规则写在 server 或 location 块中，生效快、无 JVM 开销，但无法感知业务语义（比如“下单接口”还是“查询接口”）
- Java 层限流（如 Sentinel 的 QPS 控制、Redis+Lua 分布式令牌桶）则聚焦业务维度：按接口路径、用户等级、资源标签动态限流，并支持实时规则推送与熔断联动
降级与容错的双层落地
降级不能只靠 Java 应用自己返回兜底数据，Nginx 可提供前置降级能力：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 当 Java 服务全部不可用时，Nginx 可直接返回静态降级页（error_page 502 503 504 /down.html），避免用户看到空白或超时错误
- 结合 upstream 的 max_fails=3 fail_timeout=30s，自动摘除连续失败的 Java 节点；再配 backup 服务器，故障时快速切至备用集群
- Java 层使用 @SentinelResource 或 @HystrixCommand 定义方法级降级逻辑（如查不到用户时返回缓存默认值），保障单点故障不扩散
- 两者配合形成“网关级降级（面）→ 服务级降级（点）”的立体防护
健康检查与自动剔除
Nginx 主动探测 Java 服务存活状态，是链路高可用的前提：
立即学习“Java免费学习笔记（深入）”；
- 开源版 Nginx 需借助 nginx_upstream_check_module，定期 GET /actuator/health，根据 HTTP 状态码判断节点是否在线
- Java 应用需暴露标准健康端点（Spring Boot Actuator 默认 /actuator/health），并集成自定义检查（如数据库连接、Redis 连通性）
- 探测失败后，Nginx 自动将该节点从负载池移出；恢复后自动加回，无需人工干预
- 此机制与 Java 层的熔断器（如 Sentinel 的 HALF_OPEN 状态）互补：前者管“连得上否”，后者管“调得通否”
日志与监控闭环
限流降级效果必须可观测，否则等于没配：
- Nginx 记录 $status、$request_time、$upstream_status，可识别 429（限流）、503（服务不可用）等关键码，接入 ELK 或 Prometheus + Grafana
- Java 应用通过 Micrometer 上报 Sentinel 指标（blockQps、exceptionQps）、Hystrix 熔断状态，与 Nginx 日志关联分析，定位是网关拦截还是服务内部拒绝
- 当 Nginx 出现大量 429 且 Java 侧 blockQps 为 0，说明限流配置在 Nginx 层过严；反之若 Java 侧异常飙升而 Nginx 无 5xx，则问题在应用自身
