I. Giới thiệu Reverse Proxy vs API Gateway vs Load Balancer
Phân tích bản chất, mục đích và cơ chế hoạt động của ba thành phần điều phối mạng cốt lõi trong các hệ thống hiện đại.
Sơ Đồ Minh Họa Trực Quan
artifacts/note-9-28
Sơ Đồ: Reverse Proxy vs API Gateway vs Load Balancer
Nhấn vào ảnh để xem kích thước đầy đủ trong tab mới.
1. Reverse Proxy
- Là lớp trung gian nằm giữa Client và Application Server.
- Mục đích & Lợi ích:
- Ẩn danh tính và cấu trúc của Application Server (tăng cường bảo mật).
- Hỗ trợ SSL termination (chấm dứt mã hóa SSL), nén dữ liệu (compression) và bộ nhớ đệm (caching).
- Vẫn phát huy tác dụng ngay cả khi chỉ có một Application Server đơn lẻ nhờ khả năng tối ưu hóa lưu lượng và quản lý kết nối.
2. API Gateway
- - Là điểm tiếp nhận duy nhất (single point of entry) nằm giữa Client và các dịch vụ backend.
- - Phù hợp nhất với kiến trúc hướng dịch vụ và vi dịch vụ (Microservices).
- Mục đích & Chức năng:
- Xác thực và phân quyền (Authentication and Authorization).
- Định tuyến yêu cầu (Request Routing).
- Giới hạn tần suất gọi (Rate Limiting) và giám sát lưu lượng (Monitoring).
- Cân bằng tải cơ bản giữa các service instances.
3. Load Balancer
- Là thành phần phân phối lưu lượng truy cập mạng đến một nhóm các Application Server backend.
- Mục đích & Cơ chế:
- Tối ưu hóa hiệu năng và ngăn chặn tình trạng quá tải cục bộ trên từng máy chủ.
- Đảm bảo tính sẵn sàng cao (High Availability) bằng cơ chế kiểm tra sức khỏe (health checks) để chỉ điều hướng request đến các server đang hoạt động bình thường.
- Hỗ trợ mở rộng linh hoạt: tự động thêm hoặc gỡ bỏ máy chủ tùy theo lưu lượng tải.
- Sử dụng các thuật toán phân phối phổ biến: Round Robin, Least Connections, IP Hash.
4. Cách Phối Hợp Trong Thực Tế
- Mô hình kiến trúc đám mây (AWS): API Gateway đóng vai trò đầu mối tiếp nhận, xác thực và định tuyến; phía sau mỗi nhóm microservices có thể sử dụng Elastic Load Balancer (ELB) riêng để phân phối tải.
- Công cụ đa nhiệm (Nginx): Có thể đồng thời đóng cả hai vai trò: vừa làm Load Balancer điều phối tải, vừa làm Reverse Proxy thực hiện Caching và SSL Termination.
LƯU Ý KIẾN TRÚC:
API Gateway xử lý logic tầng 7 rất nặng (xác thực token, giải mã SSL, rate limiting...) nên tiêu tốn nhiều CPU/RAM. Nếu traffic dồn về quá lớn mà nó là một máy chủ đơn lẻ, nó sẽ nhanh chóng nghẽn cổ chai và sập ➔ Luôn đặt một Load Balancer (L4) phía trước để chia tải cho một cụm (cluster) nhiều API Gateway tự động mở rộng (auto-scale).
5. Các Thuật Toán Của Load Balancer
Các thuật toán cốt lõi quyết định cách thức phân phối lưu lượng truy cập từ Client đến từng máy chủ backend:
Round Robin:
Cứ tuần tự lần lượt chia request cho từng server trong danh sách.
Sticky Round Robin:
Cái nào đã xử lý request nào rồi thì tiếp tục xử lý request đó (duy trì phiên làm việc).
Weight Round Robin:
Cho phép gán trọng số cho từng server. Server có cấu hình mạnh hơn và trọng số cao hơn sẽ nhận nhiều request hơn.
IP/URL Hash:
Dựa vào hàm băm địa chỉ IP hoặc đường dẫn URL của request để cố định request đến từng server cụ thể.
Least Connections:
Chọn server hiện có số lượng kết nối đang hoạt động ít nhất để xử lý request tiếp theo.
Least Time:
Chọn server có thời gian phản hồi (response time) chậm nhất để xử lý request.
Câu Hỏi Suy Ngẫm
Các vấn đề thiết kế then chốt nhằm kiểm tra tính độc lập, ranh giới dịch vụ và kiến trúc phân tán:
1
Một monolith được chia module tốt khác gì một "big ball of mud"?
2
Hai microservices có source code tách riêng nhưng sửa trực tiếp 30 table chung. Chúng có thực sự độc lập không?
3
Vì sao browser biết trực tiếp địa chỉ của 50 microservice tạo coupling nguy hiểm?
4
Nếu toàn bộ business rules nằm trong API Gateway còn microservice chỉ là CRUD, kiến trúc đó có còn đúng tinh thần microservice không?
5
Tại sao mobile app và desktop web có thể cần 2 API contract khác nhau dù dùng cùng business services?