test-repo/docs/zh-cn/appendix/7-infrastructure-and-operations/gateway-proxy.md

# 网关与反向代理
::: tip 🎯 核心问题
**在高并发的互联网架构中,如何把流量安全、高效地送到正确的服务?** 反向代理解决"流量怎么分发",API网关解决"请求怎么处理"。本文通过真实案例(前台接待、保安系统、智能路由)深入理解网关的设计哲学和工程实践。
:::

---

## 1. 为什么要"网关"?

### 1.1 从一个真实案例说起:某电商的架构演进

某电商平台在业务快速增长时遇到了严重的架构问题:

**场景还原:**

```
阶段一:直接暴露服务
客户端 → 直接调用用户服务、订单服务、支付服务...
         ↓
问题1:服务IP暴露,存在安全隐患
问题2:无法统一做认证、限流
问题3:新增服务需要修改客户端配置
```

::: warning ⚠️ 直接暴露的致命问题

- **安全隐患**: 所有服务IP暴露,容易被攻击
- **功能重复**: 每个服务都要做认证、限流、日志
- **扩展困难**: 新增服务要修改所有客户端
- **协议混乱**: 有的用HTTP,有的用gRPC,客户端要适配
  :::

**改进后的架构(引入网关):**

```
客户端 → API网关(Nginx/Kong) → 内部服务
         ↓
      统一认证、限流、路由
         ↓
      客户端只知道网关地址
```

::: tip ✨ 改进后的效果

- **安全**: 真实服务IP隐藏,只有网关对外
- **功能收敛**: 认证、限流、日志在网关统一处理
- **扩展容易**: 新增服务只需网关配置路由
- **协议统一**: 对外HTTP,内部可用gRPC
  :::

### 1.2 网关的生活化比喻

**前台接待**

想象你去一家大公司:

- **没有前台**: 访客直接找各部门,不知道在哪,公司乱成一团
- **有前台**: 访客先到前台,前台问清楚来意,再引导到对应部门

**API网关就是系统的"前台"**:

- **反向代理**: 前台,引导访客到正确的部门
- **API网关**: 智能前台,还能检查访客身份(认证)、限制访问人数(限流)

<ReverseProxyDemo />

---

## 2. 什么是反向代理?

### 2.1 正向代理 vs 反向代理

::: tip 🤔 术语解释
**正向代理(Forward Proxy)**:

- 部署在客户端侧
- 代替客户端访问外部资源
- 典型应用:VPN、翻墙工具
- 例子:公司网络,你通过代理访问外网

**反向代理(Reverse Proxy)**:

- 部署在服务器端
- 接收客户端请求并转发给内部服务
- 客户端只知道代理存在,不知道真实服务器
- 例子:Nginx、HAProxy
  :::

**对比表:**

| 维度         | 正向代理                 | 反向代理                 |
| ------------ | ------------------------ | ------------------------ |
| **部署位置** | 客户端侧                 | 服务器端                 |
| **服务对象** | 客户端                   | 服务器                   |
| **典型应用** | VPN、翻墙                | 负载均衡、网关           |
| **透明性**   | 服务器看到代理IP         | 客户端看到代理IP         |
| **目的**     | 隐藏真实客户端、加速访问 | 隐藏真实服务器、负载均衡 |

### 2.2 反向代理的核心价值

::: details 价值一:负载均衡
将流量分发到多个后端服务器,避免单点过载。

```
客户端
  ↓
Nginx(反向代理)
  ↓
┌─────────┬─────────┬─────────┐
│ 服务器1 │ 服务器2 │ 服务器3 │
└─────────┴─────────┴─────────┘
```

:::

::: details 价值二:安全防护
隐藏真实服务器IP,防止直接攻击。统一在代理层做安全防护。

```
客户端 → 只能看到Nginx的IP
真实服务器 → 只在内网,外部无法直接访问
```

:::

::: details 价值三:SSL终结
在代理层处理HTTPS加密解密,后端服务用HTTP,降低后端计算开销。

```
HTTPS客户端 → Nginx(加密/解密) → HTTP后端服务
                   ↑
              SSL终结点
```

:::

---

## 3. Nginx:为什么能扛起百万并发?

### 3.1 Master-Worker进程模型

Nginx采用**多进程**架构,而不是多线程:

**Master进程(管理者)**:

- 负责读取和验证配置文件
- 管理Worker进程(启动、停止、重新加载)
- 不处理具体请求

**Worker进程(工作者)**:

