Cổng gateway và Reverse Proxy

🎯 Câu hỏi cốt lõi

Trong kiến trúc Internet có mức độ truy cập đồng thời cao, làm thế nào để đưa lưu lượng truy cập đến đúng dịch vụ một cách an toàn và hiệu quả? Reverse proxy giải quyết vấn đề "phân phối lưu lượng", API gateway giải quyết vấn đề "xử lý yêu cầu". Bài viết này thông qua các ví dụ thực tế (lễ tân, hệ thống bảo vệ, định tuyến thông minh) giúp bạn hiểu sâu về triết lý thiết kế và thực hành kỹ thuật của gateway.

1. Tại sao cần "Gateway"?

1.1 Từ một ví dụ thực tế: Sự phát triển kiến trúc của một nền tảng thương mại điện tử

Một nền tảng thương mại điện tử đã gặp phải vấn đề kiến trúc nghiêm trọng khi tăng trưởng nhanh:

Tái hiện tình huống:

Giai đoạn 1: Để lộ trực tiếp dịch vụ
Client → Gọi trực tiếp User Service, Order Service, Payment Service...
         ↓
Vấn đề 1: IP dịch vụ bị lộ, tồn tại rủi ro bảo mật
Vấn đề 2: Không thể thống nhất xác thực, giới hạn lưu lượng
Vấn đề 3: Thêm dịch vụ mới cần sửa cấu hình client

⚠️ Vấn đề chết người khi để lộ trực tiếp

Rủi ro bảo mật: Tất cả IP dịch vụ bị lộ, dễ bị tấn công
Chức năng trùng lặp: Mỗi dịch vụ đều phải làm xác thực, giới hạn lưu lượng, ghi log
Khó mở rộng: Thêm dịch vụ mới phải sửa tất cả client
Hỗn loạn giao thức: Có cái dùng HTTP, có cái dùng gRPC, client phải thích ứng

Kiến trúc cải tiến (giới thiệu gateway):

Client → API Gateway (Nginx/Kong) → Internal Services
         ↓
      Xác thực thống nhất, giới hạn lưu lượng, định tuyến
         ↓
      Client chỉ cần biết địa chỉ gateway

✨ Hiệu quả sau khi cải tiến

An toàn: IP dịch vụ thực bị ẩn, chỉ có gateway tiếp xúc với bên ngoài
Tập trung chức năng: Xác thực, giới hạn lưu lượng, ghi log được xử lý tập trung tại gateway
Dễ mở rộng: Thêm dịch vụ mới chỉ cần cấu hình định tuyến tại gateway
Giao thức thống nhất: Đối ngoại HTTP, nội bộ có thể dùng gRPC

1.2 Ẩn dụ đời sống về Gateway

Lễ tân công ty

Hãy tưởng tượng bạn đến một công ty lớn:

Không có lễ tân: Khách tự tìm từng phòng ban, không biết ở đâu, công ty hỗn loạn
Có lễ tân: Khách đến lễ tân trước, lễ tân hỏi rõ mục đích, rồi hướng dẫn đến phòng ban tương ứng

API Gateway chính là "lễ tân" của hệ thống:

Reverse Proxy: Lễ tân, hướng dẫn khách đến đúng phòng ban
API Gateway: Lễ tân thông minh, còn có thể kiểm tra danh tính khách (xác thực), giới hạn số người truy cập (giới hạn lưu lượng)

👤

用户 (浏览器)

→

访问域名

🛡️

反向代理 (Nginx)

代理服务器

→

负载均衡

⚙️

后端服务器集群

Web1 | Web2 | Web3

🛡️ 反向代理特点

客户端无感知，只需要访问域名
隐藏真实服务器架构，统一对外接口
提供负载均衡、安全防护、SSL卸载等功能
典型代表：Nginx、HAProxy、AWS ELB

💡 典型使用场景

网站需要承载高并发流量（负载均衡）
统一HTTPS证书管理（SSL卸载）
防护DDoS攻击和SQL注入
灰度发布、A/B测试、蓝绿部署

🧠 记忆口诀

"反向代理 = 代理服务器" —— 客户端不知道真实服务器，只知道域名

2. Reverse Proxy là gì?

2.1 Forward Proxy và Reverse Proxy

🤔 Giải thích thuật ngữ

Forward Proxy:

Triển khai ở phía client
Thay mặt client truy cập tài nguyên bên ngoài
Ứng dụng điển hình: VPN, công cụ vượt tường lửa
Ví dụ: Trong mạng công ty, bạn truy cập Internet bên ngoài qua proxy

Reverse Proxy:

Triển khai ở phía máy chủ
Nhận yêu cầu từ client và chuyển tiếp đến dịch vụ nội bộ
Client chỉ biết proxy tồn tại, không biết máy chủ thực
Ví dụ: Nginx, HAProxy

Bảng so sánh:

Khía cạnh	Forward Proxy	Reverse Proxy
Vị trí triển khai	Phía client	Phía máy chủ
Đối tượng phục vụ	Client	Máy chủ
Ứng dụng điển hình	VPN, vượt tường lửa	Cân bằng tải, gateway
Tính minh bạch	Máy chủ thấy IP proxy	Client thấy IP proxy
Mục đích	Ẩn client thực, tăng tốc truy cập	Ẩn máy chủ thực, cân bằng tải

