Nginx、HAProxy、微服务网关

Nginx、HAProxy、微服务网关全套技术问答汇总文档

1. HAProxy是什么技术？什么场景使用？

一、HAProxy 是什么技术

HAProxy（High Availability Proxy） 是一款免费、开源、高性能的负载均衡器 + 反向代理软件，由 Willy Tarreau 于 2000 年发布，采用事件驱动、单进程/多线程模型，擅长处理高并发、低延迟的 TCP/UDP 与 HTTP/HTTPS 流量。

核心定位

四层（TCP）负载均衡：基于 IP+端口转发（如 MySQL、Redis、SSH）。
七层（HTTP/HTTPS）负载均衡：基于域名、URL、Cookie 等应用层信息智能路由。
高可用：内置健康检查、故障自动剔除、无缝重载，配合 Keepalived 可实现主备无单点。

关键能力

高性能：单实例支持数十万并发连接、百万级 QPS，内存占用低。
SSL/TLS 卸载：集中处理 HTTPS 加密/解密，减轻后端服务器压力。
会话保持：支持 Cookie、IP 哈希等，确保用户请求定向到同一后端。
流量控制：ACL 规则、限流、连接数限制、黑白名单。
可观测性：丰富日志、统计页、监控接口，便于运维排障。

二、典型使用场景

1. Web 服务负载均衡（最常用）

场景：高并发网站、电商平台、门户系统。

作用：将用户 HTTP/HTTPS 请求分发到多台 Web 服务器（Nginx、Tomcat），提升并发能力与可用性，避免单台服务器瓶颈。

2. API 网关 / 微服务入口

场景：微服务架构、RESTful API、gRPC 服务。

作用：作为统一入口，实现路由转发、负载均衡、限流、熔断、SSL 卸载、安全防护，简化客户端调用。

3. 数据库负载均衡（TCP 四层）

场景：MySQL、PostgreSQL、Oracle 集群，读写分离。

作用：分发 SQL 请求到多个数据库节点，实现读负载均衡、故障自动转移，提升数据库吞吐量与稳定性。

4. 高可用架构（消除单点）

场景：核心业务系统、支付、订单、金融级应用。

作用：双机主备（配合 Keepalived），主节点故障秒级切换到备节点，保障业务 7×24 小时在线。

5. Kubernetes Ingress（容器化流量入口）

场景：K8s 集群内部服务对外暴露。

作用：作为 Ingress Controller，实现集群外流量进入、域名路由、SSL 终止、负载均衡，替代 Nginx Ingress，性能更强。

6. 高性能 TCP 代理（非 HTTP 场景）

场景：Redis、Memcached、FTP、SSH、VPN 等 TCP 服务集群。

作用：四层转发，低延迟、高吞吐，分发流量到多个后端节点，提升服务扩展性。

三、HAProxy vs Nginx（核心差异）

对比项	HAProxy	Nginx
擅长场景	四层+七层负载均衡、高并发 TCP、高可用	Web 服务器、静态资源、反向代理、HTTP 缓存
性能	TCP 转发更强，并发更高	HTTP 静态处理更优
负载均衡算法	13+种（轮询、最小连接、一致性哈希等）	基础算法，相对较少
会话保持	原生强支持	需配置模块
SSL 卸载	性能极佳	支持但高并发下资源占用较高

四、总结

HAProxy 是高并发、高可用架构的“流量枢纽”，核心解决负载均衡、流量分发、故障转移、SSL 卸载问题，广泛用于 Web、API、数据库、K8s 等场景，是互联网大厂（GitHub、Instagram）与企业级应用的首选开源负载均衡方案。

2. SSL/TLS 卸载是什么意思？

一、先懂正常流程

用户浏览器访问网站是 HTTPS：

浏览器要和服务器做 SSL/TLS 加密握手
传输数据全程加密，防被窃听、篡改

如果后端每一台业务服务器都自己做 HTTPS 加密解密：

每台机器都要：证书配置、加解密运算、握手消耗CPU，又麻烦又耗性能。

二、SSL/TLS 卸载是什么

把 HTTPS 的加密解密工作，统一交给前面的负载均衡/代理（HAProxy、Nginx）来做，后端业务服务器只用跑明文 HTTP，不用管证书、不用做加解密。