- 实际处理HTTP请求
- 每个Worker是独立的进程,相互隔离
- 数量通常设置为CPU核心数,避免上下文切换开销

::: tip 💡 优势

- **隔离性好**: 一个Worker崩溃,不影响其他Worker
- **充分利用多核**: 每个Worker独立运行
- **避免多线程复杂性**: 无需处理锁、竞争等问题
  :::

### 3.2 事件驱动 + 异步非阻塞

这是Nginx高性能的核心秘密:

**传统Apache(多进程/线程模型)**:

- 一个连接 = 一个进程/线程
- 并发数受限于系统进程/线程数
- 大量连接时,进程切换开销巨大

**Nginx(事件驱动模型)**:

- 使用epoll(Linux)/kqueue(macOS)等高效I/O多路复用机制
- 一个Worker进程可以同时处理数万个连接
- 连接没有数据时,不会占用CPU,有新数据时通过事件通知唤醒

::: tip 生活化比喻

- **Apache**: 餐厅里每个顾客配一个服务员(进程),顾客多需要大量服务员
- **Nginx**: 一个超级服务员,同时服务所有顾客,谁需要服务就去谁那里,而不是一直站在某个顾客旁边
  :::

<NginxArchitectureDemo />

---

## 4. 什么是API网关?

### 4.1 为什么需要API网关?

**想象一个没有网关的系统:**

- 客户端需要知道多个服务的地址(用户服务、订单服务、支付服务...)
- 每个服务都要自己做认证、限流、日志
- 协议不统一,有的用HTTP,有的用gRPC
- 服务升级时,客户端也需要跟着改

::: warning ⚠️ 没有网关的问题

- **客户端复杂**: 需要配置多个服务地址
- **功能重复**: 每个服务都要实现认证、限流
- **协议混乱**: 客户端要适配多种协议
- **升级困难**: 服务升级,客户端也要改
  :::

**有了API网关之后:**

- 客户端只需要知道网关地址,网关负责路由到正确服务
- 认证、限流、日志等横切逻辑统一在网关处理
- 网关可以做协议转换,对外统一暴露HTTP
- 后端服务升级,只需要改网关配置,客户端无感知

<ApiGatewayDemo />

### 4.2 API网关的核心功能

| 功能         | 说明                                       | 典型场景                                         |
| :----------- | :----------------------------------------- | :----------------------------------------------- |
| **路由转发** | 根据URL、Header等规则,将请求转发到不同服务 | `/api/users` → 用户服务,`/api/orders` → 订单服务 |
| **负载均衡** | 同一个服务有多实例时,分摊流量              | 用户服务有3台实例,轮询分发请求                   |
| **认证鉴权** | 统一校验JWT、OAuth Token                   | 未登录用户无法访问`/api/admin`                   |
| **限流熔断** | 控制流量上限,防止服务被压垮                | 每秒最多1000请求,超过返回429                     |
| **协议转换** | 对外HTTP,内部可转gRPC                      | 客户端用HTTP,网关转gRPC调用内部服务              |
| **灰度发布** | 按Header或比例,将部分流量导到新版本        | 5%用户体验新版本,95%用旧版本                     |
| **日志监控** | 统一记录请求日志,便于分析和排障            | 记录每次请求的耗时、状态码、返回大小             |

---

## 5. 网关实战:如何构建完整的网关架构?

### 5.1 完整架构图