2.2 Giá trị cốt lõi của Reverse Proxy

Giá trị 1: Cân bằng tải

Phân phối lưu lượng đến nhiều máy chủ backend, tránh quá tải điểm đơn.

Client
  ↓
Nginx (Reverse Proxy)
  ↓
┌─────────┬─────────┬─────────┐
│ Server 1 │ Server 2 │ Server 3 │
└─────────┴─────────┴─────────┘

Giá trị 2: Bảo vệ an ninh

Ẩn IP máy chủ thực, ngăn chặn tấn công trực tiếp. Thực hiện bảo vệ an ninh tập trung tại tầng proxy.

Client → Chỉ thấy IP của Nginx
Máy chủ thực → Chỉ trong mạng nội bộ, bên ngoài không thể truy cập trực tiếp

Giá trị 3: SSL Termination

Xử lý mã hóa/giải mã HTTPS tại tầng proxy, dịch vụ backend dùng HTTP, giảm chi phí tính toán phía backend.

HTTPS Client → Nginx (mã hóa/giải mã) → HTTP Backend Service
                   ↑
              Điểm kết thúc SSL

3. Nginx: Tại sao có thể chịu được hàng triệu kết nối đồng thời?

3.1 Mô hình tiến trình Master-Worker

Nginx sử dụng kiến trúc đa tiến trình, không phải đa luồng:

Master Process (Quản lý):

Chịu trách nhiệm đọc và xác thực tệp cấu hình
Quản lý Worker Process (khởi động, dừng, tải lại)
Không xử lý yêu cầu cụ thể

Worker Process (Người làm việc):

Thực tế xử lý yêu cầu HTTP
Mỗi Worker là tiến trình độc lập, cách ly với nhau
Số lượng thường được đặt bằng số lõi CPU, tránh chi phí chuyển ngữ cảnh

💡 Ưu điểm

Cách ly tốt: Một Worker bị crash, không ảnh hưởng đến Worker khác
Tận dụng đa lõi: Mỗi Worker chạy độc lập
Tránh phức tạp đa luồng: Không cần xử lý vấn đề khóa, cạnh tranh

3.2 Hướng sự kiện + Bất đồng bộ không chặn

Đây là bí mật cốt lõi cho hiệu năng cao của Nginx:

Apache truyền thống (mô hình đa tiến trình/luồng):

Một kết nối = Một tiến trình/luồng
Số lượng đồng thời bị giới hạn bởi số tiến trình/luồng hệ thống
Khi có nhiều kết nối, chi phí chuyển tiến trình rất lớn

Nginx (mô hình hướng sự kiện):

Sử dụng cơ chế I/O multiplexing hiệu quả như epoll (Linux) / kqueue (macOS)
Một Worker Process có thể xử lý đồng thời hàng chục nghìn kết nối
Khi kết nối không có dữ liệu, không chiếm CPU; khi có dữ liệu mới, được đánh thức qua thông báo sự kiện

Ẩn dụ đời sống

Apache: Nhà hàng mỗi khách một phục vụ (tiến trình), khách đông cần nhiều phục vụ
Nginx: Một siêu phục vụ, phục vụ đồng thời tất cả khách, ai cần phục vụ thì đến chỗ người đó, thay vì đứng mãi bên cạnh một khách

Nginx 进程架构图

👑

Master 进程

管理所有 Worker，负责配置加载、平滑升级

4 个 Worker

⚙️

Worker 1

处理 0 请求

⚙️

Worker 2

处理 0 请求

⚙️

Worker 3

处理 0 请求

⚙️

Worker 4

处理 0 请求

📡 epoll (Linux) / kqueue (macOS)

事件驱动：一个 Worker 同时处理数万个连接

传统 Apache

一个连接 = 一个进程/线程

❌ C10K 问题

Nginx

事件驱动 + 异步非阻塞

✅ 百万并发

🎮 模拟请求处理

💡 生产环境建议

Worker 数量 = CPU 核心数（通常设置为 auto，让 Nginx 自动检测）
太多了上下文切换开销大，太少了无法利用多核性能。

4. API Gateway là gì?

4.1 Tại sao cần API Gateway?

Hãy tưởng tượng một hệ thống không có gateway:

Client cần biết địa chỉ của nhiều dịch vụ (User Service, Order Service, Payment Service...)
Mỗi dịch vụ đều phải tự làm xác thực, giới hạn lưu lượng, ghi log
Giao thức không thống nhất, có cái dùng HTTP, có cái dùng gRPC
Khi nâng cấp dịch vụ, client cũng phải thay đổi theo

⚠️ Vấn đề khi không có gateway

Client phức tạp: Cần cấu hình nhiều địa chỉ dịch vụ
Chức năng trùng lặp: Mỗi dịch vụ phải triển khai xác thực, giới hạn lưu lượng
Hỗn loạn giao thức: Client phải thích ứng nhiều giao thức
Khó nâng cấp: Nâng cấp dịch vụ, client cũng phải thay đổi

Sau khi có API Gateway:

Client chỉ cần biết địa chỉ gateway, gateway chịu trách nhiệm định tuyến đến đúng dịch vụ
Xác thực, giới hạn lưu lượng, ghi log và các logic xuyên suốt được xử lý tập trung tại gateway
Gateway có thể chuyển đổi giao thức, đối ngoại thống nhất HTTP
Nâng cấp dịch vụ backend chỉ cần thay đổi cấu hình gateway, client không cảm nhận được

客户端 (来访者)

📱 App

💻 Web

🔧 第三方

⬇️ 统一入口

🚪 API 网关 (前台)

🔐身份认证

⚡限流熔断

🧭路由转发

🔄协议转换

⬇️ 分发请求

⚙️ 后端服务 (各个部门)

👤

用户服务

/api/users

📦

订单服务

/api/orders

💳

支付服务

/api/pay

🔐身份认证

统一校验用户身份，无需每个后端服务都写登录逻辑。支持 JWT、OAuth2、API Key 等多种认证方式。

💡 实际场景

用户请求携带 JWT Token，网关校验签名和过期时间，通过后把用户ID添加到请求头转发给后端服务。

🤔 没有网关 vs 有网关的区别

功能需求	没有网关 (直接访问)	有 API 网关
身份认证	每个服务都要写一遍登录校验	✅ 统一在网关层校验 JWT
限流保护	每个服务自己实现限流	✅ 网关统一限流，保护后端
协议转换	HTTP、gRPC、WebSocket各自处理	✅ 网关统一对外暴露 HTTP
灰度发布	需要改负载均衡器配置	✅ 网关层按 Header 路由

4.2 Chức năng cốt lõi của API Gateway

Chức năng	Mô tả	Tình huống điển hình
Định tuyến	Chuyển tiếp yêu cầu đến các dịch vụ khác nhau dựa trên URL, Header	`/api/users` → User Service, `/api/orders` → Order Service
Cân bằng tải	Khi một dịch vụ có nhiều instance, phân bổ lưu lượng	User Service có 3 instance, phân phối yêu cầu theo vòng tròn
Xác thực	Kiểm tra JWT, OAuth Token tập trung	Người dùng chưa đăng nhập không thể truy cập `/api/admin`
Giới hạn lưu lượng & Ngắt mạch	Kiểm soát giới hạn lưu lượng, ngăn dịch vụ bị quá tải	Tối đa 1000 yêu cầu/giây, vượt quá trả về 429
Chuyển đổi giao thức	Đối ngoại HTTP, nội bộ chuyển gRPC	Client dùng HTTP, gateway chuyển gRPC gọi dịch vụ nội bộ
Canary Release	Dựa trên Header hoặc tỷ lệ, dẫn một phần lưu lượng đến phiên bản mới	5% người dùng trải nghiệm phiên bản mới, 95% dùng phiên bản cũ
Ghi log & Giám sát	Ghi log yêu cầu tập trung, dễ phân tích và xử lý sự cố	Ghi lại thời gian phản hồi, mã trạng thái, kích thước phản hồi của mỗi yêu cầu

5. Gateway Hands-on: Làm sao xây dựng kiến trúc gateway hoàn chỉnh?

5.1 Sơ đồ kiến trúc đầy đủ

┌───────────────────────────────────────────────────────────────────────┐
│                           Client (Browser/APP)                               │
└───────────────────────────┬─────────────────────────────────────────┘
                                │ HTTPS
                                ▼
┌───────────────────────────────────────────────────────────────────────┐
│                        Tầng ngoài: CDN + WAF                                  │
│  ┌─────────────────────────────────────────────────────────────┐  │
│  │  CDN (Content Delivery Network)                                        │  │
│  │  - Cache tài nguyên tĩnh (ảnh, CSS, JS)                           │  │
│  │  - Truy cập gần nhất, giảm độ trễ                                   │  │
│  └───────────────────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  WAF (Web Application Firewall)                                     │  │
│  │  - Phòng chống SQL injection, XSS                                │  │
│  │  - Chặn Bot độc hại, crawler                                  │  │
│  │  - Phòng chống tấn công CC                              │  │
│  └───────────────────────────────────────────────────────────────┘  │
└───────────────────────────────────────────────────────────────────────┘
                                │
                                ▼