流程变成：

用户 → HAProxy：HTTPS 加密流量
HAProxy 做 SSL 卸载：解密成明文 HTTP
HAProxy → 后端业务服务：明文 HTTP 传输
响应回来再由 HAProxy 加密回给用户

所谓「卸载」= 把SSL/TLS加解密的负担，从后端服务器“卸下来”，交给前端代理统一处理。

三、核心好处

省后端CPU：加解密很耗CPU，统一由HAProxy扛，后端专心跑业务逻辑。
证书统一管理：只在HAProxy配一次SSL证书，不用每台后端机器都装证书。
方便管控：在代理层就能做HTTPS强制跳转、证书更新、安全策略，不用改后端服务。
便于抓包调试：内网是明文，排查问题更简单。

四、生活化例子

- 正常：每个小店自己都要验票、加密检票（每台后端自己搞HTTPS）

- SSL卸载：门口设一个统一检票亭（HAProxy），所有人在门口验票解密，里面小店直接接待明文客人，不用自己验票。

五、常见使用位置

HAProxy、Nginx、云负载均衡、API 网关都标配 SSL/TLS 卸载 功能。

3. Nginx是如何实现动静分离的？

一、什么是动静分离

静态资源：图片、JS、CSS、HTML、字体、视频，不变、不用后端计算。
动态资源：接口、页面渲染、查数据库、业务逻辑，需要 Java/PHP/Go 后端处理。

动静分离：

让 Nginx 直接处理静态资源，动态请求转发给后端应用服务器（Tomcat/Java/PHP）。

二、Nginx 怎么实现动静分离（核心原理）

Nginx 靠 匹配 URL/后缀 做判断：

匹配到静态后缀（.jpg .png .js .css .html 等）→ Nginx 本地直接返回文件，不找后端。
匹配到 动态请求（/api、.do、.php 等）→ 反向代理转发给后端服务。

优势

Nginx 处理静态文件性能极强、高并发、省后端CPU。
后端只专注跑业务逻辑，不被静态请求压垮。
静态可以做缓存、压缩、CDN 加速，访问更快。

三、两种常见实现方式

方式1：按文件后缀区分（最常用）

server {
    listen 80;
    server_name www.xxx.com;

    # 静态资源：Nginx 本地直接返回
    location ~* \.(jpg|png|gif|js|css|html|woff|ttf)$ {
        root /usr/local/nginx/static;
        expires 7d;  # 浏览器缓存7天
    }

    # 动态接口：转发给后端 Tomcat/Java
    location /api/ {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
    }
}

方式2：按目录区分

静态都放 /static/ 目录下：

# 静态目录直接本地返回
location /static/ {
    root /usr/local/nginx;
    expires 7d;
}

# 其他全部走后端
location / {
    proxy_pass http://127.0.0.1:8080;
}

四、架构流程图

用户浏览器
     ↓
   Nginx
┌───────┬───────┐
静态请求     动态请求
(图片/JS/CSS)  (/api/业务接口)
   ↓            ↓
Nginx直接返回   转发给 Tomcat/Java后端

五、总结

Nginx 通过 正则匹配后缀/目录，静态资源自己扛、动态请求转给后端，这就是动静分离，目的是减轻后端压力、提升网站并发和访问速度。

4. nginx都有哪些功能作用？都在什么场景中使用？

一、Nginx 是什么

Nginx 是高性能 Web服务器、反向代理、负载均衡、静态资源服务器，主打高并发、低内存、稳定、抗抗压。

二、Nginx 全部核心功能 + 适用场景

1. 静态资源服务器

功能：直接托管 html、js、css、图片、字体、视频等静态文件，自带缓存、压缩、零业务开销。

场景：

网站静态页面、前端打包资源部署
图片/文件服务器
替代 Apache、Tomcat 做静态访问

2. 反向代理（最常用）

功能：用户访问 Nginx，Nginx 悄悄把请求转发给后端真实服务，隐藏后端IP和端口。

场景：

外网不能直接暴露后端Java/Tomcat/Node服务
统一入口，前端只访问Nginx，不用记后端多服务地址

3. 动静分离

功能：静态资源Nginx直接返回，动态接口转发给后端Java/PHP。

场景：

传统网站、管理后台、前后端不分离项目
减轻后端服务器压力，提升并发能力

