企业级后端架构全景

从用户浏览器到数据库，完整请求链路上的 20 个基础设施组件，逐个拆解。

总图

用户浏览器
    │
    ▼
┌─────────────────────────────────────────────────────────────────┐
│  1. DNS             域名 → IP                                    │
│  2. CDN             静态资源缓存、边缘加速                         │
│  3. WAF             Web 应用防火墙                                │
│  4. Nginx           边缘负载均衡 & SSL 终结                       │
│  5. Kong            API 网关：鉴权、限流、路由、日志                │
│  6. K8s             容器编排：部署、扩缩容、服务发现                │
│  7. FastAPI         应用代码                                      │
│  8. gRPC            微服务间通信                                  │
│  9. Redis           缓存 & 分布式锁 & 限流                        │
│ 10. PostgreSQL      主数据库（主从架构）                           │
│ 11. Kafka           异步消息队列                                  │
│ 12. Celery          异步任务（邮件、报告、AI 推理）                 │
│ 13. Elasticsearch   全文搜索 & 日志存储                           │
│ 14. Prometheus      指标采集 & 告警                               │
│ 15. Jaeger          分布式链路追踪                                │
│ 16. ELK / Loki      日志聚合                                      │
│ 17. Vault           密钥管理                                      │
│ 18. GitLab CI       持续集成 / 持续部署                            │
│ 19. Docker          容器镜像                                      │
│ 20. Helm            K8s 包管理器                                  │
└─────────────────────────────────────────────────────────────────┘

1. DNS — 互联网的电话簿

把 api.example.com 翻译成 IP 地址 13.225.142.89。人记不住 IP，浏览器也记不住域名。

解析流程

浏览器: "api.example.com 在哪？"
   ├── 本地 DNS 缓存   → 没有
   ├── 路由器          → 没有
   ├── 运营商 DNS      → 没有
   ├── 根 DNS          → "去找 .com"
   ├── .com DNS        → "去找 example.com"
   └── example.com DNS → "13.225.142.89，别名指向 CDN"

企业用法

智能解析： 北京用户解析到北京机房，纽约用户到纽约机房
故障切换： 主 IP 挂了自动切备用 IP
权重负载： 60% 流量去 A 机房，40% 去 B 机房

产品： Route53（AWS）、Cloud DNS（GCP）、DNSPod（腾讯）

2. CDN — 内容分发网络

把静态文件（图片、JS、CSS、视频）缓存到离用户最近的边缘节点，加速访问。

为什么需要

用户在美国，服务器在中国，延迟 200ms。CDN 在洛杉矶有节点，延迟 10ms。

无 CDN:  用户(纽约) ───200ms──▶ 服务器(上海) ───200ms──▶ 用户    总耗时 400ms

有 CDN:  用户(纽约) ───10ms──▶ CDN节点(纽约)
                                ├── 缓存命中 → 直接返回    总耗时 20ms
                                └── 未命中   → 回源一次，之后都走缓存

企业用法

静态资源全部走 CDN；动态请求利用 CDN 优质网络线路回源；Cloudflare Workers、Lambda@Edge 在边缘跑轻量逻辑。

产品： CloudFront（AWS）、Cloudflare、阿里云 CDN

3. WAF — Web 应用防火墙

请求到达服务器之前，拦截恶意请求。公网暴露 10 分钟 就会被自动扫描。

检测规则示例

攻击类型	恶意请求样例	处置
SQL 注入	`?id=1' OR '1'='1`	403
XSS	`<script>alert(1)</script>`	403
路径穿越	`../../etc/passwd`	403
CC 攻击	同一 IP 每秒 500 次	429
恶意爬虫	`User-Agent: scrapy`	403
漏洞扫描	请求 `/wp-admin`、`/.env`	403

厂商自动更新规则库，也支持自定义规则（如管理后台只允许公司 IP 访问）。

产品： AWS WAF、Cloudflare WAF、阿里云 WAF

4. Nginx — 边缘负载均衡 & SSL 终结

站在所有服务器前面，负责接客、分配任务、HTTPS 加解密。

为什么需要

10 台服务器，用户不知道该连哪台 → 负载均衡
HTTPS 加解密吃 CPU，每台应用服务器都做浪费 → SSL 终结（Nginx 解密后内网走 HTTP）
小文件多，每次建 TCP 连接太慢 → 连接复用（keepalive）
拒绝超大请求体 → Nginx 层就拦截

请求处理流程

SSL 握手 — 证书加密通信，可选双向认证
读请求头 — 匹配 Host、追加 X-Forwarded-For 真实 IP、透传 X-Trace-Id
选后端 — least_conn（最空闲）、ip_hash（同用户固定）、round_robin（轮流）
转发 — 后端长连接复用，5 秒超时断开，缓冲收齐再发给客户端
特殊处理 — SSE/WebSocket 关闭缓冲；静态文件 Nginx 自己返；后端全挂回 502

