- API Gateway là điểm truy cập tập trung giữa client và microservice, xử lý auth, rate limiting và routing tại một chỗ duy nhất.
- Netflix vận hành 80+ cluster Zuul 2 xử lý hơn 1 triệu request mỗi giây.
- Kong benchmark 50.000 TPS mỗi node với overhead chỉ 1-10ms.
- Pattern này phù hợp từ 3-4 service trở lên - đừng thêm gateway chỉ vì microservices là trend.
TL;DR
API Gateway là lớp trung gian tập trung giữa client và các microservice - nơi xử lý xác thực, rate limiting, SSL termination, routing và tổng hợp response. Thay vì mỗi service tự lo từng việc, Gateway làm tất cả một chỗ. Netflix vận hành hơn 80 cluster Zuul 2, xử lý hơn 1 triệu request mỗi giây. Kong đạt 50.000 TPS mỗi node. Overhead của pattern này: 1-10ms mỗi request - đáng đổi khi bạn có từ 3-4 service trở lên.
Vấn đề khi để client gọi thẳng từng service
Hình dung bạn có 8 microservice: User Service, Order Service, Product Service, Payment Service... Nếu client gọi thẳng vào từng service, một loạt vấn đề xuất hiện ngay:
- Client phải quản lý 8 URL khác nhau - và nhớ cái nào đang ở đâu.
- Logic xác thực bị copy-paste vào mỗi service. Thay đổi JWT secret? Sửa ở 8 chỗ.
- Versioning trở thành ác mộng - bạn cần điều phối release đồng bộ giữa các team.
- Internal service bị phơi ra public internet. Order Service không cần ai ngoài hệ thống gọi vào.
- Monitoring phân mảnh - log ở 8 nơi, không có bức tranh toàn cảnh.
Vấn đề không phải kiến trúc microservices tệ. Vấn đề là thiếu một điểm kiểm soát trung tâm.
Gateway làm gì thay bạn
API Gateway hoạt động như một reverse proxy Layer 7 - nó hiểu HTTP payload, không chỉ IP/port. Toàn bộ traffic từ ngoài vào đều đi qua đây trước.
- Xác thực JWT - một chỗ duy nhất validate token, service không cần biết.
- SSL/TLS termination - client kết nối HTTPS tới gateway, traffic nội bộ có thể là HTTP thuần.
- Routing -
/api/orders/*đi Order Service,/api/products/*đi Product Service. - Response aggregation - gộp kết quả từ 3 service thành 1 response duy nhất cho mobile client.
- Rate limiting & DDoS protection - chặn trước khi traffic độc hại chạm vào service.
- Caching - cache response phổ biến ở gateway, giảm tải downstream.
- Protocol translation - client gửi REST, service nhận gRPC? Gateway dịch.
- Observability tập trung - mọi request đều đi qua đây, log và metrics ở một chỗ.
Gateway không phải Load Balancer
Câu hỏi hay gặp nhất khi giải thích pattern này: "Khác Load Balancer chỗ nào?"
Load Balancer hoạt động ở Layer 4 (IP/port). Nó phân phối traffic đến các instance giống nhau của cùng một service - không hiểu HTTP payload, không biết bạn đang gọi endpoint gì.
API Gateway hoạt động ở Layer 7 (application-aware). Nó đọc được HTTP headers, path, body - từ đó enforce policy: validate token này, limit rate của IP kia, route request sang service đúng.
Hệ thống production thường chạy cả hai: client kết nối qua L4 load balancer đến gateway cluster, gateway cluster mới điều phối vào các service. Mỗi lớp làm đúng việc của mình.
| Tiêu chí | Load Balancer | API Gateway |
|---|---|---|
| OSI Layer | Layer 4 (TCP/UDP) | Layer 7 (HTTP/gRPC) |
| Hiểu HTTP payload | Không | Có |
| Auth / Rate limit | Không | Có |
| Routing theo path | Không | Có |
| Dùng trong production | Trước gateway | Sau load balancer |
Con số thực tế từ Netflix và Kong
Pattern này không phải lý thuyết hàn lâm:
- Netflix vận hành hơn 80 cluster Zuul 2, phục vụ hơn 100 backend service, xử lý ổn định hơn 1 triệu request/giây.
- Kong (open-source gateway phổ biến nhất) benchmark 50.000 TPS mỗi node trong điều kiện chuẩn.
- Overhead của gateway: 1-10ms mỗi request - có thể chấp nhận được cho tuyệt đại đa số use case.
- AWS API Gateway tính phí theo mô hình per-million-requests - chi phí thực tế rất thấp với traffic vừa phải.
Khi nào nên - và không nên - dùng
Nên dùng khi:
- Có từ 3-4 backend service trở lên.
- Phục vụ nhiều loại client: web, mobile, third-party.
- Cần public API với SLA rõ ràng.
- Team có năng lực vận hành thêm một component.
Không nên dùng khi:
- Ứng dụng chỉ có một service - gateway thêm complexity không cần thiết.
- Traffic thấp, không có áp lực scale.
- Team chưa đủ năng lực ops - gateway hỏng là toàn hệ thống hỏng theo.
Đừng thêm gateway chỉ vì "microservices là best practice". Kiến trúc nên scale theo nhu cầu thực.
Công cụ bạn sẽ gặp
Open source (tự host): Kong, NGINX, Envoy, Traefik, Spring Cloud Gateway, Zuul. Kong và NGINX là hai cái tên phổ biến nhất trong thực tế.
Managed (cloud provider lo ops): AWS API Gateway, Google Apigee, Azure API Management. Trả thêm tiền để không phải tự maintain - hợp lý nếu team nhỏ hoặc thiếu DevOps.
Không có công cụ nào "tốt nhất tuyệt đối" - chọn theo tech stack, budget và năng lực team.
Tiếp theo: Service Mesh
API Gateway giải quyết external traffic - client gọi vào hệ thống. Nhưng còn internal traffic - các service gọi nhau? Đó là bài toán của Service Mesh (Istio, Linkerd): mutual TLS, circuit breaking, service discovery, observability cho east-west traffic.
Hai pattern không thay thế nhau - Gateway xử lý north-south (vào/ra hệ thống), Service Mesh xử lý east-west (service-to-service). Hệ thống đủ lớn thường cần cả hai.