Nginx 反向代理配置的拆分设计:文件名不重要,边界设计更重要
随着服务器数量和自建服务逐渐增加,Nginx 反向代理配置往往会从最初的几个 server 块,发展成一个包含大量域名、端口、证书和代理规则的超长配置文件。 这种集中式配置在规模较小时没有明显问题,但当后端主机越来越多后,维护成本会迅速上升。此时,可以采用一种更清晰的设计: 按后端主机拆分 Nginx 反向代理配置,一台主机对应一个配置文件。 这不仅是文件整理方式的变化,更是一种配置管理思想的变化。 一、Nginx 是否关心配置文件的名字 Nginx 通常不关心配置文件叫什么名字,它真正关心的是主配置中的 include 指令。 例如: 这条规则表示: 加载指定目录中所有以 .conf 结尾的文件。 因此,下面这些文件名都可以被加载: Nginx 不会因为文件名中出现了 host、proxy、storage 或其他词语,就赋予文件特殊功能。 文件名主要是给管理员阅读和管理使用的。 真正决定配置是否生效的是: 例如,当加载规则是: 以下文件通常不会被加载: 因为它们并不是以 .conf 结尾。 这也是一种很实用的配置停用方式:保留文件,但通过修改后缀让它退出加载范围。 二、为什么要按后端主机拆分 一个反向代理节点可能同时代理多台后端服务器。 例如: 如果所有配置都写在同一个文件中,随着服务数量增加,文件会逐渐变成: 不同主机、不同服务和不同证书混在一起,查找和修改都容易出错。 按后端主机拆分后,目录结构可以变成: 每个文件只负责一台后端主机。 例如: 只包含所有转发到主站服务器的域名和服务。 只包含备份管理系统的入口。 只包含转发到另一台独立服务器的域名和端口。 这种设计符合一个重要原则: 将具有相同变化原因的配置放在一起,将变化原因不同的配置分开。 某台后端服务器迁移、关机、更换地址或调整服务端口时,只需要检查对应的一个文件,而不必在数百行配置中寻找所有相关规则。 三、这种设计的核心思想 1. 高内聚 …