📚 课程目录第3章 TLS终止的架构设计

3. TLS终止的架构设计：四种主流模式

聊完TLS终止的基本原理，咱们来看看它在实际架构中怎么落地。我这些年经手过的项目，TLS终止的部署方式基本就四种：反向代理、负载均衡器、API网关、Sidecar代理。每种模式都有自己的脾气，选错了后面改起来挺痛苦的。

核心观点：TLS终止的位置决定了你的安全边界、运维复杂度和性能瓶颈。没有银弹，只有权衡。

3.1 反向代理模式：最朴素的方案

反向代理模式，说白了就是在业务服务器前面挡一层。Nginx、HAProxy、Caddy 这些老面孔，干的就是这个活。客户端连过来走 HTTPS，反向代理把证书一卸，转成 HTTP 扔给后端。

我个人习惯在中小型项目里用这个模式。为什么？因为简单。你想想看，证书只需要放在反向代理上，后端服务根本不用操心 TLS 的事。我有个客户，团队就五六个人，后端全是 Python Flask 写的，让他们在每个服务里配证书？那不得疯掉。

我的经验：用 Nginx 做 TLS 终止时，记得把 ssl_session_cache 开大一点。我曾经遇到一个电商项目，白天高峰期 Nginx 的 CPU 直接飙到 90%，查了半天发现是 session cache 太小，每次握手都要重新算。改成 shared:SSL:50m 后，CPU 直接降到 30%。

# Nginx TLS终止典型配置
server {
    listen 443 ssl http2;
    server_name api.example.com;
    
    ssl_certificate     /etc/nginx/certs/fullchain.pem;
    ssl_certificate_key /etc/nginx/certs/privkey.pem;
    ssl_session_cache   shared:SSL:50m;
    ssl_session_timeout 1h;
    
    location / {
        proxy_pass http://backend:8080;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

注意：反向代理模式有个坑——后端服务收到的都是 HTTP 请求。如果你的应用逻辑里依赖 HTTPS 协议判断（比如某些 OAuth 回调），必须通过 X-Forwarded-Proto 头把原始协议传过去。我曾经见过一个支付回调因为没传这个头，一直报协议不匹配，排查了整整两天。

3.2 负载均衡器模式：硬件的威力

当流量大到一定程度，软件反向代理就扛不住了。这时候就该负载均衡器上场。我说的不是 Nginx 那种软负载，而是 F5、AWS NLB、Citrix ADC 这些专用设备或云服务。

负载均衡器做 TLS 终止，最大的优势是性能。硬件级的 TLS 加速芯片，处理百万级并发握手跟玩似的。我记得有个金融客户，每秒要处理 5 万笔交易，用 Nginx 跑了 8 台机器还经常超时。换成 F5 后，两台设备搞定，延迟还降了一半。

特性	软件反向代理	硬件负载均衡器
TLS 吞吐量	受 CPU 限制，通常 1-5 Gbps	硬件加速，可达 40+ Gbps
并发连接数	几万到几十万	数百万到千万级
证书管理	手动或脚本管理	HSM 集成，自动轮换
成本	免费或低价	几万到几十万
灵活性	高，可定制	中，受厂商限制

不过话说回来，硬件负载均衡器也不是万能的。它的配置通常很死板，想加个自定义逻辑？得看厂商支不支持。我建议只有在真正需要那个吞吐量的时候才上硬件，否则用软件方案更灵活。

3.3 API网关模式：微服务的守门人

微服务架构火起来之后，API 网关成了 TLS 终止的热门选择。Kong、APISIX、Traefik 这些网关，不光能做 TLS 终止，还能顺带做路由、限流、认证、日志收集。说白了，它把反向代理的能力又往上提了一层。

我个人特别喜欢 API 网关模式的一点是：它能让每个微服务团队专注于业务逻辑，安全策略统一由网关层管控。你想想看，几十个微服务，如果每个都要配 TLS、配认证、配限流，运维同学不得累死？

# Kong 网关 TLS终止 + 路由配置示例
# 启用 TLS 终止
services:
  - name: user-service
    url: http://user-svc:8080
    routes:
      - name: user-route
        paths:
          - /api/v1/users
    plugins:
      - name: rate-limiting
        config:
          minute: 100
      - name: key-auth

# 监听 HTTPS
nginx:
  proxy_listen: 0.0.0.0:8443 ssl
  ssl_cert: /etc/kong/certs/fullchain.pem
  ssl_key: /etc/kong/certs/privkey.pem

关键点：API 网关做 TLS 终止时，要注意网关本身成为性能瓶颈。我见过一个案例，网关层没做水平扩展，所有流量挤在一台机器上，TLS 握手就把 CPU 吃满了。解决方案很简单——网关前面再加一层四层负载均衡做流量分发。

3.4 Sidecar代理模式：服务网格的终极形态

最后这个模式，是近几年云原生领域最火的。Sidecar 代理，说白了就是给每个服务实例旁边塞一个代理容器，专门处理进出流量。Envoy、Linkerd 是典型代表。TLS 终止发生在 Sidecar 上，对业务容器完全透明。

这个模式的好处是什么？零信任安全。每个服务之间的通信都强制走 mTLS，不需要改一行代码。我曾经帮一个客户从传统架构迁移到 Istio，几百个服务，原来配 TLS 配了三个月。用了 Sidecar 模式后，两周搞定，而且每个服务之间的通信都自动加密了。

避坑指南：我曾经在 Istio 里踩过一个坑——Sidecar 的 TLS 终止默认用的是自签名证书，虽然能加密，但没法做双向认证。后来改成集成 cert-manager 自动签发证书，才真正实现 mTLS。记住，Sidecar 模式的价值在于零信任，不是简单的加密。

# Istio Sidecar mTLS 配置示例
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT  # 强制所有服务间通信使用 mTLS
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: default
  namespace: istio-system
spec:
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL  # 使用 Istio 管理的 mTLS

注意：Sidecar 模式虽然强大，但资源开销不小。每个 Sidecar 代理至少占用 50-100MB 内存，如果你的集群有 1000 个 Pod，光 Sidecar 就要吃掉 50-100GB 内存。我建议在决定上 Sidecar 之前，先评估一下你的基础设施能不能扛得住这个开销。

3.5 如何选择？一张表说清楚

说了这么多，到底该选哪个？我整理了一个决策表，你可以根据实际情况对号入座。

场景	推荐模式	理由
单体应用，<10个后端服务	反向代理	简单，运维成本低
高并发，>10万 QPS	负载均衡器	硬件加速，性能有保障
微服务，>20个服务	API网关	统一管控，插件丰富
云原生，K8s 环境	Sidecar代理	零信任，透明加密
混合场景，既有旧系统又有新服务	API网关 + Sidecar	网关处理外部流量，Sidecar 处理内部通信

最后说一句，架构设计没有标准答案。我见过用 Nginx 扛住百万 QPS 的狠人，也见过用 F5 只跑几千 QPS 的土豪。关键是你得清楚自己的场景——流量多大？团队多强？预算多少？想清楚这些，选哪个模式都不会错。