5. Kong — API 网关

所有 API 请求的统一入口。在业务代码之前，先把鉴权、限流、日志处理完。

Nginx vs Kong

Nginx 是网络层（管 IP、端口、SSL、TCP 连接），Kong 是应用层（管 API 路由、鉴权、限流、日志）。类比：Nginx 是机场安检（查登机牌），Kong 是航司柜台（查票是否有效、安排登机口）。

请求处理阶段

解析 — 双向 TLS 验证客户端证书
改写 — 去 URL 前缀、注入 X-User-Id / X-Trace-Id、重定向
鉴权 & 控制 ← 核心
- JWT 验证：Token 有效？过期？
- 限流：用户 1 分钟发了多少次？
- ACL：有权限调这个接口吗？
- 请求校验、IP 黑白名单
- 任一失败 → 直接 401 / 429 / 403，不到后端
转发 — Route → Service → 后端 Pod，健康检查，失败重试 3 次
响应 — 修改响应头，聚合多后端响应
日志 — 每条请求记日志 → ELK，上报 Prometheus

6. Kubernetes (K8s) — 容器编排平台

管理成百上千个容器的"操作系统"。你说"要 3 个实例"，它自动找机器部署、挂了重启、流量大了加实例。

为什么需要

没有 K8s： 凌晨 3 点服务器挂了 → 手动发现 → 找替代机器 → 重新部署 8 个服务 → 配 IP → 天亮了
有 K8s： 自动检测 Pod 挂了 → 另一台机器重启 → 30 秒恢复 → 你在睡觉

六大核心概念

概念	做什么	类比
Pod	最小运行单元，装一个或多个容器	货船上的集装箱
Deployment	管 Pod 的控制器：副本数、滚动升级	船队调度中心
Service	给 Pod 分配固定虚拟 IP（Pod IP 常变）	快递柜（地址不变）
Ingress	HTTP 路由规则	写字楼指路牌
ConfigMap	共享配置：数据库地址、日志级别	公告栏
Secret	加密存储：数据库密码、API Key	保险柜

Deployment 示例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: order-service
  template:
    spec:
      containers:
      - name: order-service
        image: registry.example.com/order-service:v1.2.3
        ports:
        - containerPort: 8080
        env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: db-secret
              key: url
        resources:
          requests:   { cpu: 500m,  memory: 512Mi }
          limits:     { cpu: 2000m, memory: 2Gi   }
        livenessProbe:
          httpGet:
            path: /health/live
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5
        readinessProbe:
          httpGet:
            path: /health/ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 3

7. FastAPI — 业务应用层

所有业务逻辑的承载层。前面 6 层和后面 13 层，都是为它服务的。这是你真正写代码的地方。

8. gRPC — 微服务间 RPC 通信

服务间通信的"高速专用电话线"。

HTTP/JSON vs gRPC

维度	HTTP/JSON	gRPC + Protobuf
消息体积	~40 字节	~15 字节（省 60%）
传输协议	HTTP/1.1	HTTP/2 多路复用
类型安全	无	IDL 编译时检查
流式传输	不支持	服务端流、双向流

Proto 定义 = 服务契约

service OrderService {
  rpc CreateOrder(CreateOrderReq) returns (CreateOrderResp);
  rpc StreamOrders(StreamReq) returns (stream Order);
  rpc Chat(stream Message) returns (stream Message);
}

message CreateOrderReq {
  int64 user_id = 1;
  repeated Item items = 2;
  string address_id = 3;
}

Python 实现

# 服务端
class OrderServiceServicer(order_pb2_grpc.OrderServiceServicer):
    async def CreateOrder(self, request, context):
        order = await create_order(request.user_id, request.items)
        return CreateOrderResp(order_id=order.id)

# 客户端 — 类型安全，IDE 自动补全
async with grpc.aio.insecure_channel('order-service:8080') as channel:
    stub = OrderServiceStub(channel)
    response = await stub.CreateOrder(CreateOrderReq(user_id=123, items=[...]))

9. Redis — 内存数据库

极快的内存存储，读写微秒级。适合缓存、分布式锁、限流计数。

场景一：缓存

用户请求 → FastAPI → Redis 查缓存
                       ├── 命中 (1ms)       → 直接返回
                       └── 未命中            → 查 PostgreSQL (10ms)
                                             → 写回 Redis → 下次 1ms

场景二：分布式锁（防并发）

