Nginx 运维实战：动静分离，加速静态资源访问！
一、概述
在现代 Web 应用中，动静分离是一种常见的性能优化策略。通过将动态请求和静态资源分开处理，可以有效提升网站的响应速度、减轻后端服务器的压力，并提高整体系统的可扩展性。
Nginx 作为一款高性能的反向代理服务器和 Web 服务器，非常适合用于实现动静分离。本文将详细介绍如何使用 Nginx 来进行动静分离配置，以加速静态资源的访问。
二、什么是动静分离？
动态请求：需要后端程序（如 PHP、Java、Python、Node.js 等）实时处理并生成内容的请求，例如用户登录、数据查询等。
静态资源：指不需要后端处理即可直接返回的文件，如 HTML 页面、CSS、JavaScript、图片、字体、视频等。
动静分离就是让不同的服务分别处理这两类请求：
使用 Nginx 直接处理静态资源；
将动态请求转发给后端应用服务器（如 Tomcat、Gunicorn、FastCGI、Node.js 等）处理。
三、为什么要做动静分离？
为什么需要做动静分离呢？它带来的好处是什么？其实这个问题也并不难回答，当你搞懂了网站的本质后，自然就理解了动静分离的重要性。先来以淘宝为例分析看看：
当浏览器输入www.taobao.com访问淘宝首页时，打开开发者调试工具可以很明显的看到，首页加载会出现100+的请求数，而正常项目开发时，静态资源一般会放入到resources/static/目录下。
在项目上线部署时，这些静态资源会一起打成包，那此时思考一个问题：假设淘宝也是这样干的，那么首页加载时的请求最终会去到哪儿被处理？答案毋庸置疑，首页100+的所有请求都会来到部署WEB服务的机器处理，那则代表着一个客户端请求淘宝首页，就会对后端服务器造成100+的并发请求。毫无疑问，这对于后端服务器的压力是尤为巨大的。
“但此时不妨分析看看，首页100+的请求中，是不是至少有60+是属于*.js、*.css、*.html、*.jpg.....这类静态资源的请求呢？答案是Yes。
既然有这么多请求属于静态的，这些资源大概率情况下，长时间也不会出现变动，那为何还要让这些请求到后端再处理呢？能不能在此之前就提前处理掉？当然OK，因此经过分析之后能够明确一点：做了动静分离之后，至少能够让后端服务减少一半以上的并发量。 到此时大家应该明白了动静分离能够带来的性能收益究竟有多大。
OK~，搞清楚动静分离的必要性之后，如何实现动静分离呢？其实非常简单，实战看看。
四、实现动静分离
先在服务器部署Nginx，然后在Nginx目录下创建一个目录static存放静态资源。
将项目中所有的静态资源全部拷贝到该目录下，而后将项目中的静态资源移除重新打包。
稍微修改一下nginx.conf的配置，增加一条location匹配规则。
server {listen 80;server_name localhost;# 静态资源访问location ~ \.(jpg|jpeg|png|gif|ico|css|js|woff|woff2|ttf|svg|txt)$ {root /usr/share/nginx/html/static;expires 30d; # 设置缓存时间add_header Cache-Control "public, no-transform"; # 明确告诉浏览器和CDN可以缓存该资源try_files $uri =404; # 请求的文件在服务器上不存在，直接返回 404，防止出现“空响应”或“目录遍历”问题}# 动态请求交给后端处理location / {proxy_pass http://localhost:3000;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;}
}然后照常启动nginx和移除了静态资源的WEB服务，你会发现原本的样式、js效果、图片等依旧有效
总结
动静分离的本质就是“各司其职”——让擅长处理静态资源的 Nginx 去做它最擅长的事，让后端专注于业务逻辑处理，从而打造高性能、高可用的 Web 系统。