┌───────────────────────────────────────────────────────────────────────┐
│                     Tầng giữa: API Gateway (Nginx/Kong)                      │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  Tầng 1: SSL Termination + Bảo vệ an ninh                              │  │
│  │  - HTTPS / TLS 1.3                                        │  │
│  │  - HSTS, Security Response Headers                                        │  │
│  └───────────────────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  Tầng 2: Xác thực và ủy quyền                                      │  │
│  │  - Xác thực JWT Token                                         │  │
│  │  - Tích hợp OAuth 2.0 / SSO                                     │  │
│  │  - Quản lý API Key                                         │  │
│  │  - Kiểm tra quyền (RBAC)                                        │  │
│  └───────────────────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  Tầng 3: Kiểm soát lưu lượng                                        │  │
│  │  - Giới hạn lưu lượng - Thuật toán Token Bucket/Leaky Bucket                             │  │
│  │  - Ngắt mạch - Ngăn chặn lan truyền lỗi                                 │  │
│  │  - Giảm cấp - Phương án dự phòng khi dịch vụ không khả dụng                         │  │
│  │  - Canary Release - Phân bổ lưu lượng theo tỷ lệ                          │  │
│  └───────────────────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  Tầng 4: Định tuyến và Cân bằng tải                                    │  │
│  │  - Định tuyến theo đường dẫn - Path-based Routing)                          │  │
│  │  - Định tuyến theo tên miền - Host-based Routing)                           │  │
│  │  - Định tuyến theo Header - Header-based Routing)                             │  │
│  │  - Thuật toán cân bằng tải - Round Robin/Weighted/Least Connections/IP Hash)             │  │
│  │  - Tích hợp Service Discovery)                        │  │
│  └───────────────────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  Tầng 5: Chuyển đổi giao thức và Xử lý dữ liệu                                 │  │
│  │  - SSL Termination - HTTPS ↔ HTTP)                                   │  │
│  │  - Chuyển đổi giao thức - HTTP ↔ gRPC / WebSocket)                         │  │
│  │  - Chuyển đổi request/response - JSON ↔ XML)                               │  │
│  │  - Nén dữ liệu - Gzip / Brotli)                                   │  │
│  │  - Cache - Cho tài nguyên tĩnh và API response                          │  │
│  └───────────────────────────────────────────────────────────────┘  │
└───────────────────────────────────────────────────────────────────────┘
                                │
                                ▼
┌───────────────────────────────────────────────────────────────────────┐
│                        Tầng trong: Cụm Microservices                             │
│  ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐      │
│  │  User Svc    │ │  Order Svc  │ │ Product Svc │ │ Payment Svc │      │
│  │             │ │             │ │             │ │             │      │
│  └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘      │
│         │                │                │                │               │
│         └────────────────┴────────────────┴────────────────┘               │
│                                       │                              │
│                    Service Discovery / etcd)                          │
│                    - Đăng ký và khám phá dịch vụ                                      │
│                    - Health check                                              │
│                    - Lưu trữ cấu hình KV                                              │
└───────────────────────────────────────────────────────────────────────┘

5.2 Định tuyến và Cân bằng tải

Một trong những trách nhiệm cốt lõi của gateway là đưa yêu cầu đến đúng nơi. Điều này liên quan đến hai khả năng then chốt: định tuyến (đến máy chủ nào) và cân bằng tải (phân bổ lưu lượng ra sao).

Quy tắc định tuyến: Từ URL đến dịch vụ

Hãy tưởng tượng một hệ thống thương mại điện tử, các URL khác nhau tương ứng với các dịch vụ khác nhau:

