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:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

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.

1

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).

1

X-Request-ID: 123e4567-e89b-12d3-a456-426614174000

Cách dùng:

1. Gateway tạo ra UUID này.
2. Service A log nó lại và truyền tiếp sang Service B.
3. Service B bị lỗi.
4. Bạn chỉ cần grep cá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.

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).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

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.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

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.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

# Đị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ạ

1
2
3
4
5
6
7

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.