# 用户快速点两次"下单"，请求同时到达
SET order:lock:user123 "1" NX EX 10   # 请求 1 → 拿到锁
SET order:lock:user123 "1" NX EX 10   # 请求 2 → 失败 → "请勿重复下单"

场景三：限流计数

INCR user:123:rate:minute          # → 49
EXPIRE user:123:rate:minute 60     # 60 秒过期
49 < 100 → 放行    101 > 100 → 限流

企业部署用 Redis Cluster（多机分片，单点挂了数据不丢）。

10. PostgreSQL — 关系型数据库

所有"绝对不能丢"的数据都存这。订单、用户、消息——每一步持久化都在这里。

为什么不用 SQLite

维度	SQLite	PostgreSQL
并发写入	串行（单锁）	行级锁，高并发
数据量	GB 级	TB 级
连接	本地单文件	连接池 + 上千并发连接
网络	不支持	原生 TCP
特性	基础 SQL	JSON、全文搜索、地理空间、窗口函数

主从架构

        ┌──────────────┐
        │  主库 Primary │  ← 所有写 (INSERT/UPDATE/DELETE)
        │     读写       │
        └───────┬───────┘
                │ WAL 日志流复制（近乎实时）
       ┌────────┼────────┐
       ▼        ▼        ▼
 ┌─────────┐ ┌─────────┐ ┌─────────┐
 │ 从库 1   │ │ 从库 2   │ │ 从库 3   │  ← 所有读 (SELECT)
 │  只读    │ │  只读    │ │  只读    │
 └─────────┘ └─────────┘ └─────────┘

读写分离，主库压力小
主库挂了，从库自动升级为 Primary
读压力大了就加从库

11. Kafka — 分布式消息队列

服务间异步传话的"邮局"。生产者丢消息就走，消费者什么时候来取都行。

为什么需要

同步 RPC 的问题是 A 必须等 B 返回。但"订单支付成功 → 发短信 / 写数据仓库 / 更新报表"不需要等——并行异步处理。

发布-订阅模型

                      ┌───────────────┐
 Producer ───────────▶│     Kafka     │
 (订单服务)            │               │
 "订单已支付" ───────▶│ Topic:        │
                      │ order-events  │
                      │               │
                      │  Partition 0  │──▶ Consumer 1 发短信
                      │  Partition 1  │──▶ Consumer 2 实时报表
                      │  Partition 2  │──▶ Consumer 3 数据仓库
                      └───────────────┘

保证： 消息不丢（磁盘 + 多副本）、同 key 顺序处理、历史回放、单机每秒百万条。

12. Celery — 异步任务队列

耗时任务丢到后台慢慢做，API 立刻返回"正在处理"。

为什么需要

HTTP 响应必须快，但生成 PDF（3 秒）、AI 生成图片（10 秒）、发 10 万封邮件（30 分钟）——不能同步等。

工作流程

# FastAPI — 10ms 即刻返回
@router.post("/generate-report")
async def generate_report(req: ReportRequest):
    task = generate_report_task.delay(user_id=req.user_id, report_type=req.report_type)
    return {"task_id": task.id, "status": "processing"}

# Celery Worker — 另一台机器后台执行
@celery_app.task
def generate_report_task(user_id, report_type):
    data = fetch_data(user_id)
    pdf = render_pdf(data)
    upload_to_s3(pdf)
    send_email(user_id, "报告已生成", pdf_url)

架构

FastAPI ──▶ Redis/RabbitMQ ──▶ Celery Worker 1
                (消息中转)      Celery Worker 2
                               Celery Worker 3

13. Elasticsearch — 全文搜索引擎

Google 级别的搜索能力，同时兼任日志存储。

为什么不用 PostgreSQL LIKE

-- PG LIKE: 100 万条记录全表扫描 → 2 秒
SELECT * FROM products WHERE name LIKE '%手机壳%';

// ES match: 倒排索引 → 5ms
GET /products/_search
{ "query": { "match": { "name": "手机壳" } } }

还支持：模糊搜索（拼音也能搜到）、聚合分析、地理位置搜索。

ELK 三件套

组件	职责
Elasticsearch	存储 & 搜索
Logstash	收集、清洗、转发日志
Kibana	可视化查询界面

服务器日志 → Logstash (解析 JSON、过滤、补全字段) → Elasticsearch → Kibana 界面

14. Prometheus — 指标监控 & 告警

不看日志，看数字。每秒多少请求、P95 延迟多少、连接池用了多少。

工作原理

Prometheus 每 15 秒抓一次应用的 /metrics 端点：

http_requests_total{method="POST", path="/orders", status="200"} 15234
http_request_duration_seconds{quantile="0.95"}                    0.085
db_connection_pool_available                                       18
db_connection_pool_used                                             2