```
┌───────────────────────────────────────────────────────────────────────┐
│                           客户端(浏览器/APP)                               │
└───────────────────────────┬─────────────────────────────────────────┘
                                │ HTTPS
                                ▼
┌───────────────────────────────────────────────────────────────────────┐
│                        外层:CDN + WAF                                  │
│  ┌─────────────────────────────────────────────────────────────┐  │
│  │  CDN(内容分发网络)                                        │  │
│  │  - 静态资源缓存(图片、CSS、JS)                           │  │
│  │  - 就近访问,降低延迟                                   │  │
│  └───────────────────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  WAF(Web应用防火墙)                                     │  │
│  │  - 防护SQL注入、XSS攻击                                │  │
│  │  - 拦截恶意Bot、爬虫                                  │  │
│  │  - CC攻击防护                              │  │
│  └───────────────────────────────────────────────────────────────┘  │
└───────────────────────────────────────────────────────────────────────┘
                                │
                                ▼
┌───────────────────────────────────────────────────────────────────────┐
│                     中层:API网关(Nginx/Kong)                      │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  第一层:SSL终结 + 安全防护                              │  │
│  │  - HTTPS / TLS 1.3                                        │  │
│  │  - HSTS、安全响应头                                        │  │
│  └───────────────────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  第二层:认证与鉴权                                      │  │
│  │  - JWT Token校验                                         │  │
│  │  - OAuth 2.0 / SSO集成                                     │  │
│  │  - API Key管理                                         │  │
│  │  - 权限校验(RBAC)                                        │  │
│  └───────────────────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  第三层:流量控制                                        │  │
│  │  - 限流- 令牌桶/漏桶算法                             │  │
│  │  - 熔断- 防止故障扩散                                 │  │
│  │  - 降级- 服务不可用时的备用方案                         │  │
│  │  - 灰度发布- 按比例分配流量                          │  │
│  └───────────────────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  第四层:路由与负载均衡                                    │  │
│  │  - 路径路由- Path-based Routing)                          │  │
│  │  - 域名路由- Host-based Routing)                           │  │
│  │  - Header路由- Header-based Routing)                             │  │
│  │  - 负载均衡算法- 轮询/加权/最少连接/IP哈希)             │  │
│  │  - 服务发现- Service Discovery)集成                        │  │
│  └───────────────────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  第五层:协议转换与数据处理                                 │  │
│  │  - SSL终结- HTTPS ↔ HTTP)                                   │  │
│  │  - 协议转换- HTTP ↔ gRPC / WebSocket)                         │  │
│  │  - 请求/响应转换- JSON ↔ XML)                               │  │
│  │  - 数据压缩- Gzip / Brotli)                                   │  │
│  │  - 缓存- Cache)- 静态资源和API响应                          │  │
│  └───────────────────────────────────────────────────────────────┘  │
└───────────────────────────────────────────────────────────────────────┘
                                │
                                ▼
┌───────────────────────────────────────────────────────────────────────┐
│                        内层:微服务集群                             │
│  ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐      │
│  │  用户服务    │ │  订单服务    │ │  商品服务    │ │  支付服务    │      │
│  │  User Svc   │ │  Order Svc  │ │ Product Svc │ │ Payment Svc │      │
│  │             │ │             │ │             │ │             │      │
│  └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘      │
│         │                │                │                │               │
│         └────────────────┴────────────────┴────────────────┘               │
│                                       │                              │
│                    服务发现与配置中心/ etcd)                          │
│                    - 服务注册与发现                                      │
│                    - 健康检查                                              │
│                    - KV配置存储                                              │
└───────────────────────────────────────────────────────────────────────┘
```

### 5.2 路由与负载均衡

网关的核心职责之一,就是**把请求送到正确的地方**。这涉及两个关键能力:**路由**(去哪台服务器)和**负载均衡**(怎么分配流量)。

::: details 路由规则:从URL到服务
想象一个电商系统,不同的URL对应不同的服务:

- `/api/users/*` → 用户服务
- `/api/orders/*` → 订单服务
- `/api/products/*` → 商品服务
- `/api/pay/*` → 支付服务

**Nginx配置示例:**

```nginx
server {
    listen 80;
    server_name api.example.com;

    # 用户服务
    location /api/users/ {
        proxy_pass http://user-service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # 订单服务
    location /api/orders/ {
        proxy_pass http://order-service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # 商品服务
    location /api/products/ {
        proxy_pass http://product-service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # 支付服务(需要更高安全级别)
    location /api/pay/ {
        # 限制IP访问
        allow 10.0.0.0/8;
        deny all;

        proxy_pass http://payment-service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}
```

:::

::: details 负载均衡:四种策略对比
当同一个服务有多个实例时,如何选择?

| 策略         | 原理                                              | 适用场景           | 优点                 | 缺点                         |
| :----------- | :------------------------------------------------ | :----------------- | :------------------- | :--------------------------- |
| **轮询**     | 按顺序依次分配给每台服务器                        | 服务器性能相近     | 简单公平             | 不考虑服务器当前负载         |
| **加权轮询** | 按权重比例分配,权重高的分配更多                   | 服务器性能不均     | 充分利用高性能服务器 | 需要合理设置权重             |
| **最少连接** | 分配给当前连接数最少的服务器                      | 长连接场景、视频流 | 动态适应负载变化     | 需要实时统计连接数           |
| **IP哈希**   | 根据客户端IP计算哈希,同一IP永远分配到同一台服务器 | 需要会话保持       | 保证会话一致性       | 某个IP流量大时会造成单点压力 |

