应用裸奔的三个老问题
把 Spring Boot 应用直接暴露给用户，很快会遇到三件事：静态资源抢线程——Tomcat 的线程池被图片、CSS 请求占满，业务接口排队；单机天花板——想加第二台机器，域名指向哪个都别扭，没有统一入口；TLS 没处放——证书配在应用里，每台都要管续期。这三个问题，Nginx 一个进程全接了。
Nginx 的三重身份
Web 服务器：直接吐静态文件，快到离谱；反向代理：站在应用前面，把请求转给后端，用户只见 Nginx 不见应用；负载均衡：把流量按策略分给多台后端，顺带做健康检查。放在整条链路里，它是流量的大门——DNS 解析到它，CDN 回源到它，应用的生死荣辱都从它门前过。
扛高并发的底气：epoll
// Nginx 的进程模型：1 个 master + N 个 worker（默认=CPU 核数）
//
// master：读配置、绑定端口、管理 worker，不碰流量
// worker：每个 worker 单线程，用 epoll 同时盯几万个连接
//
// 传统"一线程一连接"（早期 Tomcat 模式）：
// 1 万连接 = 1 万线程 = 内存爆炸 + 上下文切换灾难
//
// epoll 事件驱动：连接闲着就不管它，事件来了才处理
// 1 个 worker 盯 10 万连接也不慌——因为同一时刻活跃的就几百个
// 这就是 C10K 问题的答案，也是 Nginx 快的根源注意对比：Tomcat 是一个请求占一个线程直到处理完（阻塞式业务逻辑），Nginx 是事件驱动、非阻塞 IO。所以 Nginx 干不了业务逻辑（没有线程给你sleep），但接流量一骑绝尘——各守各的岗位，谁也不替代谁。
它不做什么
三个不做：不做业务逻辑（没有计算引擎，Lua 扩展另说）；不替代 Redis（有代理缓存，但那是 HTTP 层的缓存，不是分布式缓存）；不做复杂鉴权（JWT 校验之类交给网关，呼应微服务治理系列里网关的定位）。把 Nginx 当万能瑞士军刀用，往往是事故的开始。
这个系列的路线图
十五篇分四段：基础（配置文件、location 匹配、反向代理）、流量治理（负载均衡、动静分离、压缩缓存、限流）、安全与细节（HTTPS、rewrite、WebSocket、日志排错）、进阶（性能调优、高可用、收官）。每篇都以"能抄走的配置"结尾——Nginx 是拿来用的，不是拿来背的。下一篇从配置文件的全景地图讲起。
评论 (0)