一、引文写这篇博客的起因是昨天一个朋友问我如果你的微服务项目出问题了用户访问页面响应404 Not Found该怎么办。我直接傻了查网关层然后再定位对应接口对照路径后面问了一些大佬后才知道一般来说如果微服务项目出现问题排查顺序一般都是倒着来的先查接口再查网关最后查Nginx。我恍然大悟随即想到了初中用电流表和电压表排除故障的物理题。羞愧之余决定重温一下微服务项目的架构故作此文分享给大家。二、架构分析本图很好地展现了Nginx的两大功能1.通过nginx的反向代理功能访问后台的网关资源。2.通过nginx的静态服务器功能访问前端静态页面。同时也间接展现了在“黑马头条”这类标准的微服务项目中架构通常分为三层前端展示层即图中的“前端项目”包含 HTML、CSS、JS 等静态文件。接入控制层由Nginx组成负责分发请求。业务逻辑层由Spring Cloud Gateway网关和底层的各个微服务组成。这种设计实现了动静分离即让 Nginx 处理它最擅长的静态资源而让 Java 容器专注于复杂的业务逻辑从而极大提升了系统的整体响应速度。三、Nginx1动静分离图中下方箭头指向的“静态资源”体现了 Nginx 作为高性能 Web 服务器的功能。资源托管前端开发打包后的 HTML、Vue 资源直接部署在 Nginx 服务器的目录下。性能优势Nginx 基于非阻塞 I/O 模型 (epoll)处理静态文件极其高效。当用户访问首页时Nginx 直接返回文件请求完全不需要经过 Java 后端极大地减轻了后台服务器的压力。2反向代理图中上方箭头指向的“网关”体现了 Nginx 作为反向代理服务器的功能。请求转发当前端发起 API 调用如登录、发帖时请求会先到达 Nginx。Nginx 根据 URL 路径例如匹配到/api/路径将请求转发给后端的 Spring Cloud Gateway。屏蔽内网对用户而言他们只知道 Nginx 的地址而不知道后端微服务的具体 IP 和端口。这有效地隐藏了内部网络拓扑增强了系统的安全性。3配置解读我们将黑马头条的App前端项目解压在了当前目录中记住当前路径一会配置需要用到。随后解压Nginx当前conf目录的nginx.conf文件是主配置文件。我们会在里面配置运行环境的全局参数。配置解耦最关键的一行是include leadnews.conf/*.conf;。这表明主配置文件并不直接写业务逻辑而是通过include指令引入外部的子配置文件。这种做法实现了模块化管理方便后期维护不同的业务模块如 App 端、自媒体端、管理后台。性能优化sendfile on;开启了零拷贝技术允许 Nginx 直接在内核空间完成文件发送无需经过用户缓冲区极大提升了发送 HTML、图片等静态资源的效率。#user nobody; worker_processes 1; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; # 引入自定义配置文件 include leadnews.conf/*.conf; }配置好主配置文件后我们需要在conf目录下创建leadnews.conf文件夹负责管理我们创建的多个子配置文件进行配置解耦。upstream heima-app-gateway{ server localhost:51601; } server { listen 8801; location / { root D:\WorkSpace\Java-WorkSpace\app-web; # 前端项目的位置 index index.html; } location ~/app/(.*) { proxy_pass http://heima-app-gateway/$1; proxy_set_header HOST $host; # 不改变源请求头的值 proxy_pass_request_body on; #开启获取请求体 proxy_pass_request_headers on; #开启获取请求头 proxy_set_header X-Real-IP $remote_addr; # 记录真实发出请求的客户端IP proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; #记录代理信息 } }1. 外部server块虚拟主机监听入口在配置文件最外层的server { ... }块代表的是一个虚拟主机 (Virtual Host)。它的含义它定义了 Nginx 作为一个 Web 服务器如何“接客”。它关注的是监听哪个端口如listen 8801;。匹配哪个域名如server_name localhost;。处理哪些路径通过location块定义的静态资源或转发规则。可以有多个吗完全可以。比如你可以在一台机器上运行一个 Nginx通过两个server块分别监听80端口给 App 用户用和8801端口给管理员用。它们彼此独立互不干扰。server块中的第一个location /处理的是静态请求。静态映射通过root指令指向了前端代码的具体物理路径如D:/workspace/app-web/。当用户访问8801端口时Nginx 直接从磁盘读取 HTML、JS、CSS 文件返回。效率优势这种方式避免了前端页面的请求进入 Java 虚拟机充分发挥了 Nginx 处理I/O 密集型任务的极高性能。第二个location ~/app/(.*)使用了正则表达式来匹配 API 请求。路径重写与转发proxy_pass http://heima-app-gateway/$1;是核心逻辑。它将匹配到的/app/后面的路径部分由$1捕获转发给前面定义的upstream网关。例如请求/app/login会被转发为网关的/login。关联概念这种配置实现了内外网隔离。前端只需要知道 Nginx 的 8801 端口而真实的微服务网关端口51601被隐藏在防火墙之后。配置文件中大量的proxy_set_header指令是为了解决反向代理带来的信息丢失问题。IP 溯源由于请求经过了 Nginx后端微服务直接获取到的 IP 会变成 Nginx 的服务器 IP。通过配置X-Real-IP和X-Forwarded-ForNginx 会将客户端的真实 IP放入请求头传给后端这对于后端的日志审计、风险控制如限制异地登录至关重要。保持 Hostproxy_set_header HOST $host;确保了原始请求的主机名不会在转发过程中丢失防止某些基于域名的业务逻辑失效。2.upstream里的server后端节点转发目标在upstream内部定义的server 127.0.0.1:51601;代表的是一个后端真实的业务实例。它的含义它是 Nginx 转发请求的最终目的地。它关注的是真实的物理地址即具体的 IP 和端口。健康状态Nginx 会根据配置判断这个后端节点是否还活着。可以有多个吗必须可以。为了实现高可用一个upstream逻辑组里通常会配置多个后端server实例通过负载均衡策略进行访问在图中对应的其实就是多个网关实例。总结Nginx 的 Upstream解决的是“如何把流量分发给网关集群”的问题外部负载均衡。网关内部逻辑解决的是“如何把流量分发给具体的业务微服务如文章服务、用户服务”的问题内部负载均衡。这种两级负载均衡的设计共同保障了整个后端系统承载海量用户访问的能力。3流程总结它们之间的逻辑关系是通过proxy_pass指令打通的用户访问http://localhost:8801/app/login。Nginx 的外部server块监听 8801 的那个接到了请求。location匹配到了/app/路径。执行proxy_pass http://heima-app-gateway;。Nginx 查找名为heima-app-gateway的upstream块。从该upstream块的内部server列表中挑选出一个具体的 IP如127.0.0.1:51601将请求转发过去。四、既生N何生G看到Nginx那么强大不禁生出既生Nginx何生Spring Cloud Gateway的想法。但是它们两个的分工是不同的。Nginx侧重运维与性能负责HTTPS 证书卸载、Gzip 压缩、全局负载均衡以及处理高并发的静态请求。它是 C 语言编写的性能更接近底层。Gateway侧重业务与治理负责微服务级别的权限校验、动态路由、服务熔断及限流。它是 Java 编写的能深度集成 Nacos 等微服务组件方便开发者用 Java 逻辑控制业务流程。五、总结看到这里相信你已经明白了Nginx和Gateway各自的分工了在微服务架构中它们是极其常见的对于刚入门的程序员而言熟悉这两层架构可以让我们后续的学习不再困扰为何这么设计。