**Nginx配置示例:**

```nginx
# 加权轮询
upstream backend_weighted {
    server 10.0.1.10:8080 weight=3;  # 性能好,承担更多流量
    server 10.0.1.11:8080 weight=2;
    server 10.0.1.12:8080 weight=1;  # 性能差,承担较少流量
}

# 最少连接
upstream backend_least_conn {
    least_conn;
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080;
}

# IP哈希(会话保持)
upstream backend_ip_hash {
    ip_hash;
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080;
}
```

:::

<LoadBalancingDemo />

---

## 6. 网关安全:如何守护系统大门?

### 6.1 认证与鉴权

**传统方式(每个服务各自认证):**

- 用户服务、订单服务、支付服务...每个都要校验JWT
- 代码重复,维护困难
- secret分散在各个服务,泄露风险高

**网关统一认证:**

- 客户端携带Token访问网关
- 网关校验Token合法性(签名、过期时间)
- 校验通过后,将用户信息(如user_id)添加到请求头,转发给后端服务
- 后端服务无需校验,直接从Header获取用户信息

::: tip 💡 核心思想
**认证在网关,鉴权在服务**:

- **认证**: 你是谁?(校验Token,获取用户身份)
- **鉴权**: 你能做什么?(根据用户角色判断权限)

就像公司前台:前台认证你的身份(身份证),但具体权限由各部门判断。
:::

<AuthMiddlewareDemo />

### 6.2 HTTPS与SSL终结

**为什么需要HTTPS?**

1. **安全**: 防止数据在传输过程中被窃取
2. **合规**: 现代浏览器对HTTP网站显示"不安全"警告
3. **SEO**: 搜索引擎优先收录HTTPS网站

**SSL终结方案:**

- 只在网关层配置HTTPS和证书
- 网关负责TLS握手和加解密
- 网关和后端服务之间使用HTTP明文传输(内部网络可信)
- 后端服务专注于业务逻辑,无需处理TLS

::: tip 💡 SSL终结的优势

- **简化管理**: 证书只在网关配置,后端无需配置
- **降低开销**: 后端服务不需要处理TLS握手
- **统一更新**: 证书更新只需在网关操作
  :::

<SslTerminationDemo />

---

## 7. 限流与熔断:如何防止系统被"流量洪水"冲垮?

### 7.1 限流算法对比

| 算法         | 核心思想                  | 突发流量                    | 适用场景                       | 实现复杂度 |
| :----------- | :------------------------ | :-------------------------- | :----------------------------- | :--------- |
| **令牌桶**   | 桶里装令牌,有令牌才能通过 | 允许一定程度的突发          | API限流、带宽控制              | 中等       |
| **漏桶**     | 请求进桶,匀速流出处理     | 强制平滑,突发会被缓存或拒绝 | 需要严格匀速处理的场景         | 中等       |
| **滑动窗口** | 统计时间窗口内的请求数    | 严格按窗口计数,超出一律拒绝 | 精确统计(如"1分钟内最多100次") | 较高       |

### 7.2 Nginx限流配置实战

```nginx
# 定义限流区域(放在http块中)

# 1. 基于IP的限流(漏桶算法)
# zone=mylimit:10m - 区域名称和内存大小(10MB约可存储16万IP)
# rate=10r/s - 每秒允许10个请求
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

# 2. 基于IP的连接数限制(防止单个IP建立过多连接)
limit_conn_zone $binary_remote_addr zone=addr:10m;

# 3. 基于服务端点的限流(不区分IP,保护后端整体)
limit_req_zone $server_name zone=server_limit:10m rate=100r/s;

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

    # 用户服务 - 普通限流
    location /api/users/ {
        # 应用限流
        # burst=20 - 桶容量,允许突发20个请求
        # nodelay - 不延迟处理突发请求(立即处理或拒绝)
        limit_req zone=mylimit burst=20 nodelay;

        # 限制单个IP的连接数
        limit_conn addr 10;

        proxy_pass http://user-service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # 订单服务 - 更严格的限流
    location /api/orders/ {
        # 更严格的限流:每秒5个请求
        limit_req_zone $binary_remote_addr zone=order_limit:10m rate=5r/s;
        limit_req zone=order_limit burst=10 nodelay;

        proxy_pass http://order-service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # 限流后的处理
    # 当请求被限流时,返回429 Too Many Requests
    error_page 429 /429.html;
    location = /429.html {
        internal;
        return 429 '{"error": "Too Many Requests", "message": "Rate limit exceeded. Please try again later."}';
        add_header Content-Type application/json;
    }
}
```