告警示例

P95 延迟 > 500ms 持续 5 分钟 → 飞书 / Slack / 短信
错误率 > 1% → 告警
连接池用满 → 预警
磁盘使用率 > 85% → 告警

15. Jaeger — 分布式链路追踪

一个请求过了 8 个微服务，每个花了多长时间？Jaeger 告诉你。

为什么需要

没有追踪： "下单很慢" → ssh 一台台翻日志 → 定位靠猜
有追踪： 搜 trace_id，一秒定位：

Nginx (1ms) ────▶ Kong (2ms) ────▶ Order Service (500ms!!)
                                        ├── Stock gRPC   (50ms)
                                        ├── Payment gRPC (400ms!!) ← 问题在这
                                        │    └── Stripe API (390ms)
                                        └── DB INSERT    (10ms)

trace_id 全链路透传

Nginx 生成 trace_id: "abc123"
  → Kong 透传
  → FastAPI 透传
  → gRPC Metadata 注入
  → SQL Comment 注入
Jaeger 收集所有 span → 拼出完整火焰图

16. ELK / Loki — 日志聚合

50 台服务器都在写日志，不能一台一台 ssh 去翻。

没聚合： ssh → grep → 没找到 → 换一台 → 30 分钟
有 ELK： Kibana 搜 trace_id:"abc123" → 自动聚合全部服务器 → 5 秒

17. Vault — 密钥管理

API Key、数据库密码、TLS 证书——不能泄密的东西，存在 Vault 里。不在代码里，不在环境变量里。

环境变量的问题

问题	Vault 做法
`kubectl exec` → `env` 就能看到密码	加密存储，磁盘上不可直接读
改 `.env` 要重启所有 Pod	动态轮换，应用通过 API 自动获取新密码
不知道谁用过密钥	完整审计日志
密钥长期不变	30 天自动轮换 / 按需签发临时凭证

18. GitLab CI / GitHub Actions — CI/CD

git push → 自动跑测试 → 自动构建镜像 → 自动部署。全程不需要人手。

git push
──────────────────────────────────────────
Stage 1  代码检查 (2min)     ruff | mypy | 安全扫描
Stage 2  测试     (5min)     pytest → 覆盖率 < 80% 则失败
Stage 3  构建镜像 (3min)     docker build → 推送 → 漏洞扫描
Stage 4  部署开发  (自动)     helm upgrade → K8s 滚动更新
Stage 5  部署生产  (人工审批)  金丝雀 10% → 观察 30min → 全量 100%

19. Docker — 容器

把应用、依赖、系统工具打包成"集装箱"，到哪都能跑。

没有 Docker： 开发机 Python 3.13 + macOS，服务器 Python 3.9 + Ubuntu → 报错
有 Docker： docker build && docker run → 开发 / 测试 / 生产完全一致

FROM python:3.13-slim
COPY . /app
RUN pip install -r requirements.txt
CMD ["python", "run.py"]

20. Helm — K8s 包管理器

K8s 的 apt install。把一堆 YAML 打包成可一键安装、升级、回滚的包。

为什么需要

一个服务 5 个 YAML（Deployment、Service、Ingress、ConfigMap、Secret）× 10 个服务 = 50 个文件。改个镜像版本要改 10 个文件。

Chart 结构

order-service/
├── Chart.yaml
├── values.yaml
└── templates/
    ├── deployment.yaml
    ├── service.yaml
    ├── ingress.yaml
    └── configmap.yaml

helm install order-service ./order-service -f production-values.yaml   # 部署
helm upgrade order-service ./order-service --set image.tag=v1.2.4      # 升级
helm rollback order-service 1                                          # 回滚

分层速览

层	组件	一句话
寻址	DNS	域名 → IP
加速	CDN	静态文件边缘缓存
安全	WAF	拦截恶意请求
接入	Nginx	负载均衡 + SSL 终结
网关	Kong	鉴权、限流、路由
编排	K8s	容器自动部署、扩缩容
应用	FastAPI	业务逻辑
通信	gRPC	服务间高性能 RPC
缓存	Redis	缓存、分布式锁、限流
存储	PostgreSQL	主数据库（主从架构）
消息	Kafka	异步事件流
任务	Celery	后台异步任务
搜索	Elasticsearch	全文搜索 + 日志存储
监控	Prometheus	指标采集 + 告警
追踪	Jaeger	分布式链路追踪
日志	ELK / Loki	集中式日志聚合
密钥	Vault	密钥加密存储与轮换
CI/CD	GitLab CI	自动测试、构建、部署
打包	Docker	应用容器化
部署	Helm	K8s 应用包管理

Sources

企业级后端架构全景