/api/users/* → User Service
/api/orders/* → Order Service
/api/products/* → Product Service
/api/pay/* → Payment Service

Ví dụ cấu hình Nginx:

nginx

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

    # User Service
    location /api/users/ {
        proxy_pass http://user-service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # Order Service
    location /api/orders/ {
        proxy_pass http://order-service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # Product Service
    location /api/products/ {
        proxy_pass http://product-service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # Payment Service (yêu cầu bảo mật cao hơn)
    location /api/pay/ {
        # Giới hạn truy cập 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;
    }
}

Cân bằng tải: So sánh bốn chiến lược

Khi cùng một dịch vụ có nhiều instance, làm thế nào để chọn?

Chiến lược	Nguyên lý	Tình huống phù hợp	Ưu điểm	Nhược điểm
Round Robin	Phân bổ lần lượt cho từng máy chủ	Các máy chủ có hiệu năng tương đương	Đơn giản, công bằng	Không xét tải hiện tại của máy chủ
Weighted Round Robin	Phân bổ theo tỷ lệ trọng số, trọng số cao được phân bổ nhiều hơn	Các máy chủ có hiệu năng không đồng đều	Tận dụng tối đa máy chủ hiệu năng cao	Cần thiết lập trọng số hợp lý
Least Connections	Phân bổ cho máy chủ có ít kết nối nhất	Kết nối dài, video streaming	Thích ứng động với thay đổi tải	Cần thống kê số kết nối theo thời gian thực
IP Hash	Tính hash dựa trên IP client, cùng IP luôn đến cùng một máy chủ	Cần duy trì session	Đảm bảo tính nhất quán của session	IP nào có lưu lượng lớn sẽ gây áp lực điểm đơn

Ví dụ cấu hình Nginx:

nginx

# Weighted Round Robin
upstream backend_weighted {
    server 10.0.1.10:8080 weight=3;  # Hiệu năng tốt, chịu nhiều lưu lượng hơn
    server 10.0.1.11:8080 weight=2;
    server 10.0.1.12:8080 weight=1;  # Hiệu năng kém, chịu ít lưu lượng hơn
}

# Least Connections
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 Hash (duy trì session)
upstream backend_ip_hash {
    ip_hash;
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080;
}

选择负载均衡策略

🎮 负载均衡模拟器

💡

轮询 - 挨个分发，雨露均沾

按照服务器列表的顺序，依次将请求分配给每台服务器。就像银行叫号，1号窗口完事了到2号，2号完事了到3号，轮着来。

🏢 后端服务器集群

服务器数量:4 台

🖥️

Server-A

47%

请求数:0

权重:3

最近请求:

🖥️

Server-B

12%

请求数:0

权重:2

最近请求:

🖥️

Server-C

38%

请求数:0

权重:4

最近请求:

🖥️

Server-D

48%

请求数:0

权重:1

最近请求:

📨 请求队列

总请求: 0待处理: 0

📊 负载分布统计

36%

平均负载

48%

最高负载

14.5

负载标准差

Server-D

最忙服务器

6. Bảo mật Gateway: Làm thế nào bảo vệ cánh cổng hệ thống?

6.1 Xác thực và Ủy quyền

Cách truyền thống (mỗi dịch vụ tự xác thực):

User Service, Order Service, Payment Service... mỗi cái đều phải kiểm tra JWT
Code trùng lặp, khó bảo trì
Secret phân tán ở nhiều dịch vụ, rủi ro lộ thông tin cao

Xác thực tập trung tại Gateway:

Client mang Token truy cập gateway
Gateway kiểm tra tính hợp lệ của Token (chữ ký, thời gian hết hạn)
Sau khi kiểm tra thành công, thêm thông tin người dùng (như user_id) vào request header, chuyển tiếp đến dịch vụ backend
Dịch vụ backend không cần kiểm tra, lấy thông tin người dùng trực tiếp từ Header

💡 Tư tưởng cốt lõi

Xác thực ở Gateway, ủy quyền ở Service:

Xác thực: Bạn là ai? (Kiểm tra Token, lấy danh tính người dùng)
Ủy quyền: Bạn có thể làm gì? (Dựa trên vai trò người dùng để xác định quyền hạn)

Giống như lễ tân công ty: lễ tân xác thực danh tính của bạn (CMND), nhưng quyền hạn cụ thể do từng phòng ban xác định.

JWT (JSON Web Token) 认证流程

用户

输入用户名密码，点击登录

↓

网关/Nginx

转发登录请求到认证服务

↓

认证服务

验证密码，生成 JWT Token（包含 Header、Payload、Signature）

↓

用户/客户端

保存 Token（LocalStorage 或 Cookie）

↓

后续请求

在 HTTP Header 中携带: Authorization: Bearer <Token>

↓

网关/Nginx

校验 Token 签名和过期时间，通过后转发请求

↓

后端服务

从 Token 中解析用户信息，处理业务逻辑

🔑 JWT Token 结构（Base64编码）

PAYLOAD

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ

{ "sub": "1234567890", "name": "John Doe", "iat": 1516239022 }

SIGNATURE

SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

HMACSHA256(base64Url(header) + "." + base64Url(payload), secret)

🛠️ 三种方案实现对比

对比维度	Session + Cookie	JWT	OAuth2.0
存储位置	服务端存储 Session，客户端存 Cookie	客户端存储 Token，服务端无状态	授权服务器存储，客户端存 Access Token
扩展性	❌ 需要共享 Session，扩展复杂	✅ 无状态，易于水平扩展	✅ 分布式架构，支持大规模系统
安全性	⚠️ Cookie 可能被窃取，需要 CSRF 防护	⚠️ Token 泄露风险，需 HTTPS + 短期有效	✅ 行业最佳实践，支持多种安全机制
实现复杂度	🟢 简单，开箱即用	🟡 中等，需要 Token 管理	🔴 复杂，需要授权服务器
适用场景	传统 Web 应用、后台管理系统	SPA、移动端 API、微服务	第三方登录、开放平台、SSO

🔒 网关层认证最佳实践

统一在网关层验证

不要在每个微服务里重复写认证逻辑，统一在网关层校验 JWT 或 Session

HTTPS 强制

网关层强制 HTTPS，防止 Token 在传输过程中被窃取（中间人攻击）

Token 过期策略

Access Token 短期有效（15分钟），配合 Refresh Token 实现无感知续期

黑名单机制

用户登出或 Token 泄露时，将 Token 加入黑名单（Redis 存储）

6.2 HTTPS và SSL Termination

Tại sao cần HTTPS?

An toàn: Ngăn chặn dữ liệu bị đánh cắp trong quá trình truyền tải
Tuân thủ: Trình duyệt hiện đại hiển thị cảnh báo "Không an toàn" với website HTTP
SEO: Công cụ tìm kiếm ưu tiên thu thập website HTTPS

Giải pháp SSL Termination:

Chỉ cấu hình HTTPS và chứng chỉ ở tầng gateway
Gateway chịu trách nhiệm TLS handshake và mã hóa/giải mã
Giữa gateway và dịch vụ backend sử dụng HTTP plaintext (mạng nội bộ đáng tin cậy)
Dịch vụ backend tập trung vào logic nghiệp vụ, không cần xử lý TLS

💡 Ưu điểm của SSL Termination

Đơn giản hóa quản lý: Chứng chỉ chỉ cấu hình ở gateway, backend không cần cấu hình
Giảm chi phí: Dịch vụ backend không cần xử lý TLS handshake
Cập nhật thống nhất: Cập nhật chứng chỉ chỉ cần thao tác ở gateway

🔐 HTTPS 流量解密流程

👤

客户端 (浏览器)

发起 HTTPS 请求

🔒TLS 加密连接

证书: *.example.com

算法: TLS 1.3

加密: AES-256-GCM

🚪

Nginx (SSL 终结)

📜 校验证书

🔓 解密流量

📝 添加 X-Forwarded-*

🔓HTTP 明文

X-Forwarded-For: 203.0.113.42

X-Forwarded-Proto: https

X-Real-IP: 203.0.113.42

⚙️

后端服务集群

专注于业务逻辑，无需处理 TLS

📜 SSL 证书管理

生成私钥

使用 OpenSSL 生成 RSA 私钥，这是证书的基础

openssl genrsa -out private.key 2048

创建 CSR

生成证书签名请求，包含域名和组织信息

openssl req -new -key private.key -out csr.pem

域名验证

CA 机构验证域名所有权（DNS 记录或 HTTP 文件）

# 添加 DNS TXT 记录或上传验证文件到 /.well-known/

签发证书

验证通过后，CA 签发证书文件

# 下载 certificate.crt 和 chain.crt

部署配置

将证书配置到 Nginx 并测试

nginx -t && systemctl reload nginx

✨ SSL 终结的核心优势

🚀

性能提升

TLS 握手和加密解密是 CPU 密集型操作，集中在 Nginx 处理，后端服务专注业务逻辑，整体吞吐量提升 2-5 倍

🔧

简化运维

证书统一管理，只需在 Nginx 配置一次，无需在每个后端服务重复配置，证书续期、更换一键完成

🛡️

集中安全

SSL/TLS 配置统一管控，强制使用最新协议版本和密码套件，统一添加安全响应头（HSTS、CSP 等）

📊

统一监控

所有 HTTPS 流量经过 Nginx，可以统一记录访问日志、分析 SSL 握手性能、监控证书有效期，便于审计和排障

7. Giới hạn lưu lượng và Ngắt mạch: Làm sao ngăn hệ thống bị "lũ lưu lượng" cuốn trôi?

7.1 So sánh thuật toán giới hạn lưu lượng

Thuật toán	Tư tưởng cốt lõi	Lưu lượng đột biến	Tình huống phù hợp	Độ phức tạp triển khai
Token Bucket	Xô chứa token, có token mới được qua	Cho phép một mức độ đột biến nhất định	Giới hạn API, kiểm soát băng thông	Trung bình
Leaky Bucket	Yêu cầu vào xô, xử lý đầu ra đều đặn	Bắt buộc làm mịn, đột biến sẽ bị cache hoặc từ chối	Cần xử lý đều đặn nghiêm ngặt	Trung bình
Sliding Window	Thống kê số yêu cầu trong cửa sổ thời gian	Đếm chặt theo cửa sổ, vượt quá đều từ chối	Thống kê chính xác (ví dụ "tối đa 100 lần/phút")	Khá cao

7.2 Cấu hình giới hạn lưu lượng Nginx thực tế

nginx

# Định nghĩa vùng giới hạn lưu lượng (đặt trong khối http)

# 1. Giới hạn lưu lượng dựa trên IP (thuật toán Leaky Bucket)
# zone=mylimit:10m - tên vùng và kích thước bộ nhớ (10MB lưu được khoảng 160k IP)
# rate=10r/s - cho phép 10 yêu cầu mỗi giây
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

# 2. Giới hạn số kết nối dựa trên IP (ngăn một IP tạo quá nhiều kết nối)
limit_conn_zone $binary_remote_addr zone=addr:10m;

# 3. Giới hạn lưu lượng dựa trên endpoint dịch vụ (không phân biệt IP, bảo vệ toàn bộ backend)
limit_req_zone $server_name zone=server_limit:10m rate=100r/s;

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

    # User Service - Giới hạn lưu lượng thông thường
    location /api/users/ {
        # Áp dụng giới hạn lưu lượng
        # burst=20 - dung lượng xô, cho phép đột biến 20 yêu cầu
        # nodelay - không trì hoãn xử lý yêu cầu đột biến (xử lý ngay hoặc từ chối)
        limit_req zone=mylimit burst=20 nodelay;

        # Giới hạn số kết nối của một IP
        limit_conn addr 10;

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

    # Order Service - Giới hạn lưu lượng nghiêm ngặt hơn
    location /api/orders/ {
        # Giới hạn nghiêm ngặt hơn: 5 yêu cầu mỗi giây
        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;
    }

    # Xử lý sau khi giới hạn lưu lượng
    # Khi yêu cầu bị giới hạn, trả về 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;
    }
}

💡 Khuyến nghị chiến lược giới hạn lưu lượng

API thông thường: 10 yêu cầu/giây, cho phép đột biến 20
API quan trọng (thanh toán, đơn hàng): 5 yêu cầu/giây, cho phép đột biến 10
Bảo vệ toàn cục: Tổng tất cả yêu cầu không vượt quá 100/giây

选择限流算法

🪙 令牌桶算法可视化

令牌桶

🪙

5 / 10 令牌

⏰ 令牌产生器 (2/秒)

🪙

📥 请求队列

📊 三种算法对比

维度	令牌桶 (Token Bucket)	漏桶 (Leaky Bucket)	滑动窗口 (Sliding Window)
核心思想	桶里装令牌，有令牌才能通过	请求进桶，匀速流出处理	统计时间窗口内的请求数
突发流量	✅ 允许一定程度的突发（桶里有令牌）	❌ 强制平滑，突发会被缓存或拒绝	❌ 严格按窗口计数，超出一律拒绝
适用场景	API 限流、带宽控制（允许突发）	需要严格匀速处理的场景（如消息队列）	精确统计（如"1分钟内最多100次"）
实现复杂度	中等	中等	较高（需要记录每个时间窗口的请求）
Nginx 配置	limit_req_zone (漏桶)	limit_req_zone (漏桶)	需第三方模块或 Lua

📝 Nginx 限流配置示例

# 定义限流区域
# $binary_remote_addr: 按 IP 限流
# zone=mylimit:10m: 区域名称和大小
# rate=10r/s: 每秒最多10个请求
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

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

    location / {
        # 应用限流
        # burst=20: 桶容量，允许突发20个请求
        # nodelay: 不延迟处理突发请求
        limit_req zone=mylimit burst=20 nodelay;

        proxy_pass http://backend;
    }
}

💡 配置说明

limit_req_zone: 在 http 块中定义限流区域
$binary_remote_addr: 使用二进制 IP 地址作为限流键（省内存）
zone=mylimit:10m: 区域名称 mylimit，分配 10MB 内存
rate=10r/s: 每秒允许 10 个请求（漏桶算法）
burst=20: 桶的容量为 20，允许一定程度的突发流量
nodelay: 不延迟处理突发请求（立即处理或拒绝）

7.3 Ngắt mạch: Ngăn chặn lan truyền lỗi

Nguyên lý hoạt động của Circuit Breaker:

Trạng thái đóng: Chuyển tiếp yêu cầu bình thường, đồng thời thống kê tỷ lệ lỗi
Trạng thái mở: Khi tỷ lệ lỗi vượt ngưỡng, circuit breaker mở, trả về lỗi trực tiếp, không chuyển tiếp yêu cầu nữa
Trạng thái nửa mở: Sau một khoảng thời gian, cho phép một lượng nhỏ yêu cầu thăm dò, nếu thành công thì đóng circuit breaker

💡 Tư tưởng cốt lõi

Ngắt mạch giống như cầu chì điện: Khi dòng điện quá lớn, cầu chì tự động ngắt, bảo vệ toàn bộ mạch điện không bị cháy.

Tương tự, khi dịch vụ backend xuất hiện nhiều lỗi, circuit breaker "ngắt", thất bại nhanh, ngăn lỗi lan truyền ra toàn hệ thống.

8. Tổng kết: Tư duy thiết kế Gateway cốt lõi

8.1 Ôn tập nguyên tắc cốt lõi

Nguyên tắc	Ý nghĩa	Điểm thực hành
Định tuyến	Đưa yêu cầu đến đúng nơi	Định tuyến theo đường dẫn, tên miền, Header
Cân bằng tải	Phân bổ lưu lượng đến nhiều máy chủ	Round Robin, Weighted, Least Connections, IP Hash
An toàn	Bảo vệ cánh cổng hệ thống	Xác thực, ủy quyền, HTTPS, WAF
Giới hạn lưu lượng	Ngăn bị lưu lượng cuốn trôi	Token Bucket, Leaky Bucket, Sliding Window
Ngắt mạch	Ngăn lan truyền lỗi	Thất bại nhanh, phương án giảm cấp
Khả năng quan sát	Giám sát và xử lý sự cố	Log, metrics, tracing

8.2 Khuyến nghị lựa chọn công nghệ

💡 Cây quyết định lựa chọn

Chọn gateway:
│
├─ Chỉ cần reverse proxy, cân bằng tải?
│  ├─ Có → Nginx (lựa chọn hàng đầu)
│  └─ Không → Tiếp tục
│
├─ Cần hệ sinh thái plugin phong phú?
│  ├─ Có → Kong (dựa trên Nginx)
│  └─ Không → Tiếp tục
│
├─ Hệ sinh thái Spring Cloud?
│  ├─ Có → Spring Cloud Gateway
│  └─ Không → Nginx

9. Bảng tra cứu thuật ngữ

Thuật ngữ	Tiếng Anh	Giải thích
Reverse Proxy	Reverse Proxy	Dịch vụ proxy triển khai ở phía máy chủ, nhận yêu cầu từ client và chuyển tiếp đến dịch vụ nội bộ. Client chỉ biết reverse proxy tồn tại, không biết địa chỉ máy chủ thực.
Forward Proxy	Forward Proxy	Dịch vụ proxy triển khai ở phía client, thay mặt client truy cập tài nguyên bên ngoài. Máy chủ thấy IP của proxy, không biết client thực. Ứng dụng điển hình: VPN, công cụ vượt tường lửa.
API Gateway	API Gateway	Tầng trung gian giữa client và dịch vụ backend, cung cấp định tuyến, xác thực, giới hạn lưu lượng, ghi log, là "cánh cổng thống nhất" của kiến trúc microservices.
Cân bằng tải	Load Balancing	Phân bổ lưu lượng yêu cầu đến nhiều máy chủ, tránh một máy chủ quá tải, nâng cao tính khả dụng và hiệu năng hệ thống.
SSL Termination	SSL Termination	Xử lý mã hóa/giải mã HTTPS tại tầng gateway, dịch vụ backend dùng HTTP, giảm chi phí tính toán backend, đơn giản hóa quản lý chứng chỉ.
Giới hạn lưu lượng	Rate Limiting	Giới hạn số yêu cầu trong một đơn vị thời gian, ngăn hệ thống bị quá tải bởi lưu lượng đột biến. Thuật toán phổ biến: Token Bucket, Leaky Bucket, Sliding Window.
Ngắt mạch	Circuit Breaking	Khi dịch vụ phụ thuộc gặp sự cố, tự động cắt lời gọi, ngăn lỗi lan truyền, và cung cấp phương án giảm cấp.
Duy trì session	Session Persistence	Đảm bảo yêu cầu của cùng một client luôn được định tuyến đến cùng một máy chủ backend, dùng cho các tình huống cần duy trì trạng thái session.
Health Check	Health Check	Định kỳ kiểm tra trạng thái sức khỏe của dịch vụ backend, tự động loại bỏ node lỗi, đảm bảo lưu lượng chỉ được gửi đến instance dịch vụ khỏe mạnh.
Canary Release	Canary Release	Dẫn một lượng nhỏ lưu lượng đến phiên bản mới, sau khi xác minh tính ổn định, từ từ mở rộng tỷ lệ, giảm rủi ro phát hành.
WAF	Web Application Firewall	Tường lửa ứng dụng web, phòng chống SQL injection, XSS, tấn công CC và các mối đe dọa bảo mật web khác.
CDN	Content Delivery Network	Mạng phân phối nội dung, triển khai node biên trên toàn cầu, tăng tốc truy cập tài nguyên tĩnh.

Cổng gateway và Reverse Proxy ​

1. Tại sao cần "Gateway"? ​

1.1 Từ một ví dụ thực tế: Sự phát triển kiến trúc của một nền tảng thương mại điện tử ​

1.2 Ẩn dụ đời sống về Gateway ​

2. Reverse Proxy là gì? ​

2.1 Forward Proxy và Reverse Proxy ​

2.2 Giá trị cốt lõi của Reverse Proxy ​

3. Nginx: Tại sao có thể chịu được hàng triệu kết nối đồng thời? ​

3.1 Mô hình tiến trình Master-Worker ​

3.2 Hướng sự kiện + Bất đồng bộ không chặn ​

4. API Gateway là gì? ​

4.1 Tại sao cần API Gateway? ​

4.2 Chức năng cốt lõi của API Gateway ​

5. Gateway Hands-on: Làm sao xây dựng kiến trúc gateway hoàn chỉnh? ​

5.1 Sơ đồ kiến trúc đầy đủ ​

5.2 Định tuyến và Cân bằng tải ​

6. Bảo mật Gateway: Làm thế nào bảo vệ cánh cổng hệ thống? ​

6.1 Xác thực và Ủy quyền ​

6.2 HTTPS và SSL Termination ​

7. Giới hạn lưu lượng và Ngắt mạch: Làm sao ngăn hệ thống bị "lũ lưu lượng" cuốn trôi? ​

7.1 So sánh thuật toán giới hạn lưu lượng ​

7.2 Cấu hình giới hạn lưu lượng Nginx thực tế ​

7.3 Ngắt mạch: Ngăn chặn lan truyền lỗi ​

8. Tổng kết: Tư duy thiết kế Gateway cốt lõi ​

8.1 Ôn tập nguyên tắc cốt lõi ​

8.2 Khuyến nghị lựa chọn công nghệ ​

9. Bảng tra cứu thuật ngữ ​

Cổng gateway và Reverse Proxy

1. Tại sao cần "Gateway"?

1.1 Từ một ví dụ thực tế: Sự phát triển kiến trúc của một nền tảng thương mại điện tử

1.2 Ẩn dụ đời sống về Gateway

2. Reverse Proxy là gì?

2.1 Forward Proxy và Reverse Proxy

2.2 Giá trị cốt lõi của Reverse Proxy

3. Nginx: Tại sao có thể chịu được hàng triệu kết nối đồng thời?

3.1 Mô hình tiến trình Master-Worker

3.2 Hướng sự kiện + Bất đồng bộ không chặn

4. API Gateway là gì?

4.1 Tại sao cần API Gateway?

4.2 Chức năng cốt lõi của API Gateway

5. Gateway Hands-on: Làm sao xây dựng kiến trúc gateway hoàn chỉnh?

5.1 Sơ đồ kiến trúc đầy đủ

5.2 Định tuyến và Cân bằng tải

6. Bảo mật Gateway: Làm thế nào bảo vệ cánh cổng hệ thống?

6.1 Xác thực và Ủy quyền

6.2 HTTPS và SSL Termination

7. Giới hạn lưu lượng và Ngắt mạch: Làm sao ngăn hệ thống bị "lũ lưu lượng" cuốn trôi?

7.1 So sánh thuật toán giới hạn lưu lượng

7.2 Cấu hình giới hạn lưu lượng Nginx thực tế

7.3 Ngắt mạch: Ngăn chặn lan truyền lỗi

8. Tổng kết: Tư duy thiết kế Gateway cốt lõi

8.1 Ôn tập nguyên tắc cốt lõi

8.2 Khuyến nghị lựa chọn công nghệ

9. Bảng tra cứu thuật ngữ