Load Balancer, Reverse Proxy, API Gateway: Mô hình tư duy 'Khách sạn 5 sao'
Phân biệt 'Bộ ba giao thông' (Traffic Trio) ở đẳng cấp chuyên gia. Từ mô hình tư duy đến cấu hình Nginx thực chiến, và cách debug lỗi 502 vs 504.
Nếu bạn hỏi mười anh em dev về sự khác biệt giữa Load Balancer, Reverse Proxy, và API Gateway, khả năng cao là bạn sẽ nhận được mười câu trả lời khác nhau.
Người thì bảo chúng nó là một. Người thì bảo chúng nó nằm ở các tầng OSI khác nhau.
Về mặt kỹ thuật, cả ba đều làm nhiệm vụ “điều hướng request” (Request Forwarding), nhưng mục đích (intent) của chúng thì hoàn toàn khác biệt.
Đây là Hướng dẫn chuyên sâu (Mastery Guide) về “Bộ ba giao thông” này. Chúng ta sẽ bắt đầu với mô hình tư duy chuẩn, sau đó lặn sâu vào các HTTP Headers, giải mã các mã lỗi (502 vs 504), và cuối cùng là cấu hình Nginx thực chiến cho từng loại.
Phần 1: Nền tảng (Mô hình tư duy)
Một sơ đồ duy nhất cần nhớ
Hãy tưởng tượng ba cái này giống như các tầng của một cái phễu lọc:
THẾ GIỚI BÊN NGOÀI (Internet)
│
▼
PHÂN PHỐI LƯU LƯỢNG (Layer 4/7)
Load Balancer
│
▼
BẢO MẬT & TỐI ƯU (Layer 7)
Reverse Proxy
│
▼
ĐIỀU PHỐI & LOGIC (Layer 7)
API Gateway
│
▼
HỆ THỐNG NỘI BỘ (Apps của bạn)
Mô hình Khách sạn 5 sao
Tưởng tượng bạn đang đi nghỉ dưỡng ở một khách sạn siêu sang.
-
Load Balancer = Anh Cảnh sát giao thông (Ngoài cổng) Anh đứng ngay lối vào. Khách sạn có 3 cái cổng khác nhau. Anh chỉ việc vẫy xe sang cổng nào đang vắng nhất. Anh chẳng quan tâm bạn là ai, anh chỉ muốn cái đường vào không bị kẹt là được.
- Mục tiêu: Tính sẵn sàng (Availability). Đừng để server nào chết vì quá tải.
-
Reverse Proxy = Lễ tân (Ngay cửa ra vào) Khi bạn bước vào, lễ tân sẽ kiểm tra ID của bạn (SSL Termination), cất hộ áo khoác (Compression), và đưa cho bạn cái bản đồ khách sạn (Caching). Lễ tân bảo vệ nhân viên bên trong khỏi mấy việc vặt vãnh.
- Mục tiêu: Hiệu năng & Ẩn danh. Giấu kỹ mấy con server backend đi.
-
API Gateway = Quản gia / Concierge (Chuyên gia phục vụ) Đây là người thông minh nhất. Nếu bạn bảo: “Tôi muốn ăn bít tết, đi massage và cần một cái taxi”, ông quản gia sẽ tự tay gọi đầu bếp, gọi nhân viên spa và gọi tài xế cho bạn. Ông điều phối (orchestrate) mọi nhu cầu và trả lời bạn một câu duy nhất.
- Mục tiêu: Quản lý sự phức tạp. Xử lý Auth, Rate Limiting, và Routing.
Phần 2: Điều tra (Debug như chuyên gia)
Khi bạn nhét một ông “trung gian” (proxy) vào giữa, bạn đã làm đứt kết nối trực tiếp giữa Client và Server. Việc debug sẽ trở thành thảm họa nếu bạn không hiểu về Headers.
1. Bí ẩn IP bị mất (X-Forwarded-For)
Khi người dùng gọi qua Load Balancer, App của bạn sẽ nhìn thấy IP kết nối đến là IP của Load Balancer, chứ không phải IP thật của khách.
- Vấn đề: Bạn chặn (ban) một IP spam, nhưng lại vô tình chặn luôn IP của Load Balancer (sập toàn bộ web).
- Giải pháp: Nhìn vào header
X-Forwarded-For.
X-Forwarded-For: <Client IP>, <Proxy 1 IP>, <Proxy 2 IP>
- Quy tắc vàng: IP đầu tiên trong danh sách là khách thật (Real User). IP cuối cùng là Proxy gần mình nhất.
2. Dấu vết (X-Request-ID)
Trong thế giới microservices, một request có thể nhảy qua 5 service khác nhau. Nếu lỗi xảy ra, làm sao tìm được nó trong đống log hỗn độn?
Bạn phải gắn thẻ (tag) cho mỗi request bằng một ID duy nhất ngay khoảnh khắc nó đi vào hệ thống (tại Gateway).
X-Request-ID: 123e4567-e89b-12d3-a456-426614174000
Cách dùng:
- Gateway tạo ra UUID này.
- Service A log nó lại và truyền tiếp sang Service B.
- Service B bị lỗi.
- Bạn chỉ cần
grepcái UUID đó trên hệ thống log tổng (Splunk/Datadog/ELK) là ra toàn bộ câu chuyện.
Phần 3: Chẩn đoán (Giải mã Error Codes)
Khi “Khách sạn” cháy, mã lỗi sẽ cho bạn biết chính xác cháy ở tầng nào.
502 Bad Gateway vs. 504 Gateway Timeout
Hai lỗi này hay gặp nhất và anh em hay nhầm nhất.
| Lỗi | Tên | Phân tích | Lỗi tại ai? |
|---|---|---|---|
| 502 | Bad Gateway | Proxy thử gọi App, nhưng App từ chối kết nối hoặc ngắt ngay lập tức. | App ĐÃ CHẾT. (Crashed, chưa bật, port chưa mở). |
| 504 | Gateway Timeout | Proxy kết nối được tới App, và chờ… chờ mãi… nhưng App không trả lời. | App BỊ CHẬM. (Database bị lock, query quá lâu, quá tải). |
| 503 | Service Unavailable | Proxy tìm không thấy server nào “healthy” để gọi. | App BỊ THIẾU. (Deploy bị lỗi, health check fail hết). |
Mẹo: Thấy 502 -> Kiểm tra xem process có chạy không (
ps aux). Thấy 504 -> Kiểm tra database lock hoặc slow query log.
Phần 4: Giải pháp (Sách nấu ăn Nginx)
Một công cụ làm được cả 3 không? Có. Nginx là con dao Thụy Sĩ. Nhưng cấu hình (config) của nó sẽ quyết định nó đóng vai gì.
Kịch bản 1: The Load Balancer
Chia tải đơn giản (Round-Robin).
upstream backend_servers {
server 10.0.0.1;
server 10.0.0.2;
server 10.0.0.3;
}
server {
listen 80;
location / {
proxy_pass http://backend_servers;
}
}
Kịch bản 2: The Reverse Proxy
Thêm SSL Termination và chỉnh sửa Header.
server {
listen 443 ssl;
server_name api.mysite.com;
# Cấu hình SSL (Cô Lễ tân kiểm tra ID)
ssl_certificate /etc/ssl/certs/fullchain.pem;
ssl_certificate_key /etc/ssl/private/key.pem;
location / {
# Truyền danh tính thật cho backend (Fix lỗi "Mất IP")
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host;
proxy_pass http://localhost:8000;
}
}
Kịch bản 3: The API Gateway
Thêm giới hạn truy cập (Rate Limiting) và Routing thông minh.
# Định nghĩa Rate Limit: 10 requests mỗi giây cho mỗi IP
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;
server {
listen 443 ssl;
# 1. Auth Service
location /auth {
proxy_pass http://auth-service:3000;
}
# 2. Payment Service (Bảo vệ nghiêm ngặt)
location /payments {
# Ép Rate Limit
limit_req zone=api_limit burst=5;
# Verify Token (Nginx Plus hoặc Lua script thường dùng ở đây)
auth_request /auth/verify;
proxy_pass http://payment-service:4000;
}
}
Mô hình tư duy chốt hạ
Chia tải (Traffic) -> Load Balancer (Tính sẵn sàng)
Giấu & Bảo vệ -> Reverse Proxy (Bảo mật)
Routing & Logic -> API Gateway (Điều phối)
502 = App Chết
504 = App Chậm
X-Forwarded-For = IP thật của khách
Đừng chỉ cài công cụ. Hãy hiểu mục đích (intent) của dòng chảy dữ liệu, và bạn sẽ biết chính xác cần rút món đồ chơi nào ra khỏi thắt lưng.
Bài viết liên quan
-
CDN: Mô hình tư duy 'Cửa hàng Tiện lợi'
Tại sao ảnh load ngay với user Mỹ nhưng ì ạch ở Việt Nam? Hướng dẫn chuyên sâu về CDN Edge Node, Cache-Control header và cache busting.
-
Caching & Redis: Mô hình tư duy 'Tờ giấy nhớ'
Tại sao Redis làm mọi thứ nhanh hơn? Hướng dẫn chuyên sâu về cache invalidation (vấn đề khó nhất CS), các chiến lược eviction, và Redis data types.
-
Task Queue & Message Broker: Celery, RabbitMQ và Kafka — Phân biệt rõ ràng
Tại sao gửi email làm đứng API? Hướng dẫn chuyên sâu về xử lý bất đồng bộ: từ Celery/Django-Q (hàng đợi tác vụ) đến RabbitMQ (môi giới) và Kafka (luồng sự kiện).
-
Rate Limiting & Circuit Breaker: Mô hình tư duy 'Đèn Giao thông & Hộp Cầu dao'
Làm sao ngăn một client xấu làm sập toàn bộ API của bạn? Hướng dẫn chuyên sâu về chiến lược rate limiting, circuit breaker và các pattern tăng cường độ bền.