4. 负载均衡

功能：把请求分发到多台后端服务器，轮询/权重/IP哈希等算法，自动剔除故障节点。

场景：

后端多台Tomcat、SpringBoot集群
高并发电商、官网、业务系统
保证服务不单点、扩容方便

5. SSL/TLS 证书卸载（HTTPS 配置）

功能：配置证书，实现 HTTP 转 HTTPS，前端加密、内网明文。

场景：

所有官网、小程序、APP接口必须HTTPS
统一证书管理，后端不用配证书

6. 端口转发、域名跳转

功能：

多域名绑定同一台服务器
80端口强制跳转443
旧域名重定向到新域名

场景：

一台服务器部署多个网站
域名改版、防止流量丢失

7. 限流、防爬虫、防盗链

功能：限制单IP访问频率、连接数；禁止别人盗用图片资源；拦截恶意请求。

场景：

防刷接口、防DDOS、防爬虫
保护图片/视频资源不被盗用

8. 缓存功能

功能：对接口、静态资源做本地缓存，减少后端重复请求。

场景：

热门列表、首页数据缓存
减轻数据库和后端接口压力

9. 压缩传输（Gzip）

功能：自动压缩 js/css/html，减小传输体积，打开网页更快。

场景：

所有网站、H5、管理后台标配开启

10. 跨域解决

功能：Nginx 配置响应头，解决前端浏览器跨域问题。

场景：

前后端分离项目，前端域名和后端接口域名不一致

11. 文件上传、大文件断点续传

功能：支持大文件上传、限速、超时控制。

场景：

后台管理系统文件上传、附件系统

12. 微服务网关简易替代

功能：按路径路由到不同微服务，实现简单网关能力。

场景：

小型微服务项目，不想部署 Spring Cloud Gateway、Kong 时，用Nginx做简易路由

三、汇总 Nginx 能力

1. 托管静态资源

2. 反向代理隐藏后端

3. 负载均衡集群分发

4. HTTPS 证书统一配置

5. 动静分离减压后端

6. 域名跳转、多站点部署

7. 限流、防盗链、防爬虫

8. Gzip压缩、缓存、解决跨域

四、常见整体架构使用位置

用户浏览器/APP
      ↓
    Nginx （入口：HTTPS+反向代理+负载均衡+动静分离+限流）
      ↓
后端集群（SpringBoot/Tomcat/微服务）

5. nginx的功能和微服务的网关有什么区别？他们是如何组合使用的？

一、定性区别

Nginx：七层高性能反向代理、负载均衡、静态资源、SSL卸载，偏流量接入层、硬件级高性能。

微服务网关：业务逻辑层网关，偏微服务治理、权限、鉴权、限流熔断、路由编排。

二、核心功能区别

1. Nginx 擅长做什么

1. 高并发接入层流量，抗大流量、高吞吐

2. 静态资源托管、动静分离

3. SSL/TLS 卸载、HTTP 转 HTTPS

4. 四层/七层基础负载均衡

5. Gzip压缩、浏览器缓存、防盗链、简单限流

6. 多域名、端口转发、重定向

短板

- 不擅长复杂业务鉴权、登录认证、权限控制

- 没有微服务注册发现、熔断降级、灰度发布

- 不适合写复杂业务逻辑、动态路由配置麻烦

2. 微服务网关（SpringCloud Gateway）擅长做什么

1. 统一登录鉴权、Token校验、身份认证

2. 微服务动态路由（对接Nacos/Eureka注册中心）

3. 限流、熔断、降级、灰度发布、蓝绿部署

4. 请求参数过滤、接口签名、安全校验

5. 统一日志、链路追踪、接口监控

6. 适配微服务体系，和SpringCloud生态无缝集成

短板

- 静态文件处理性能远不如Nginx

- 高并发大流量抗压不如Nginx

- 不适合直接暴露公网做最外层入口

三、关键区别对照表

维度	Nginx	微服务网关(SC Gateway)
定位	公网接入层、边缘入口	微服务内部业务网关
性能	极高，异步事件模型，抗高并发	中等，Java应用，高并发弱于Nginx
主要能力	反向代理、负载均衡、SSL、静态、压缩、缓存	鉴权、路由、限流熔断、灰度、注册发现
业务逻辑	几乎不做业务逻辑	可做业务级拦截、权限控制
注册发现	不原生支持，配置写死	原生对接Nacos/Eureka，动态路由
部署位置	最外层，直接暴露公网	Nginx后面，内网层
适用场景	全局流量入口、静态资源、HTTPS卸载	微服务统一入口、业务治理

