引言：一次请求要跨越多少道关卡？#

当你在浏览器中敲下回车，一个看似简单的 HTTP 请求，实际上要穿越 CDN、WAF、负载均衡、网关、微服务、中间件、数据库 等多达九层的精密协作。理解这条链路，是进行架构设计、性能调优与故障定位的基本功。

本文将以请求的视角，逐层拆解现代服务器架构的核心组件、职责边界与主流技术选型，并给出全链路速查表与排错清单。

flowchart TD
    A[用户浏览器 / App] -->|DNS 解析 CNAME| B[CDN 边缘节点]
    B -.->|静态命中直接返回| A
    B -->|静态未命中,回源| C[WAF Web 应用防火墙]
    C -->|进入云 VPC 内网| D[四层负载均衡 SLB / LVS]
    D --> E[七层接入网关 ALB / Nginx-Ingress / Higress]
    E --> F[API 网关集群]
    F --> G[业务微服务集群]
    G <-->|服务注册发现| H[Nacos / Eureka]
    G --> I[中间件层]
    I --> I1[Redis 缓存集群]
    I --> I2[Kafka / RocketMQ]
    I --> I3[配置中心 Nacos / Apollo]
    G --> J[持久化存储层]
    J --> J1[MySQL 主从集群]
    J --> J2[对象存储 OSS / S3]
    J --> J3[Elasticsearch]

第一层：CDN 边缘节点 —— 离用户最近的守门员#

用户的请求首先通过 DNS 的 CNAME 记录被调度到就近的 CDN 边缘节点。这一层承担着 静态缓存、DDoS 边缘清洗、TLS 卸载与动态加速 四大职责，是抵御流量洪峰的第一道缓冲带。

1
dig www.example.com CNAME +short
2
# 输出示例：
3
# www.example.com.cdn-provider.net.

第二层：WAF Web 应用防火墙 —— 七层安全的过滤网#

穿过 CDN 的回源流量，首先要接受 WAF 的安全审查。WAF 工作在应用层，专门识别业务层面的恶意请求，是进入 VPC 内网前的最后一道安全闸门。

1
[2024-11-29 14:23:01] BLOCK  rule=SQLi-034  src=203.0.113.88
2
uri=/api/user/detail?id=1' UNION SELECT password FROM users--
3
action=deny  status=403  upstream=-

第三层：四层负载均衡（SLB / LVS）—— 连接级别的调度大师#

流量进入云 VPC 后，首先到达四层负载均衡器。它工作在 传输层，不关心 HTTP 内容，只负责海量 TCP 连接的建立、调度与健康检查，是抗住大并发连接的基石[^1]。

第四层：七层接入网关 —— 流量的精细化分拣中心#

七层网关是 HTTP 请求的「分拣中心」，负责 证书管理、域名路由、限流、灰度发布与 URL 重写。在云原生体系中，通常由 Nginx-Ingress 或 Higress 承担这一角色。

1
server {
2
    listen 443 ssl;
3
    server_name api.example.com;
4

5
    ssl_certificate     /etc/ssl/api.example.com.pem;   # TLS 证书托管
6
    ssl_certificate_key /etc/ssl/api.example.com.key;
7

8
    location /api/v2/ {          # 灰度路由: v2 版本流量
9
        proxy_pass http://order-service-v2;
10
        proxy_set_header X-Gray-Tag "canary";
11
    }
12

13
    location /api/ {
14
        limit_req zone=api_limit burst=20 nodelay;      # 限流
15
        proxy_pass http://api-gateway-cluster;
16
    }
17

18
    rewrite ^/old-path/(.*)$ /api/v1/$1 permanent;      # URL 重写
19
}

四层与七层为何都要存在？

四层 LB 解决的是「连接能不能扛住」，七层网关解决的是「请求该往哪里去」。四层性能强但不理解业务，七层灵活但性能有限，两者是互补而非替代关系。

第五层：API 网关集群 —— 业务流量的统一入口#

接入网关之后，请求进入面向业务的 API 网关集群。如果说接入网关管「流量」，API 网关管的就是「接口」：鉴权、签名、熔断、协议转换与日志埋点都在这里完成。

第六层：业务微服务集群 —— 按业务域拆分的计算核心#

通过 API 网关校验后的请求，最终抵达业务微服务集群。服务按 业务域 拆分（用户、订单、商品、支付……），以 Pod 或 ECS 实例形态部署，通过注册中心完成服务发现。

1
spring:
2
  cloud:
3
    nacos:
4
      discovery:
5
        server-addr: nacos-cluster:8848   # 注册中心地址
6
        namespace: prod
7
        group: order-group                 # 订单域分组
8
  application:
9
    name: order-service

第七层：中间件层 —— 性能与解耦的加速器#

微服务并非直接访问数据库，而是先经过中间件层的缓冲与解耦。这一层是系统高并发能力的决定性因素。

1
public Order getOrder(String orderId) {
2
    // 1. 先查缓存
3
    Order cached = redisClient.get("order:" + orderId);
4
    if (cached != null) {
5
        return cached;                      // 缓存命中,直接返回
6
    }
7
    // 2. 缓存未命中,回源数据库
8
    Order order = orderMapper.selectById(orderId);
9
    if (order != null) {
10
        // 3. 回写缓存,设置过期时间防止雪崩
11
        redisClient.setex("order:" + orderId, 300 + jitter(), order);
12
    }
13
    return order;
14
}

1
# 秒杀瞬间: 峰值 50w QPS 打入 MQ
2
[PRODUCER] send order_create_msg  topic=seckill_order  cost=2ms  ✔
3
# 消费者以 5w QPS 匀速消费,数据库平稳无压力
4
[CONSUMER] consume batch=32  lag=120000  tps=50000

第八层：持久化存储层 —— 数据的最终归宿#

所有计算与缓存的尽头，是持久化存储。现代架构按数据特征选择不同的存储引擎，而非一套 MySQL 打天下。

返回链路：应答如何回到用户手中#

请求抵达存储层并完成处理后，应答将 沿原路逐层返回：微服务 → API 网关 → 接入网关 → 四层 LB → CDN → 用户。

但返回链路并非完全对称，有两个关键细节：

• 静态命中短路：若响应在 CDN 边缘命中缓存，链路在第一步就已终止，后续所有层级的流量为零——这正是 CDN 的价值所在。
• 逐层追加治理信息：返回途中各层会附加自己的处理逻辑，如网关补充响应头、CDN 写入缓存、WAF 记录审计日志。

flowchart LR
    S[存储层] --> M[中间件/微服务] --> G[API 网关] --> I[接入网关]
    I --> L[四层 LB] --> W[WAF] --> C[CDN] --> U[用户]
    C -.->|静态响应| U

全链路职责速查表#

一张表回顾整条链路的分层职责：

常见故障定位清单#

线上请求异常时，建议 沿链路自外向内逐层排查：

• CDN：缓存命中率是否骤降？边缘节点是否故障？
• WAF：是否存在误拦截（检查拦截日志与规则命中）？
• SLB：健康检查是否大面积异常摘除后端？
• 接入网关：是否正常路由流量?