::: tip 💡 限流策略建议

- **普通接口**: 每秒10个请求,允许突发20个
- **重要接口**(支付、订单): 每秒5个请求,允许突发10个
- **全局保护**: 所有请求总和不超过每秒100个
  :::

<RateLimitingDemo />

### 7.3 熔断:防止故障扩散

**熔断器的工作原理:**

1. **关闭状态**: 正常转发请求,同时统计错误率
2. **开启状态**: 当错误率超过阈值,熔断器开启,直接返回错误,不再转发请求
3. **半开状态**: 经过一段时间后,允许少量请求通过试探,如果成功则关闭熔断器

::: tip 💡 核心思想
**熔断就像电路保险丝**: 电流过大时,保险丝自动熔断,保护整个电路不被烧毁。

类似地,当后端服务出现大量错误时,熔断器"跳闸",快速失败,防止故障扩散到整个系统。
:::

---

## 8. 总结:网关设计的核心思维

### 8.1 核心原则回顾

| 原则         | 含义                 | 实践要点                       |
| ------------ | -------------------- | ------------------------------ |
| **路由**     | 把请求送到正确的地方 | 路径路由、域名路由、Header路由 |
| **负载均衡** | 分摊流量到多台服务器 | 轮询、加权、最少连接、IP哈希   |
| **安全**     | 守护系统大门         | 认证鉴权、HTTPS、WAF           |
| **限流**     | 防止被流量冲垮       | 令牌桶、漏桶、滑动窗口         |
| **熔断**     | 防止故障扩散         | 快速失败、降级方案             |
| **可观测**   | 监控和排障           | 日志、指标、链路追踪           |

### 8.2 技术选型建议

::: tip 💡 选型决策树

```
选择网关:
│
├─ 只需要反向代理、负载均衡?
│  ├─ 是 → Nginx(首选)
│  └─ 否 → 继续
│
├─ 需要丰富的插件生态?
│  ├─ 是 → Kong(基于Nginx)
│  └─ 否 → 继续
│
├─ Spring Cloud 全家桶?
│  ├─ 是 → Spring Cloud Gateway
│  └─ 否 → Nginx
```

:::

---

## 9. 名词速查表

| 名词         | 英文                     | 解释                                                                                                               |
| ------------ | ------------------------ | ------------------------------------------------------------------------------------------------------------------ |
| **反向代理** | Reverse Proxy            | 部署在服务器端,接收客户端请求并转发给内部服务的代理服务。客户端只知道反向代理的存在,不知道真实服务器地址。         |
| **正向代理** | Forward Proxy            | 部署在客户端侧,代替客户端访问外部资源的代理服务。服务端看到的是代理的IP,不知道真实客户端。典型应用:VPN、翻墙工具。 |
| **API网关**  | API Gateway              | 位于客户端和后端服务之间的中间层,提供路由、认证、限流、日志等功能,是微服务架构的"统一大门"。                       |
| **负载均衡** | Load Balancing           | 将请求流量分配到多台服务器,避免单台服务器过载,提高系统可用性和性能。                                               |
| **SSL终结**  | SSL Termination          | 在网关层处理HTTPS加密解密,后端服务使用HTTP,降低后端计算开销,简化证书管理。                                         |
| **限流**     | Rate Limiting            | 限制单位时间内的请求数量,防止系统被突发流量压垮。常用算法:令牌桶、漏桶、滑动窗口。                                 |
| **熔断**     | Circuit Breaking         | 当依赖服务出现故障时,自动切断调用,防止故障扩散,并提供降级方案。                                                    |
| **会话保持** | Session Persistence      | 确保同一客户端的请求始终路由到同一台后端服务器,用于需要保持会话状态的场景。                                        |
| **健康检查** | Health Check             | 定期检查后端服务的健康状态,自动剔除故障节点,保证流量只发送到健康的服务实例。                                       |
| **灰度发布** | Canary Release           | 将少量流量导到新版本,验证稳定性后逐步扩大比例,降低发布风险。                                                       |
| **WAF**      | Web Application Firewall | Web应用防火墙,防护SQL注入、XSS、CC攻击等Web安全威胁。                                                              |
| **CDN**      | Content Delivery Network | 内容分发网络,在全球部署边缘节点,加速静态资源访问。                                                                 |