四、生产环境标准组合架构

外网用户/APP/小程序 → Nginx → 微服务网关 → 各个微服务

外网用户/APP/小程序
        ↓
     【Nginx 最外层】
  做：SSL卸载、HTTPS、静态资源、
       全局负载均衡、防攻击、动静分离
        ↓
【SpringCloud Gateway 微服务网关】
  做：鉴权Token、路由转发、限流熔断、
       灰度、日志、链路追踪
        ↓
微服务集群（用户服务/订单服务/商品服务...）

每层分工

1. Nginx 干活

- 扛住公网大流量

- 统一配SSL证书，HTTPS解密

- 静态资源（图片/js/css）直接返回，不进网关

- 全局负载均衡、简单防刷、域名跳转

- 把动态接口请求，统一转发给微服务网关集群

2. 微服务网关干活

- 接收Nginx转发过来的动态请求

- 校验Token、登录权限、接口拦截

- 根据路径路由到对应的微服务

- 做限流、熔断、降级、灰度发布

- 统一埋点日志、链路追踪

五、为什么不只用一个？

1. 只用Nginx：做不了微服务鉴权、动态路由、熔断灰度，业务治理能力为0。

2. 只用微服务网关：Java网关抗压差、处理静态资源弱、不适合直接暴露公网扛攻击、SSL性能差。

3. 组合使用：Nginx扛流量、做接入；网关管业务、做治理，各司其职，架构最稳。

六、极简总结

1. Nginx 是高性能接入层，负责公网入口、SSL卸载、静态资源、全局负载均衡；

2. 微服务网关是业务治理层，负责鉴权认证、动态路由、限流熔断、灰度发布；

3. 企业标准架构：外网→Nginx→微服务网关→微服务，Nginx管流量接入，网关管业务治理。

6. 微服务一般只会有一个网关入口吗？nginx的负载均衡到微服务网关，是如何分发的？

一、微服务是不是只有一个网关入口？

不是只有一个，分两种情况：

1. 中小型项目：统一一个网关入口

所有端（小程序、APP、H5、后台管理）全部走同一个 SpringCloud Gateway。

优点：简单好维护、统一鉴权、统一限流

缺点：所有流量挤在一个网关集群，大业务不够灵活

2. 中大型/大型项目：拆分多个网关（按业务/按端）

常见拆分方式：

用户网关：APP、小程序、H5 前端请求
后台网关：运营后台、管理系统
第三方网关：对外开放 API、第三方对接
内部网关：微服务之间内部调用专用

好处：

互不影响，一个网关崩了不影响其他端
可以单独给某类业务做限流、灰度、权限策略
扩容、运维隔离更清晰

二、Nginx 怎么负载均衡到「微服务网关集群」？

关键点：微服务网关不会只部署单实例，都是部署多台做成集群，Nginx 在上层做七层负载均衡，把请求分发到网关集群里的每一台网关节点。

1. 架构流程

用户/外网
    ↓
  Nginx（最外层）
    ↓ 负载均衡分发
网关集群：
  Gateway-1  192.168.1.100:8080
  Gateway-2  192.168.1.101:8080
  Gateway-3  192.168.1.102:8080
    ↓
各个微服务

2. Nginx 核心配置（真实生产写法）

第一步：定义网关集群 upstream

# 微服务网关集群列表
upstream gateway_cluster {
    server 192.168.1.100:8080;
    server 192.168.1.101:8080;
    server 192.168.1.102:8080;
}

默认策略：轮询，挨个分发请求。

第二步：所有接口请求转发到网关集群

