API Gateway là gì? Cổng vào thống nhất cho Microservices

API Gateway là lớp trung gian thông minh đứng giữa client và hàng chục microservice phía sau: nó nhận mọi request, kiểm tra danh tính, giới hạn tốc độ, định tuyến đến đúng service rồi trả kết quả về — tất cả trong một điểm vào duy nhất. Bài viết này giải thích API Gateway là gì, luồng request đi qua gateway như thế nào, so sánh các giải pháp phổ biến và cách bảo vệ hệ thống tại lớp gateway.

API Gateway là gì?

API Gateway là một reverse proxy đóng vai trò single entry point — điểm vào duy nhất — cho toàn bộ hệ thống microservices. Thay vì để client gọi trực tiếp đến từng service riêng lẻ (với địa chỉ và port khác nhau), client chỉ cần biết một địa chỉ duy nhất là gateway.

Gateway đảm nhiệm nhiều trách nhiệm cùng lúc:

• Routing: Dựa trên path (/users/* → User Service, /orders/* → Order Service), header hoặc method HTTP để chuyển tiếp request đến đúng service phía sau.
• Authentication & Authorization: Kiểm tra token JWT, API key hoặc session trước khi request đến được service.
• Rate Limiting: Giới hạn số lượng request trong một khoảng thời gian để bảo vệ service khỏi quá tải.
• SSL Termination: Xử lý HTTPS tại gateway, service nội bộ chỉ cần HTTP đơn giản.
• Load Balancing: Phân phối traffic đến nhiều instance của cùng một service.
• Request/Response Transformation: Thêm header, chuyển đổi format (XML ↔ JSON), che giấu thông tin nhạy cảm.

Không có gateway, mỗi microservice phải tự triển khai toàn bộ lớp bảo mật và xác thực — dẫn đến code trùng lặp, khó bảo trì và dễ sinh lỗ hổng.

Các chức năng cốt lõi của API Gateway

Một API Gateway sản xuất đầy đủ thường có ít nhất bảy nhóm chức năng sau:

1. Routing thông minh

Gateway phân tích URL, HTTP method và header của request rồi quyết định chuyển tiếp đến upstream nào. Một số gateway hỗ trợ path rewriting — ví dụ nhận /v1/products từ client nhưng chuyển tiếp /internal/catalog đến service.

2. Authentication — xác thực danh tính

Gateway tích hợp với Identity Provider (IdP) để xác minh JWT, OAuth2 token hoặc API key. Nếu token không hợp lệ, gateway trả 401 Unauthorized ngay lập tức mà không cần request chạm đến service phía sau.

3. Rate Limiting — giới hạn tốc độ

Cơ chế phổ biến: token bucket hoặc sliding window. Mỗi client (hoặc mỗi API key) có một "hạn ngạch" requests. Khi vượt ngưỡng, gateway trả 429 Too Many Requests kèm header Retry-After.

4. SSL/TLS Termination

Gateway nhận kết nối HTTPS từ internet, giải mã TLS tại đây rồi chuyển tiếp bằng HTTP thuần đến service nội bộ. Giúp giảm tải CPU cho service và đơn giản hóa quản lý certificate — chỉ cần renew một nơi.

5. Load Balancing

Gateway có thể round-robin, least-connections hoặc weighted balance request đến nhiều instance của cùng một service, kèm health check để tự loại instance không phản hồi.

6. Circuit Breaker

Khi một service phía sau liên tục lỗi (timeout, 5xx), circuit breaker "ngắt mạch" để không gửi thêm request — trả về lỗi có kiểm soát thay vì để client chờ. Giúp hệ thống phục hồi nhanh hơn.

7. Observability: Logging, Metrics, Tracing

Gateway là điểm lý tưởng để inject request ID, collect latency metrics và forward log tập trung. Mọi request đều đi qua đây nên không cần instrumentation ở từng service.

Luồng Request qua API Gateway

Hiểu rõ luồng request giúp debug vấn đề và thiết kế hệ thống đúng:

Client
  │
  ▼  (HTTPS)
┌─────────────────────────────┐
│        API Gateway          │
│  ┌──────────┐ ┌───────────┐ │
│  │Auth Check│ │Rate Limit │ │
│  └────┬─────┘ └─────┬─────┘ │
│       │             │       │
│  ┌────▼─────────────▼─────┐ │
│  │       Router            │ │
│  └────┬──────────┬────────┘ │
└───────┼──────────┼──────────┘
        │          │
   (HTTP)          (HTTP)
        ▼          ▼
   User Service  Order Service

Các bước xử lý chi tiết:

1. Client gửi request — luôn đến địa chỉ gateway, ví dụ https://api.example.com/v1/orders.
2. SSL Termination — gateway giải mã TLS, request trở thành HTTP nội bộ.
3. Authentication Check — gateway kiểm tra JWT hoặc API key trong header Authorization. Nếu thiếu hoặc sai → 401.
4. Rate Limit Check — gateway đếm request theo key (IP, user ID, API key). Nếu vượt ngưỡng → 429.
5. Routing — gateway khớp path với route table, chọn upstream service.
6. Load Balancing — nếu service có nhiều instance, gateway chọn instance theo algorithm đã cấu hình.
7. Forward Request — gateway gửi request (HTTP) đến service, kèm thêm header như X-Request-ID, X-Forwarded-For.
8. Service xử lý — service nhận, xử lý và trả response.
9. Response về client — gateway nhận response từ service, có thể thêm header (CORS, security headers) rồi trả về cho client qua HTTPS.

Tổng thời gian gateway xử lý thường chỉ tốn 1–5ms nếu không có caching hay heavy transformation.

API Gateways phổ biến nhất

Hiện có nhiều lựa chọn từ self-hosted đến fully managed:

Kong — declarative config

Kong cho phép định nghĩa toàn bộ cấu hình bằng file YAML (declarative):

 1# kong.yaml — Kong declarative configuration
 2_format_version: "3.0"
 3
 4services:
 5  - name: user-service
 6    url: http://user-svc:8080
 7    routes:
 8      - name: user-routes
 9        paths:
10          - /v1/users
11        strip_path: true
12    plugins:
13      - name: rate-limiting
14        config:
15          minute: 100          # tối đa 100 req/phút mỗi consumer
16          policy: local
17      - name: key-auth          # yêu cầu API key
18        config:
19          key_names:
20            - apikey
21
22  - name: order-service
23    url: http://order-svc:8080
24    routes:
25      - name: order-routes
26        paths:
27          - /v1/orders
28        strip_path: true
29    plugins:
30      - name: rate-limiting
31        config:
32          minute: 50
33          policy: local
34      - name: jwt               # yêu cầu JWT token
35        config:
36          secret_is_base64: false

Apply config với lệnh: deck gateway sync kong.yaml

NGINX — location block

NGINX làm reverse proxy cơ bản với location block:

 1# /etc/nginx/conf.d/api-gateway.conf
 2
 3upstream user_service {
 4    server user-svc-1:8080;
 5    server user-svc-2:8080;
 6    keepalive 32;              # duy trì connection pool
 7}
 8
 9upstream order_service {
10    server order-svc:8080;
11}
12
13server {
14    listen 443 ssl;
15    server_name api.example.com;
16
17    ssl_certificate     /etc/ssl/certs/api.crt;
18    ssl_certificate_key /etc/ssl/private/api.key;
19
20    # Route /v1/users → User Service
21    location /v1/users/ {
22        proxy_pass         http://user_service/;
23        proxy_set_header   Host $host;
24        proxy_set_header   X-Real-IP $remote_addr;
25        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
26        proxy_set_header   X-Request-ID $request_id;
27
28        # Rate limiting (dùng limit_req_zone định nghĩa bên ngoài)
29        limit_req zone=api_limit burst=20 nodelay;
30    }
31
32    # Route /v1/orders → Order Service
33    location /v1/orders/ {
34        proxy_pass         http://order_service/;
35        proxy_set_header   Host $host;
36        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
37        limit_req zone=api_limit burst=10 nodelay;
38    }
39
40    # Health check endpoint của chính gateway
41    location /health {
42        return 200 "OK\n";
43        add_header Content-Type text/plain;
44    }
45}
46
47# Định nghĩa rate limit zone — 10MB shared memory, 30 req/s mỗi IP
48limit_req_zone $binary_remote_addr zone=api_limit:10m rate=30r/s;

API Gateway vs Load Balancer vs Reverse Proxy

Ba khái niệm này thường bị nhầm lẫn vì đều đứng "trước" service, nhưng vai trò khác nhau rõ ràng:

Khi nào dùng cái nào?

• Chỉ cần phân phối tải nhiều instance → Load Balancer (ALB, HAProxy) là đủ và nhanh hơn.
• Cần SSL termination + static file serving → Reverse Proxy (NGINX) là hợp lý.
• Nhiều service khác nhau, cần auth/rate-limit tập trung → API Gateway là lựa chọn đúng.
• Kiến trúc microservices quy mô lớn → Thường kết hợp cả ba lớp: API Gateway ở ngoài cùng, rồi đến Load Balancer cho từng service cluster.

Microservices là gì? Kiến trúc chia nhỏ service và lợi ích thực tế

Security tại API Gateway

Gateway là nơi lý tưởng để triển khai bảo mật tập trung, thay vì implement lặp lại ở mỗi service:

JWT Validation

JWT (JSON Web Token) là phương thức xác thực phổ biến nhất trong REST API. Gateway xác minh chữ ký của token bằng public key (RS256) hoặc shared secret (HS256):

 1# Kong JWT plugin
 2plugins:
 3  - name: jwt
 4    config:
 5      key_claim_name: iss        # claim chứa key ID
 6      claims_to_verify:
 7        - exp                    # kiểm tra token chưa hết hạn
 8        - nbf                    # kiểm tra token đã có hiệu lực
 9      secret_is_base64: false
10      run_on_preflight: false    # bỏ qua OPTIONS request (CORS preflight)

Khi JWT hợp lệ, gateway thêm header X-Consumer-ID và X-Consumer-Username vào request để service phía sau biết ai đang gọi mà không cần tự decode token.

OAuth2 Authorization Code Flow

Với API cần phân quyền chi tiết (scope-based), gateway tích hợp Authorization Server:

Client → Gateway: GET /v1/orders (Authorization: Bearer <access_token>)
Gateway → Auth Server: Introspect token (kiểm tra scope "orders:read")
Auth Server → Gateway: {"active": true, "scope": "orders:read", "sub": "user123"}
Gateway → Order Service: Forward request + X-User-ID: user123
Order Service → Gateway: 200 OK + response body
Gateway → Client: 200 OK + response body

API Key Authentication

Đơn giản hơn JWT — phù hợp cho server-to-server API hoặc third-party integrations:

 1
 2> [Tìm hiểu thêm về NGINX và cách cấu hình reverse proxy](/nginx-la-gi/)
 3
 4# NGINX — kiểm tra API key qua header X-API-Key
 5map $http_x_api_key $api_key_valid {
 6    default         0;
 7    "secret-key-A"  1;
 8    "secret-key-B"  1;
 9}
10
11server {
12    location /v1/data/ {
13        if ($api_key_valid = 0) {
14            return 403 '{"error": "Invalid API key"}';
15        }
16        proxy_pass http://data_service/;
17    }
18}

Trong thực tế, API key nên được lưu trong secret store (Vault, AWS Secrets Manager) thay vì hardcode trong config.

Các best practices bảo mật tại gateway

• Chỉ expose HTTPS — tắt HTTP hoặc redirect toàn bộ sang HTTPS.
• Validate input — giới hạn kích thước request body, check Content-Type.
• Hide internal topology — không để service name nội bộ lộ trong response header hay error message.
• Rotate API keys và JWT secrets định kỳ — tích hợp với secret management.
• Enable WAF (Web Application Firewall) cho các gateway expose ra internet — chặn SQLi, XSS, path traversal ở layer gateway.

Use Cases thực tế

Netflix Zuul (API Gateway thế hệ đầu)

Netflix là một trong những đơn vị đầu tiên popularize API Gateway pattern. Zuul (được viết bằng Java, nay đã có Zuul 2 với non-blocking I/O) xử lý hàng tỷ request mỗi ngày, chịu trách nhiệm dynamic routing, monitoring, resiliency (hystrix circuit breaker) và security cho toàn bộ backend services của Netflix.

AWS API Gateway + Lambda (Serverless pattern)

Pattern phổ biến nhất trên AWS cloud: API Gateway nhận HTTP request, trigger Lambda function để xử lý logic nghiệp vụ, không cần server thường trực. Toàn bộ infrastructure được quản lý bởi AWS.

Client → AWS API Gateway → AWS Lambda → DynamoDB
                        ↑
               (auto-scale, auth via Cognito,
                rate-limit via usage plan,
                logging via CloudWatch)

Chi phí rất thấp khi traffic nhỏ (pay-per-request), nhưng cần tính kỹ khi traffic lớn vì chi phí có thể tăng nhanh hơn so với EC2 hay Fargate.

Kong + Kubernetes Ingress

Trong môi trường Kubernetes, Kong thường được deploy dưới dạng Ingress Controller — tích hợp với Kubernetes native (dùng CRD để định nghĩa route) đồng thời giữ nguyên tất cả plugin capabilities của Kong.

 1# Kong Ingress Resource
 2apiVersion: networking.k8s.io/v1
 3kind: Ingress
 4metadata:
 5  name: api-routes
 6  annotations:
 7    konghq.com/plugins: rate-limiting,jwt-auth
 8spec:
 9  ingressClassName: kong
10  rules:
11    - host: api.example.com
12      http:
13        paths:
14          - path: /v1/users
15            pathType: Prefix
16            backend:
17              service:
18                name: user-service
19                port:
20                  number: 8080

JWT là gì? Cách hoạt động của JSON Web Token trong xác thực API