1. 项目概述动静分离和负载均衡到底解决了什么问题先聊一个让很多团队头疼的场景一套Java Web应用上线后初期用户量不大一台Tomcat扛得住响应也还行。等业务量起来了并发一高Tomcat线程池被打满页面加载越来越慢更别提图片、CSS、JS这些静态资源——明明和业务逻辑没关系却也挤占了宝贵的应用线程。这时候很多人的第一反应是加服务器、堆配置但钱花了问题往往没根治。用Nginx配合Tomcat做“动静分离”加“负载均衡”就是一套成熟、低成本、见效快的解法。Nginx在前面顶住静态资源的请求和并发连接Tomcat在后面专心处理JSP、Servlet和接口请求再用负载均衡把请求分摊到多台Tomcat上既提升了单机吞吐也为后续的水平扩展铺好了路。这套架构几乎是Java Web项目的标配组合无论是刚毕业的初级开发还是带了几年团队的技术负责人都应该掌握其中的原理和落地细节。这篇文章我不打算只贴一份能跑的配置而是把思路、参数选型、踩坑点一起拆开讲。你会看到为什么静态资源一定要交给Nginx、upstream的几种策略各自适合什么场景、配置写好后怎么验证效果以及线上最常遇到的几个诡异问题是怎么排查的。适合正在给项目做性能优化的人也适合准备架构面试的人——面试官问Nginx配置很少只问语法基本都会追到“为什么这么配”。2. 整体设计思路为什么要用Nginx挡在前面2.1 动静分离的价值拆解在没有Nginx介入的纯Tomcat架构里所有请求都进Tomcat请求一个1MB的图片和请求一段复杂SQL的接口占用的是同一批线程。Tomcat的默认最大线程数通常是200左右意味着同一时刻大约只能同时处理200个请求。如果50个请求都在下大图片真正能分给接口处理的线程就只剩150个接口的响应时间会明显被拉长——这是典型的“资源错配”。动静分离的本质是谁擅长什么就让它干什么。Nginx处理静态资源有天然优势基于epoll的事件驱动模型一个进程能扛住数万并发连接处理小文件时开销极低还可以开启sendfile、gzip、缓存等特性把这些能力发挥到极致。Tomcat则专注于动态逻辑Java的线程模型更适合处理计算、数据库访问、远程调用这类任务。静态请求不再进入Tomcat的线程池动态接口的可用线程数相当于被完整释放了整个系统的吞吐能力自然就上去了。还有一个常被忽略的收益安全性和稳定性。Nginx挡在最前面可以对请求做访问控制、限流、请求体大小限制静态文件也不需要Tomcat去读了减少了文件句柄的占用和磁盘I/O竞争。如果哪天某个Tomcat节点挂掉Nginx还能通过健康检查自动把它摘掉对用户几乎没有感知。2.2 负载均衡的几种策略和选型依据Nginx的负载均衡基于upstream模块实现核心策略有四种我按实际场景的适用度从高到低说。默认的是轮询策略每个请求按时间顺序逐一分配到后端Tomcat。它背后的逻辑是假设每台服务器配置相同、每个请求耗时相近适合绝大多数无状态服务。但如果后端机器配置差异明显比如一台8核16G、另一台4核8G轮询会把流量等分弱的机器容易成为瓶颈。这时就该用加权轮询在server后面加weight参数例如weight2表示这台机器承担两倍于weight1的流量。这个参数需要结合机器配置和压测数据来定不是拍脑袋写的——我见过有人给弱机器配了更高的权重结果上线后那台机器直接被打挂。ip_hash策略按照客户端IP的哈希结果分发请求同一个IP会稳定落在同一台后端服务器上。它解决的核心问题是Session共享如果后端没有做Session同步或外置存储轮询会导致用户请求跳转到不同TomcatSession频繁失效用户表现为“动不动要重新登录”。但ip_hash也有副作用某个IP下的请求量特别大时会集中在某一台机器上造成负载不均如果那台机器故障该IP下的会话也会全部受影响。它更适合那种“暂时没条件做Session外置先保住登录态”的阶段。least_conn策略会把新请求分配给当前连接数最少的后端适合请求处理时长差异很大的场景。比如有的接口快、几十毫秒就返回有的接口慢、要好几秒单纯轮询会让处理慢请求的机器积压越来越多的连接least_conn则能动态平衡。实际部署中如果所有后端都是同规格机器且做了健康检查我倾向于用least_conn或者带权重的least_conn它在多数业务模型下表现都比较稳定。还有一个容易被忽略的细节Nginx的负载均衡是基于反向代理实现的。客户端只跟Nginx建立连接Nginx再把请求转发给后面的Tomcat。这意味着Nginx本身不能成为单点故障生产环境至少需要两台Nginx做高可用比如配合keepalived挂一个虚拟IP。这个属于架构层面的延伸单机Nginx的训练环境不需要考虑但上线前必须纳入规划。3. 核心参数拆解Nginx配置里每一项都是为什么3.1 手写一份动静分离加负载均衡的配置先拿一份最典型的配置配置里每行后面我会标出关键的参数意图然后逐个拆开讲。# 定义Tomcat后端节点 upstream tomcat_cluster { # least_conn; # 按连接数分配注释掉表示默认轮询 server 10.0.0.11:8080 weight1 max_fails2 fail_timeout30s; server 10.0.0.12:8080 weight2 max_fails2 fail_timeout30s; keepalive 32; } server { listen 80; server_name example.com; # 动静分离先匹配静态资源由Nginx直接处理 location ~* \.(gif|jpg|jpeg|png|css|js|ico|woff2?|eot|ttf|svg)$ { root /data/webapp/static; expires 7d; access_log off; sendfile on; log_not_found off; } # 动态请求反向代理到Tomcat集群 location / { proxy_pass http://tomcat_cluster; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_connect_timeout 5s; proxy_read_timeout 60s; index index.jsp; } }先看location的匹配顺序。location ~* \.(gif|jpg|jpeg|png|css|js|ico|woff2?|eot|ttf|svg)$用了正则匹配Nginx会先尝试匹配普通前缀location再按顺序匹配所有正则location一旦命中就停止。所以这段正则必须放在普通location之前吗不一定因为正则匹配单独一个阶段只要它是所有正则中第一个匹配成功的就行。但为了维护清晰我习惯把静态资源的location写在前面。根目录root /data/webapp/static的坑需要重点说。这个root配合正则location使用时Nginx会把完整的请求URL拼到root后面去查找文件。比如请求/images/login.pngNginx实际查找的文件路径是/data/webapp/static/images/login.png。如果项目中的静态资源路径本身带了一个前缀目录比如/assets/images/login.png根目录就必须是/data/webapp/static/assets否则会404。很多人第一次配置时在这里卡半天查文件权限没问题、目录存在没问题结果就是路径拼接逻辑没搞明白。expires 7d是配合浏览器做强缓存的常用手段。静态资源一般不会频繁变动给一个7天的Expires头用户第二次访问时会直接从本地缓存加载连Nginx都不需要访问。这里要注意既然设了强缓存那前端发布新版本时文件名必须带上版本号或内容哈希比如app-3f2a9d.js否则用户会一直拿到旧的缓存文件。这个配合问题属于团队协作层面的坑后端配好了缓存前端不处理版本号照样会出线上事故。把静态请求的日志关掉是性能细节。静态资源的访问量通常远大于动态接口每个请求都写访问日志会带来大量磁盘I/O。access_log off对静态location生效动态请求则保留日志便于排查。log_not_found off的意思是如果静态文件不存在Nginx不往错误日志里刷404记录避免日志暴涨。3.2 proxy_pass与tomcat之间必须交代清楚的头信息动态请求转发到Tomcat时有三个头是必须设置的而且各有原因。Host $host保证Tomcat拿到的Host头和用户浏览器访问时一致。如果不设置Tomcat里的request.getServerName()会返回Nginx的内网IP很多基于域名做判断的逻辑会全部失效比如链接生成、单点登录回调、某些安全校验。这个参数的实质就是反向代理不能篡改业务对域名的感知。X-Real-IP和X-Forwarded-For是为了传递真实客户端IP。Nginx转发后Tomcat直接通过request.getRemoteAddr()拿到的是Nginx的IP所有客户端的IP都成了同一个值日志分析、风控、限流全部失真。X-Real-IP是Nginx自定义的一个头通常只加一层代理时用X-Forwarded-For则是行业标准的追加式头每经过一层代理就追加一个IP。Java后端一般用X-Forwarded-For里最左边、且不是信任代理地址的那一个IP作为客户端真实IP而不是无脑取第一个值——如果前面还有CDN这个解析逻辑要判断多层。proxy_set_header X-Forwarded-Proto $scheme解决的是协议传递问题。Nginx如果配置了HTTPS转发到Tomcat时如果不带这个头Tomcat里的request.isSecure()会判定请求不是安全的导致redirect的地址生成成http://开头的明明用户访问的是https跳转后就变成了http页面提示不安全。这个细节点很多人上线TLS后才会发现。顺带一提keepalive 32的含义。它是在upstream块内配置的指定Nginx到后端Tomcat的空闲长连接数量。默认情况下Nginx每转发一个请求就和Tomcat重新建立一条TCP连接高并发时连接建立的开销很可观。设置keepalive后Nginx会复用和后端的空闲连接减少握手耗时。但需要注意这个参数不是越大越好它需要在Nginx的http块里同时开启upstream模块的长连接支持并且Tomcat的maxKeepAliveRequests如果设得太小比如默认的100长连接复用次数多了后端可能主动断开Nginx侧会出现连接重置之类的报错。3.3 Tomcat侧必须同步调整的配套参数光调Nginx不管Tomcat是不行的。生产环境下后端服务的代码不变但线程池、连接超时这些参数要和架构匹配起来。Tomcat的Connector配置在conf/server.xml里核心参数是Connector port8080 protocolHTTP/1.1 connectionTimeout20000 maxThreads400 minSpareThreads20 acceptCount200 maxKeepAliveRequests500 redirectPort8443 /maxThreads决定Tomcat最多同时处理多少个请求线程默认200压力大时容易成为瓶颈。但盲调没用——线程数调到500如果数据库连接池只有20个连接线程会挤在数据库等待上只是把积压点从Tomcat线程池转移到了数据库连接池整体吞吐不会提升。我见到很多团队给Tomcat加线程却不看MySQL的max_connections最后数据库先崩了。所以调参一定是链路级联动的Nginx的worker_connections、Tomcat的maxThreads、数据库连接池大小、应用自身的线程池要按流量预测量级一起评估。还有URIEncodingUTF-8这个参数。以前老版本Tomcat默认是ISO-8859-1参数里的中文会乱码新版本默认UTF-8了但如果你维护的是老项目还是检查一下比较稳妥。另外一旦用了Nginx转发Tomcat的server.xml中最好去掉Host里的autoDeploytrue这类开发期配置避免生产环境上热部署导致奇怪的问题。后端如果有多台TomcatSession同步怎么处理是架构设计里绕不开的点。最省事的方案是在Nginx用ip_hash把同一用户固定到同一台Tomcat。但这个方案有两个先天问题一是某个节点挂掉后固定到该节点的用户会话直接丢失需要重登二是流量分布可能不均衡。更稳的方案是引入Session外置存储比如Redis统一保存Session这样任何一台Tomcat都能读到同一份会话数据ip_hash就可以去掉了负载均衡的调度完全自由。Spring Boot项目里集成Redis Session非常快两三行配置的事个人建议哪怕刚开始只有两台Tomcat也直接上Redis Session后面扩容零障碍。4. 实操过程从零搭建一套可复现的环境4.1 节点规划与安装准备为了演示我规划一套最小规模的环境。用虚拟机或者云主机都行我这里用一个简化的内网网段做示意。准备两台配置相同的Linux服务器装CentOS 7或更新的Linux发行版都可以。这里为了说明给它们起虚构代号节点A和节点B。角色服务对应机器反向代理Nginx节点A后端应用Tomcat节点A 节点B数据库MySQL独立节点或复用节点B演示用这套环境中节点A既跑Nginx又跑一个Tomcat实例节点B跑另一个Tomcat实例模拟两台后端。实际上生产环境不建议Nginx和Tomcat同机部署因为Nginx需要保持轻负载来支撑高并发连接Tomcat占用CPU和内存较高两者同机容易互相争抢资源。演示环境中为了节省机器同机操作可以理解但要明确标注出这是演示妥协。Nginx安装没什么特别用包管理器装或者编译安装都行。Linux发行版自带的Nginx通常版本偏旧如果要用到一些新特性建议通过官方源安装。我这边习惯用编译安装一是能指定安装目录、模块二是方便日后排查问题时快速定位版本和编译参数。但编译安装对小白不太友好依赖没装全容易报错。如果只是为了快速验证动静分离和负载均衡用系统包管理器安装就够了后文配置不依赖任何编译模块。Tomcat这边我用的Java版本和Tomcat版本需要注意兼容性。Java 8对应Tomcat 8.5/9.0都没问题Java 17的话建议Tomcat 10.1以上因为Tomcat 10把javax.servlet迁移到了jakarta.servlet代码包名变了老应用直接扔上去会报ClassNotFoundException。这一步是很多人在升级时踩的大坑——Tomcat版本不是随便换的要跟着Java和Servlet规范走。4.2 部署手册级别的操作步骤按顺序执行以下步骤。第一在节点A和节点B上分别安装JDK和Tomcat确保两个节点的Tomcat能独立通过http://节点IP:8080访问这个是最基本的连通性验证。第二在节点A上装Nginx在/etc/nginx/conf.d/下新建一个虚拟主机配置文件。我用的是一份更完整的配置版本user nginx; worker_processes auto; worker_rlimit_nofile 65535; events { worker_connections 10240; use epoll; } http { include /etc/nginx/mime.types; default_type application/octet-stream; sendfile on; tcp_nopush on; keepalive_timeout 65; client_max_body_size 20m; gzip on; gzip_types text/css application/javascript application/json image/svgxml; gzip_min_length 1k; upstream tomcat_cluster { least_conn; server 节点A内网IP:8080 max_fails2 fail_timeout30s; server 节点B内网IP:8080 max_fails2 fail_timeout30s; keepalive 32; } server { listen 80; server_name 你的域名或IP; location ~* \.(css|js|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot)$ { root /data/webapp/static; expires 7d; access_log off; add_header Cache-Control public; } location / { proxy_pass http://tomcat_cluster; proxy_http_version 1.1; proxy_set_header Connection ; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } }第三部署一个最简单的Java Web应用用于验证。不需要太复杂一个会返回当前服务器IP和Session ID的页面即可。在所有后端Tomcat的webapps目录下放同一个应用包保证两台节点的应用代码完全一致。第四静态资源目录准备。在节点A的/data/webapp/static下放一张测试图片和一个测试CSS文件并用chown -R nginx:nginx /data/webapp/static调整属主避免Nginx worker进程因权限不足返回403。这个权限问题也是高频踩坑点很多403不是配置问题就是Nginx进程对目录没有读权限。第五启动所有服务后开始验证。浏览器访问Nginx地址连刷几次观察应用页面返回的服务器标识是否在节点A和节点B之间切换直接访问一张图片的URL用浏览器的开发者工具看响应头确认有Expires或Cache-Control字段确认响应服务器头Server字段显示的是Nginx而不是Tomcat就说明静态请求被Nginx直接拦截了。4.3 验证和压测配置有没有生效用数据说话很多人在验证动静分离时只看“页面正常打开了”就认为配置生效了。这不够严谨。我用两个方法做验证。第一个是响应头验证。动态请求经过Nginx转发后Tomcat返回的响应头里通常会带有X-Powered-By之类的标识Nginx自己处理静态文件时则没有。更直接的方法是看响应头里的Server字段Nginx返回的一般是Server: nginx/版本号如果请求被发到了TomcatTomcat 9默认不一定返回Server头但它的响应样式和其他字段能看出来区别。第二个是日志验证。Nginx的access日志里请求方式那一行的处理时间是关键指标。静态资源的请求耗时通常是个位数毫秒动态请求可能几十到几百毫秒。配置生效后静态资源的耗时应该远低于动态请求。我见过有人把所有请求都转发给Tomcat但配置里照样写了一段静态location结果静态location命中不到因为路径不对所有请求都走了动态转发页面也能打开但压测数据一对比就露馅了——吞吐上不去Tomcat CPU飙升。压测工具我推荐wrk或者ApacheBenchab。ab的优势是自带且简单wrk更吃性能也更准。压测的目标不是测出极限数字而是验证两点一是静态资源请求完全不经过Tomcat二是多台Tomcat都收到了请求。压测几轮后在节点A和节点B的Tomcat本地访问日志里能看到请求来自Nginx的IP说明转发正常且两台都有访问记录说明负载均衡生效。如果只有一台有记录优先检查upstream里节点配置是否有误。5. 常见问题实战排查我踩过的几个典型坑5.1 静态资源404但文件确实存在这个坑我前文提过一次但值得单独展开。现象是浏览器访问http://Nginx_IP/static/css/style.cssNginx返回404但在节点A的/data/webapp/static/static/css/style.css里手动创建目录后居然能访问通了——很多人在这里恍然大悟。原因在root的拼接逻辑。配置里写的是root /data/webapp/static;请求URL是/static/css/style.cssNginx实际查找的路径是/data/webapp/static/static/css/style.css。多了一层static目录。理解这个拼接机制以后解法就有两种一种是调整root为/data/webapp另一种是改用aliaslocation ~* ^/static/.*\.(css|js|png)$ { alias /data/webapp/; }alias会直接把location匹配到的路径替换为指定路径不像root那样拼接。但alias与正则location的配合有时会有限制部分Nginx版本中正则location不能用alias。所以更稳妥的方案是直接用root把目录结构设计成和URL路径一致或者用location ^~ /static/加root的组合前缀匹配配合root语义最好理解location ^~ /static/ { root /data/webapp/; }这个前缀匹配会命中所有/static/开头的请求root指定为/data/webapp/实际查找路径就是/data/webapp/static/...完美对应。注意^~的意思是命中后不再继续匹配正则location但代价是static目录下的所有文件不会再走后面的正则规则。5.2 动态请求Session老是丢失应用部署了多台Tomcat用户登录后访问几次就退出登录排查Nginx配置没问题后台日志能看到请求在不同Tomcat之间跳转。这个问题的根源就是Session不共享。Nginx层面的临时解法是改用ip_hash但长远方案一定是Session外置。我用某个有状态服务的真实案例说明某系统为用户中心三个后端节点最开始是轮询用户反馈登录状态老掉。后来先改ip_hash现象消失但一段时间后发现节点之间流量倾斜严重。最终方案是引入Redis Session统一存储用户会话全部落在Redis里Nginx改回least_conn后端任意一台都能处理任意用户的请求故障节点摘除后用户无感知。Spring Boot项目改造Redis Session很简单引入spring-session-data-redis依赖后在配置类上加EnableRedisHttpSession即可。遗留的Spring MVC项目可以用Spring Session的XML方式配置原理相同。这里要额外注意Redis本身的可用性——Session放到Redis后Redis成了关键节点必须做好持久化和主从或集群部署否则Redis一挂所有人同时掉登录态这个故障比之前更严重。5.3 配置改了不生效到底reload还是restart这个属于操作习惯问题但每天都有新同学踩。Nginx的配置修改后需要用nginx -t先检查语法再执行nginx -s reload重载配置。reload过程是平滑的master进程会启动新的worker进程新请求走向新配置旧worker进程处理完手头请求后退出。所以线上环境的Nginx配置变更永远用reload不要restart——restart会断开当前所有连接正在传输的请求直接中断。Tomcat的server.xml修改后一般需要重启Tomcat才能生效因为Connector的线程池参数在启动时初始化。但是很多应用代码更新不需要重启Tomcat你把新的war包扔进webapps目录Tomcat检测到变化会自动重新部署。这个自动部署的功能在生产环境建议关掉原因一是不可控二是热部署偶尔会引发内存泄漏。生产环境统一走停服部署或者优雅下线流程先从Nginx的upstream中把节点注释掉reload Nginx等该节点的存量请求处理完再停Tomcat发布完启动后重新加回upstream。5.4 压测发现所有请求都堆在一台Tomcat如果配置了least_conn但压测时发现流量并没有均匀分摊先检查是不是session粘连导致。least_conn模式下在不启用ip_hash的情况下Nginx本身不会做会话粘连请求应该分散。但如果应用里自己通过Cookie做了会话保持或者Nginx配置里同时保留了ip_hash指令就会出现“看起来配了负载均衡实际上全在一台”的假象。另一个隐蔽点upstream里的max_fails和fail_timeout设置不当会导致节点被临时隔离。比如max_fails2意味着2次失败后30秒内不再向该节点分发请求如果某台Tomcat因为应用发布或网络抖动出现了一个瞬时错误Nginx会把它摘掉后续流量全部打到另一台。压测时只盯着Nginx日志看“为什么只有一台收到请求”很容易忽略这一点。排查方法是查看Nginx的错误日志看是否有upstream timed out或connect failed之类的记录。5.5 大文件上传失败配置了client_max_body_size 20m;后上传超过20MB的文件仍失败。先确认Nginx层面的错误信息常见的是返回413 Request Entity Too Large。如果Nginx配置确实生效还报413可能是上传请求经过了CDN或其他代理层那层代理对请求体大小也有限制。另外Tomcat的maxSwallowSize和maxPostSize默认值也有限制Tomcat 9默认maxPostSize是2MB超过会拒绝。所以大文件上传要同时调Nginx、Tomcat、以及应用本身Spring的spring.servlet.multipart.max-file-size和max-request-size。三层中任何一层没改都可能卡住。而且这三层报错形式各不相同Nginx报413、Tomcat可能直接断开连接、Spring可能抛出MaxUploadSizeExceededException排查时需要逐层确认请求到底卡在哪。6. 性能调优进阶让Nginx发挥到极限6.1 连接数模型的几个关键参数Nginx性能调优的核心首先在于连接数模型。worker_processes建议设置为auto让Nginx自动匹配CPU核心数每个核心对应一个worker进程。worker_connections默认值是1024意思是每个worker进程能同时处理1024个连接总连接数就是worker_processes乘以worker_connections。调这块的时候先把所有进程能打开的文件句柄上限调上去worker_rlimit_nofile 65535;然后worker_connections才能对应调大。如果不调rlimit句柄到顶后Nginx会报too many open files连接数再大也没用。keepalive_timeout决定客户端与Nginx之间的长连接保持时间。默认65秒如果前端是浏览器访问这个值可以保持如果前面还有CDN或网关建议缩短到10~20秒减少无效连接的占用。tcp_nopush和tcp_nodelay这两个参数经常被一起讨论前者优化大文件传输的包发送效率后者确保小响应不被延迟合并发送。对动态接口来说tcp_nodelay on是必要的否则触发Nagle算法小数据包可能会等待后面的数据一起发引入几十毫秒延迟。6.2 缓存除了浏览器强缓存还有Nginx本地缓存静态资源的浏览器缓存解决了重复访问的问题但第一次访问时Nginx仍然要从磁盘读文件。如果流量足够大可以启用proxy_cache做Nginx本地的内容缓存。这种方案主要应用于Nginx直接转发到上游的场景比如动态页面或接口的响应做了短时间缓存。配置思路如下先定义缓存路径和内存缓存区再定义缓存有效期然后在location中开启proxy_cache。需要注意几点一是缓存键默认包含请求URL和参数动态页面缓存时慎用避免拿到脏数据二是缓存清理机制要配套可以用第三方模块配合管理或者使用短有效期让自然过期三是缓存目录的磁盘容量要监控写满会导致缓存失效甚至返回错误。我在实际项目里的体会是proxy_cache更多用在接口网关层做「读多写少」的查询缓存比如商品详情、配置信息这类数据缓存10-30秒对数据库的减压效果非常明显。但纯粹的动静分离场景Nginx给静态资源做磁盘缓存的意义不大——文件系统的page cache已经很高效了再加一层反而多一次磁盘读写。这个点要区分清楚不要为了追求配置完整性硬加。6.3 HTTPS接入的注意点架构里如果接了HTTPSNginx的SSL配置有一些细节必须处理。首先证书链要配置完整ssl_certificate和ssl_certificate_key之外中间证书如果缺失部分老设备或特定客户端会报证书信任错误。其次SSL会话复用的参数ssl_session_cache建议开启能明显减少TLS握手的开销尤其在高并发短连接场景下。启用HTTP/2也是性价比很高的优化现在主流Nginx版本都支持listen 443 ssl http2;的写法新版本需要单独用http2 on;指令HTTP/2的多路复用特性对少并发、多资源的网页加载体验提升非常明显尤其是同一页面有几十个静态资源文件的场景。但HTTP/2强制要求HTTPS所以如果项目还在用明文HTTP想享受这层优化必须先上TLS。7. 架构层面的进一步思考这套方案还能怎么扩展7.1 Nginx也可以做API网关的部分工作动静分离加负载均衡只是Nginx在Java Web架构里的基础职能。实际项目中Nginx还能承担不少API网关的职责。比如用limit_req和limit_conn做接口限流防止某个接口被刷用allow/deny做IP黑白名单用return 403拦截恶意请求用proxy_next_upstream实现在某个节点返回500或超时时自动重试另一个节点。这些能力叠加起来Nginx就从简单的流量分发器升级为应用入口的守护层。把Nginx当成网关用的时候要注意一个配比问题网关层配置越复杂单机性能损耗越大。如果需要在网关层做大量鉴权、转发规则、限流策略建议评估是否需要引入OpenResty或者基于Nginx做过深度定制的网关产品。换句话说能用Lua写业务逻辑的网关是另一个技术栈的决策不是简单修配Nginx配置文件能替代的。对于大多数中小团队Nginx原生的配置能力加上后端应用自身的防护已经足够了。7.2 容器化时代的部署方式现在的项目很多是容器化部署Nginx和Tomcat各自跑在容器里。这时候动静分离和负载均衡的配置原理没有变但有几个新问题要考虑。Nginx容器里的upstream server地址不再固定在宿主机IP上而是通过服务发现机制解析到后端容器的动态IP。比较常见的做法是让Nginx所在容器和后端Tomcat容器处于同一个Docker网络或Kubernetes集群内用服务名或者内部DNS解析替代IP写死。容器环境下还多了一个层级如果外部流量先进Ingress或Gateway再转发到Nginx再到Tomcat那Nginx这一层是不是有必要保留需要根据团队规模判断。在Kubernetes场景里Ingress Controller本身已经具备一定的负载均衡能力可以替代传统Nginx的角色。但如果Pod内的请求路径复杂静态资源量很大保留Nginx做动静分离依然有意义。方案没有标准答案核心是与团队现有的基础设施和运维能力匹配。7.3 日志与监控闭环架构搭好之后日常运维的监控是容易忽略的部分。Nginx访问日志里藏着大量信号请求量趋势、响应状态码分布、upstream响应时间、磁盘I/O节奏。建议把Nginx的access日志格式做一次整理加入$upstream_response_time、$upstream_addr、$request_time这样能直接统计Nginx到后端Tomcat的响应耗时。配合Prometheus加Grafana用nginx-exporter采集基础指标能看到连接数、读写字节数、请求状态码分布这些运行指标。Tomcat的JVM监控同样重要用JMX导出堆内存、GC次数、线程池活跃线程数到监控系统配合Nginx的指标联合排查。我遇到过一次线上卡顿从Tomcat线程堆栈看到大量线程阻塞在数据库连接获取上但因为监控里只配了Nginx指标差点被误导去优化Nginx配置。这种跨组件的排查经验说明监控一定要有链路视角不能只看单一组件。8. 最后再分享一个低成本但收益明显的验证用例我在做培训分享时经常安排一个小实验成本很低但把动静分离和负载均衡的核心知识全串起来了适合刚学完理论的同学自己动手验证。在部署好的环境中把Nginx里的静态资源location临时注释掉让所有请求都转发给Tomcat然后用ab对同一张图片做压测。对比配置开启和关闭两组数据你会看到Tomcat的QPS差距在一到两个数量级。这个实验能让每个人直观理解“静态资源交给Nginx处理”不是一句空话而是实实在在的数量级差距。另一个实验是人为制造后端故障。把节点B的Tomcat直接停掉不修改Nginx配置持续灌请求观察Nginx的日志和返回结果。如果配置了max_fails和fail_timeout节点B会在几次失败后被自动摘除所有请求自动转到节点A用户侧感知不到异常如果没有配置部分请求会超时或报502。这个故障实验能验证Nginx健康检查机制是否可靠也是面试时“如何实现高可用”这个问题最直接的实操回答。我个人在实际操作中的体会是Nginx和Tomcat的组合方案难点向来不在配置语法而在理解每一层为什么存在。把静态和动态的边界理清楚把会话和IP的关系想明白把超时和重试的语义搞透彻后面再叠Redis、容器化、服务治理都是水到渠成的事。不要一上来就抄一份大而全的配置——先跑通最小闭环再逐步加参数填细节出问题时能快速定位到层这比任何“万能配置模板”都可靠。