server {
    listen 80;
    server_name api.xxx.com;

    # 全部接口转发给网关集群
    location / {
        proxy_pass http://gateway_cluster;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

3. Nginx 分发的几种算法

1. 轮询（默认）：请求挨个分给网关1、网关2、网关3，平均分配

2. weight 权重：给配置高的网关多分配流量

upstream gateway_cluster {
    server 192.168.1.100:8080 weight=3;
    server 192.168.1.101:8080 weight=1;
}

3. ip_hash：同一个用户始终访问同一台网关，保持会话

4. least_conn：分给当前连接数最少的网关，自动减压

4. 故障自动剔除

某一台网关挂了，Nginx 自动探测健康状态，坏的节点暂时剔除，不再分发流量，等恢复了再自动加回来。

三、总结

1. 微服务不一定只有一个网关，大企业按端/业务拆多个网关；小项目一个网关集群够用。

2. Nginx 通过 upstream 配置网关集群地址列表，内置轮询/权重/IP哈希等算法，把外网请求均衡分发到每一台微服务网关，实现网关层高可用、横向扩容。

7. 多微服务集群完整拓扑架构（订单/商品多实例）

整体链路：客户端 → Nginx集群 → 微服务Gateway网关集群 → 各业务微服务集群（多实例）

┌───────────────┬───────────────┬───────────────┐
│ 浏览器/H5      │ APP手机端     │ 小程序/第三方  │
└───────┬───────┴───────┬───────┴───────┬───────┘
        │               │               │
        ▼               ▼               ▼
┌───────────────────────────────────────────────┐
│              Nginx 高可用集群                  │
│ 职责：SSL卸载、HTTPS、动静分离、静态资源、      │
│      全局防攻击、负载均衡转发到网关集群        │
└───────────────────┬───────────────────────────┘
                    │
                    ▼
┌───────────────────────────────────────────────────────┐
│            SpringCloud Gateway 网关集群               │
│ 网关节点1  192.168.10.10:8888                         │
│ 网关节点2  192.168.10.11:8888                         │
│ 网关节点3  192.168.10.12:8888                         │
│ 【Nginx upstream 轮询/权重分发，自动剔除故障节点】     │
└───────────────┬───────────────────────┬───────────────┘
                │                       │
        路径匹配路由            注册中心(Nacos/Eureka)
        /order/** /goods/**      统一管理所有微服务上下线
                │                       │
                ▼                       ▼
┌────────────────────┐     ┌────────────────────┐
│   订单微服务集群    │     │   商品微服务集群    │
│ Order-Service-1    │     │ Goods-Service-1    │
│ Order-Service-2    │     │ Goods-Service-2    │
│ Order-Service-3    │     │ Goods-Service-3    │
└────────────────────┘     └────────────────────┘

┌────────────────────┐  ┌────────────────────┐
│   用户微服务集群    │  │   库存微服务集群    │
│ User-Service-1     │  │ Stock-Service-1     │
│ User-Service-2     │  │ Stock-Service-2     │
└────────────────────┘  └────────────────────┘

一、关键关联细节

1. Nginx ↔ 网关集群细节

1. Nginx 配置 upstream 写所有网关实例IP:端口，做七层负载均衡。

2. Nginx 只把 /api/** 动态接口转发给网关；图片/JS/CSS 静态资源 Nginx 直接返回，不进网关。

3. 外网 HTTPS 终结在 Nginx，Nginx → 网关内网走明文HTTP。

2. 网关 ↔ 多个微服务集群细节

1. 网关对接Nacos/Eureka注册中心，自动发现：订单服务多实例、商品服务多实例、用户、库存等多实例

2. 网关按URL路径路由：

/order/** 自动负载均衡转发到 Order-Service 集群多个实例
/goods/** 自动负载均衡转发到 Goods-Service 集群多个实例

3. 网关层统一做：Token鉴权、限流、熔断、灰度、跨域，后端每个微服务集群不用重复处理。

4. 某一个微服务实例挂了，注册中心自动下线，网关自动剔除，不影响整体业务。

二、完整流量走向举例

用户请求：https://api.xxx.com/goods/list

1. 浏览器 → Nginx（HTTPS解密、SSL卸载）

2. Nginx 负载均衡 → 任选一台 Gateway 网关

3. 网关匹配路径 /goods/** → 转发到商品微服务集群某一个实例

4. 商品服务处理完原路返回

三、架构特点总结

- Nginx：最外层入口，扛流量、做SSL、反向代理到网关集群；

- Gateway网关：承接Nginx流量，按路径路由，自动负载均衡到每个业务的微服务集群（多实例）；

- 每个业务（订单/商品/用户）都是多实例集群部署，实现高可用、可横向扩容。

8. 网关怎么负载均衡到多个业务微服务集群？（原理 + 流程 + 细节，通俗易懂）

先把核心结论先说透： 网关自己内置了负载均衡器，再配合注册中心（Nacos/Eureka），自动拿到每个微服务的多实例列表，然后按算法分发请求，不用手写 IP，自动感知上下线。

一、先理清三层关系

Nginx：只负载均衡到网关集群（把请求分给某一台网关）
SpringCloud Gateway：接收 Nginx 请求，自己做第二步负载均衡
每个业务微服务：订单集群、商品集群、用户集群，都是多实例部署

二、网关实现微服务负载均衡完整原理

1. 第一步：所有微服务启动后注册到注册中心

订单服务启动 3 个实例：

order-service  192.168.1.50:8080
order-service  192.168.1.51:8080
order-service  192.168.1.52:8080

商品服务启动 2 个实例：

goods-service  192.168.1.60:8080
goods-service  192.168.1.61:8080

全都主动注册到 Nacos/Eureka。

2. 第二步：网关订阅注册中心

Gateway 网关启动后：

连接 Nacos/Eureka
订阅所有微服务
自动拉取到：
- order-service 的 3 个实例地址列表
- goods-service 的 2 个实例地址列表
- user-service 实例列表……

网关本地实时维护一份 服务名 → 实例 IP 列表 映射表。

3. 第三步：网关根据 URL 路径路由到对应服务

网关配置路由规则：

# 路径匹配 + 服务名转发
routes:
  - id: order-route
    uri: lb://order-service   # lb=开启负载均衡
    predicates:
      - Path=/order/**

  - id: goods-route
    uri: lb://goods-service
    predicates:
      - Path=/goods/**

访问 /order/xxx → 匹配到 order-service
访问 /goods/xxx → 匹配到 goods-service

重点：lb:// 就是开启网关内置负载均衡

4. 第四步：网关按负载均衡算法分发到多实例

网关内置负载均衡算法（默认轮询）：

收到 /order/** 请求
从本地列表拿出 order-service 3 个实例
按 轮询 / 权重 / 随机 / 最小连接 选一个实例转发
自动跳过宕机、下线的实例

三、完整流量流转全过程

以请求 GET /order/list 为例：

客户端 → Nginx
Nginx 负载均衡 → 某一台 Gateway 网关
网关匹配路径 /order/** → 定位到服务 order-service
网关从本地服务列表，按负载均衡算法 选一台订单实例
请求转发到：订单服务某一个节点
响应原路返回

客户端
   ↓
 Nginx（负载均衡到网关集群）
   ↓
Gateway网关
  1.路径匹配 /order/**
  2.查Nacos拿到order-service 3个实例
  3.内置负载均衡算法选其中一台
   ↓
订单微服务集群 任选一台实例处理

四、网关负载均衡关键能力细节

不用手动配置 IP 微服务扩容、加机器、下线机器，网关自动感知，不用改配置、不用重启。
自动健康检查、剔除故障节点 某一个订单实例挂了 → Nacos 标记不健康 → 网关自动把它从列表剔除 → 不再分发流量。
每个微服务集群独立负载均衡
1. 订单集群自己轮询
2. 商品集群自己轮询互不干扰。
内置多种负载均衡算法 轮询、权重、随机、IP 哈希、最小连接，可灵活配置。

五、一句话极简总结

微服务全部注册到 Nacos/Eureka；
网关订阅注册中心，自动获取每个服务的多实例地址；
网关通过 路径匹配 定位到对应微服务名；
网关内置 lb 负载均衡组件，自动把请求按算法分发到该服务集群的某一个实例；
服务上下线、故障，网关自动感知，无需人工改配置。

9.HAProxy、Nginx、微服务网关三者生产选型 & 层级组合用法

先给核心结论： **HAProxy、Nginx 是接入层负载均衡 / 反向代理；微服务网关是业务治理层。大企业三层叠放：HAProxy → Nginx → 微服务网关；中小企业两层：Nginx → 微服务网关；简单项目：只用 Nginx 就够。**

一、先定三者定位（本质区别）

1. HAProxy

定位：专业四层 + 七层高性能负载均衡、TCP/UDP 全能
强项：超高并发、四层 TCP 负载均衡、数据库集群、Redis 集群、LVS 替代、高可用主备
弱项：静态资源不如 Nginx、不适合做 Web 静态站点、业务治理为 0

2. Nginx

定位：Web 静态服务、七层反向代理、SSL 卸载、动静分离
强项：静态资源、缓存、Gzip、防盗链、HTTP/HTTPS 接入层、部署简单
弱项：四层 TCP 不如 HAProxy、微服务治理能力没有

3. 微服务网关（SpringCloud Gateway/Kong）

定位：微服务业务网关、治理层
强项：鉴权、Token、动态路由、限流熔断、灰度、注册中心联动、微服务生态集成
弱项：高并发抗压不如前两者、不适合裸奔直接对外网暴露

二、生产中 3 种标准组织架构（按公司规模）

架构 1：小型项目 / 创业公司（最常用）

层级：用户 → Nginx → 微服务网关 → 各微服务

客户端
   ↓
Nginx（最外层入口）
- SSL卸载、HTTPS、动静分离、静态资源
- 负载均衡转发到网关集群
   ↓
SpringCloud Gateway
- 鉴权、路由、限流、灰度
   ↓
用户/订单/商品 微服务集群

适用：业务不大、流量一般、不用四层复杂转发，只用 Nginx 足够。

架构 2：中大型企业 / 互联网公司（标准三层）

层级：用户 → HAProxy → Nginx → 微服务网关 → 微服务

客户端
   ↓
HAProxy 集群
- 全局四层/七层负载均衡
- 高可用、故障转移、TCP端口转发
- 统一流量入口，做最外层流量调度
   ↓
Nginx 集群
- SSL证书统一管理、HTTPS解密
- 静态资源、动静分离、缓存、防攻击
   ↓
微服务网关 Gateway
- 业务鉴权、路由、限流熔断、微服务治理
   ↓
各业务微服务集群

分工为什么要叠两层 HAProxy+Nginx：

HAProxy 扛最外层大流量、做四层负载均衡（数据库、Redis、TCP 服务都能统一调度）
Nginx 专注做 HTTP/HTTPS web 处理：SSL、静态、缓存、压缩，各司其职
内网隔离、分层防护，安全更高、扩容更灵活

架构 3：传统非微服务项目

层级：用户 → Nginx → Tomcat / 后端服务

不用微服务、不用网关
Nginx 直接做反向代理、动静分离、负载均衡到多台 Tomcat
HAProxy 都可以不用

三、什么时候选 HAProxy？什么时候只用 Nginx？

必须用 HAProxy 的场景

需要四层 TCP 负载均衡：MySQL、Redis、MQ、Oracle 集群
要做高可用主备、秒级故障切换（配合 Keepalived）
超高并发流量、需要极致吞吐、低延迟
多业务集群统一流量入口，同时代理 TCP + HTTP 混合流量

只用 Nginx 就够的场景

纯 Web、HTTP/HTTPS 业务
需要静态资源、动静分离、Gzip、浏览器缓存
中小型微服务、管理后台、官网、APP 接口
配置简单、运维成本低

什么时候必须上微服务网关？

微服务架构，有用户鉴权、Token 登录
需要限流、熔断、降级、灰度发布
要对接 Nacos/Eureka 动态路由、服务自动发现
多端统一入口：APP / 小程序 / 后台共用一套接口入口

四、三者选型一句话口诀

纯 Web、中小型微服务：Nginx + 微服务网关两层足够；
大型互联网、有 TCP 集群（数据库 / Redis）、高可用要求高：HAProxy + Nginx + 网关三层架构；
传统单体项目：只需要 Nginx，不用 HAProxy、不用网关；
HAProxy 偏底层流量负载，Nginx 偏 Web 接入，网关偏业务治理。

五、每层固定分工（面试直接背）

HAProxy：底层全局流量调度、四层 TCP 负载均衡、高可用
Nginx：Web 接入层、SSL 卸载、静态资源、动静分离、HTTP 负载均衡
微服务网关：业务鉴权、动态路由、限流熔断、微服务治理

posted @ 2026-05-04 13:53 ConfidentLiu 阅读(56) 评论(0) 收藏举报

刷新页面返回顶部

ConfidentLiu