Kiến trúc API gateway và các tính năng chính (hướng dẫn 2026)
API gateway là một điểm vào duy nhất nằm giữa client và các dịch vụ backend: nó nhận mọi request, áp dụng chính sách bảo mật và lưu lượng, rồi chuyển request đến đúng dịch vụ. Kiến trúc của nó gồm hai phần: data plane xử lý lưu lượng thực (định tuyến, xác thực, giới hạn tốc độ, biến đổi, cache, ghi log) và control plane nơi bạn cấu hình các chính sách đó. Những tính năng chính cần quan tâm là định tuyến, xác thực và phân quyền, rate limiting, biến đổi request và response, cache, khả năng quan sát và các cơ chế chịu lỗi như timeout, retry và circuit breaker.
Hướng dẫn này trình bày kiến trúc API gateway bằng sơ đồ, giải thích từng thành phần và tính năng, so sánh các mô hình triển khai và sản phẩm phổ biến, đồng thời cung cấp cấu hình và mã chạy được. Phần cuối cho thấy cùng kiến trúc đó áp dụng như thế nào cho gateway dành cho API mô hình ngôn ngữ lớn (LLM). Thông tin sản phẩm lấy từ tài liệu chính thức, kiểm tra ngày 24/10/2026.
API gateway là gì?
Trong hệ thống microservices không có gateway, client sẽ phải biết địa chỉ, giao thức và cơ chế xác thực của từng dịch vụ. Mẫu API gateway đặt một thành phần duy nhất phía trước chúng. Client gọi gateway, và gateway quyết định mỗi request đi đâu và áp dụng quy tắc nào.
Không có gateway, mỗi dịch vụ phải tự triển khai lại xác thực, giới hạn tốc độ và ghi log, và mọi client phải thay đổi khi một dịch vụ di chuyển. Có gateway, các mối quan tâm xuyên suốt này nằm ở một chỗ, và các dịch vụ có thể thay đổi phía sau một API công khai ổn định.
Sơ đồ kiến trúc API gateway
Clients (web, mobile, partners, internal jobs)
|
v
[ DNS / CDN / WAF / Load balancer ]
|
v
+--------------------- API GATEWAY (data plane) ---------------------+
| TLS termination -> AuthN/AuthZ -> Rate limit & quota -> |
| Request validation & transform -> Cache lookup -> Router |
| -> Timeouts / retries / circuit breaker -> Response transform |
| -> Logs, metrics, traces |
+--------------------------------------------------------------------+
| | |
v v v
Orders service Users service Payments service (or Lambda, queues, LLM providers)
Control plane: config store, admin API/UI, policy and key management, deploys config to data plane
Các thành phần cốt lõi
| Thành phần | Vai trò |
|---|---|
| Listener / kết thúc TLS | Nhận kết nối HTTP/1.1, HTTP/2, gRPC hoặc WebSocket và giải mã TLS |
| Xác thực và phân quyền | Kiểm tra API key, token OAuth 2.0 / JWT hoặc chứng chỉ mTLS, sau đó kiểm tra quyền |
| Bộ giới hạn tốc độ và hạn mức | Giới hạn request theo client, key hoặc route; trả về HTTP 429 khi vượt ngưỡng |
| Kiểm tra và biến đổi request | Kiểm tra schema, viết lại đường dẫn và header, chuyển đổi giao thức (ví dụ REST sang gRPC) |
| Cache | Trả về các response lặp lại mà không cần gọi backend |
| Bộ định tuyến | Ánh xạ đường dẫn, phương thức, host hoặc header tới dịch vụ upstream và cân bằng tải giữa các instance |
| Lớp chịu lỗi | Timeout, retry có backoff, circuit breaker và fallback |
| Khả năng quan sát | Access log, metric (độ trễ, tỷ lệ lỗi) và trace phân tán |
| Control plane | Lưu cấu hình và đẩy xuống các instance gateway; cung cấp admin API hoặc giao diện quản trị |
Vòng đời của một request
- Client gửi
GET /orders/42kèm bearer token. - Gateway kết thúc TLS và xác thực token.
- Kiểm tra rate limit và hạn mức của bên gọi.
- Kiểm tra request và thêm các header như request ID.
- Kiểm tra cache; nếu không có, định tuyến đến một instance
ordersđang hoạt động tốt. - Áp dụng timeout, retry một lần khi lỗi kết nối và ghi lại kết quả.
- Biến đổi response nếu cần rồi trả về, ghi log trạng thái, độ trễ và bên gọi.
Các tính năng chính của API gateway
Đây là những tính năng mà hầu hết các nhóm cần, xếp gần đúng theo mức độ quan trọng:
- Định tuyến request. Định tuyến theo đường dẫn, host, phương thức và header, cùng cân bằng tải và phát hành canary hoặc theo trọng số.
- Xác thực và phân quyền. API key, xác thực OAuth 2.0 và JWT, mTLS và chính sách truy cập theo từng route.
- Rate limiting và hạn mức. Giới hạn theo từng consumer để bảo vệ backend; mã HTTP 429 "Too Many Requests" được định nghĩa trong RFC 6585.
- Biến đổi request và response. Chèn header, ánh xạ payload, chuyển đổi giao thức và quản lý phiên bản API.
- Cache. Cache response có TTL để giảm độ trễ và tải cho backend.
- Bảo mật. TLS, danh sách IP cho phép và chặn, giới hạn kích thước request và tích hợp với tường lửa ứng dụng web (WAF).
- Khả năng quan sát. Access log có cấu trúc, metric và lan truyền trace đến các công cụ như Grafana Tempo hoặc Datadog.
- Khả năng chịu lỗi. Timeout, retry, circuit breaker và health check.
- Trải nghiệm nhà phát triển. API key và gói dịch vụ, cổng thông tin nhà phát triển và phân tích sử dụng; thường được gộp chung là "API management".
- Kiếm tiền và đo lường. Đếm lượng sử dụng theo từng consumer để tính phí hoặc phân bổ chi phí nội bộ.
Các mô hình triển khai
| Mô hình | Cách hoạt động | Khi nào dùng |
|---|---|---|
| Một gateway trung tâm | Một cụm gateway phục vụ tất cả dịch vụ | Hệ thống nhỏ đến vừa, một nhóm quản lý lớp biên |
| Backend for frontend (BFF) | Mỗi loại client (web, mobile, đối tác) có gateway riêng | Các client cần API rất khác nhau |
| Gateway theo domain | Mỗi domain nghiệp vụ chạy gateway riêng | Tổ chức lớn với các nhóm tự chủ |
| Kubernetes Ingress / Gateway API | Gateway được cấu hình bằng tài nguyên Kubernetes | Dịch vụ đã chạy trên Kubernetes |
| Gateway kết hợp service mesh | Gateway xử lý lưu lượng bắc–nam (client), mesh xử lý đông–tây (giữa các dịch vụ) | Nhiều dịch vụ nội bộ cần mTLS và chính sách lưu lượng |
Kubernetes Gateway API hiện là cách tiêu chuẩn để cấu hình gateway trên Kubernetes, và các triển khai như Envoy Gateway được xây dựng trên nó.
API gateway, load balancer và service mesh khác nhau thế nào
- Load balancer phân phối lưu lượng giữa các instance của một dịch vụ, chủ yếu ở tầng mạng hoặc HTTP, không có chính sách nhận biết API.
- API gateway hiểu API: nó xác thực consumer, áp dụng hạn mức theo key, biến đổi payload và định tuyến qua nhiều dịch vụ.
- Service mesh quản lý lưu lượng giữa các dịch vụ nội bộ, thường thông qua sidecar hoặc proxy trên từng node.
Hầu hết hệ thống production dùng load balancer phía trước gateway, một số thêm mesh phía sau.
Các sản phẩm API gateway phổ biến
| Sản phẩm | Loại | Ghi chú (tháng 10/2026) |
|---|---|---|
| Amazon API Gateway | Dịch vụ quản lý (AWS) | API REST, HTTP và WebSocket; gói miễn phí gồm 1 triệu lượt gọi REST, 1 triệu lượt gọi HTTP, 1 triệu tin nhắn WebSocket và 750.000 phút kết nối mỗi tháng trong 12 tháng |
| Kong Gateway | Mã nguồn mở và enterprise | Dựa trên plugin; chạy không cần cơ sở dữ liệu (DB-less) với cấu hình khai báo hoặc có cơ sở dữ liệu |
| Envoy Gateway | Mã nguồn mở | Proxy Envoy được quản lý qua Kubernetes Gateway API |
| Azure API Management | Dịch vụ quản lý (Azure) | Gateway được quản lý và tự host, cùng cổng thông tin nhà phát triển |
Ví dụ: cấu hình khai báo của Kong
Cấu hình Kong DB-less này định tuyến /orders đến một backend, yêu cầu API key và giới hạn mỗi consumer ở 60 request mỗi phút:
_format_version: "3.0"
services:
- name: orders
url: http://orders:8080
routes:
- name: orders-route
paths: ["/orders"]
plugins:
- name: key-auth
- name: rate-limiting
config:
minute: 60
policy: local
consumers:
- username: mobile-app
keyauth_credentials:
- key: replace-with-a-long-random-key
Ví dụ: một gateway tối giản bằng Python
Để thấy kiến trúc dưới dạng mã, đây là một gateway nhỏ chạy được, có xác thực API key, giới hạn tốc độ theo key, định tuyến và timeout. Nó dùng để học; hãy dùng gateway production cho lưu lượng thực.
# pip install fastapi uvicorn httpx ; run: uvicorn gateway:app --port 8080
import time, httpx
from collections import defaultdict
from fastapi import FastAPI, Request, Response, HTTPException
ROUTES = {"/orders": "http://localhost:9001", "/users": "http://localhost:9002"}
KEYS = {"key-mobile": "mobile-app"}
LIMIT_PER_MIN = 60
hits = defaultdict(list)
app = FastAPI()
@app.api_route("/{path:path}", methods=["GET", "POST", "PUT", "DELETE"])
async def gateway(path: str, request: Request):
consumer = KEYS.get(request.headers.get("x-api-key", ""))
if not consumer:
raise HTTPException(401, "invalid API key")
now = time.time()
hits[consumer] = [t for t in hits[consumer] if now - t < 60]
if len(hits[consumer]) >= LIMIT_PER_MIN:
raise HTTPException(429, "rate limit exceeded", headers={"Retry-After": "60"})
hits[consumer].append(now)
prefix = next((p for p in ROUTES if f"/{path}".startswith(p)), None)
if not prefix:
raise HTTPException(404, "no route")
async with httpx.AsyncClient(timeout=5.0) as client:
upstream = await client.request(request.method, ROUTES[prefix] + f"/{path}"[len(prefix):],
content=await request.body(),
headers={"x-consumer": consumer})
return Response(upstream.content, upstream.status_code,
media_type=upstream.headers.get("content-type"))
Từ API gateway đến LLM gateway
Khi backend là các nhà cung cấp mô hình AI thay vì microservices, kiến trúc vẫn như cũ nhưng có thêm vài nhiệm vụ. LLM gateway (hay AI gateway) bổ sung:
| Tính năng gateway truyền thống | Mở rộng của LLM gateway |
|---|---|
| Định tuyến theo đường dẫn | Định tuyến theo tên mô hình, chi phí, độ trễ hoặc tình trạng nhà cung cấp |
| Giới hạn theo số request | Giới hạn theo token mỗi phút và chi tiêu theo key |
| Biến đổi request | Chuyển đổi giữa định dạng request của OpenAI, Anthropic và Gemini |
| Cache response | Prompt caching và cache ngữ nghĩa |
| Retry và circuit breaker | Fallback sang nhà cung cấp hoặc mô hình khác khi gặp 429, 5xx hoặc timeout |
| Access log | Số token, chi phí mỗi request và mô hình đã dùng |
| API key theo consumer | Một key dùng cho nhiều nhà cung cấp, kèm ngân sách theo nhóm |
App / agent --OpenAI-format request--> LLM gateway
auth + budget check -> model map -> route (primary provider)
-> on 429/5xx/timeout: fallback provider -> usage + cost log
-> Anthropic / OpenAI / Google / DeepSeek / self-hosted vLLM
Bạn có thể tự vận hành lớp này (ví dụ với LiteLLM hoặc các plugin AI của Kong) hoặc dùng dịch vụ được quản lý. Flatkey là một lựa chọn được quản lý: một endpoint tương thích OpenAI tại https://router.flatkey.ai/v1, một key cho hơn 300 mô hình, log sử dụng với token và chi phí cho từng lượt gọi, cùng giới hạn chi tiêu theo key hoặc nhóm, theo tài liệu của Flatkey tính đến tháng 10/2026. Vì dùng định dạng OpenAI, các client hiện có chỉ cần đổi base URL:
curl https://router.flatkey.ai/v1/chat/completions \
-H "Authorization: Bearer $FLATKEY_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"claude-sonnet-5-5","messages":[{"role":"user","content":"Summarize the API gateway pattern in one sentence."}]}'
Để thiết kế sâu hơn, hãy đọc các hướng dẫn của chúng tôi về kiến trúc AI API gateway và định tuyến mô hình, circuit breaker cho LLM gateway, AI gateway so với API management và AI gateway được quản lý so với proxy tự host. Nếu bạn mới tìm hiểu chủ đề này, hướng dẫn LLM gateway cho người mới là điểm khởi đầu tốt, còn hướng dẫn xử lý rate limit trình bày các chiến lược xử lý lỗi 429.
Danh sách kiểm tra khi thiết kế
- Đặt TLS, xác thực và rate limiting tại gateway, không phải ở từng dịch vụ.
- Đặt timeout cho mọi route upstream; đừng bao giờ chờ vô thời hạn.
- Chỉ retry các request idempotent (GET, PUT, DELETE theo RFC 9110), trừ khi backend hỗ trợ idempotency key.
- Truyền request ID và ngữ cảnh trace đến mọi backend.
- Chạy ít nhất hai instance gateway sau load balancer để gateway không trở thành điểm lỗi duy nhất.
- Không đưa logic nghiệp vụ vào gateway; gateway áp dụng chính sách chứ không triển khai tính năng.
- Quản lý phiên bản cấu hình gateway bằng git và triển khai dưới dạng mã.
Câu hỏi thường gặp
Mẫu API gateway trong microservices là gì?
Đó là thiết kế trong đó một gateway duy nhất là điểm vào cho mọi request từ client. Gateway định tuyến từng request đến đúng microservice và xử lý các mối quan tâm chung như xác thực, rate limiting và ghi log, nên client không gọi trực tiếp các dịch vụ.
Các tính năng chính của API gateway là gì?
Các tính năng cốt lõi là định tuyến request, xác thực và phân quyền, rate limiting và hạn mức, biến đổi request và response, cache, kiểm soát bảo mật, khả năng quan sát và các tính năng chịu lỗi như timeout, retry và circuit breaker.
Kiến trúc API gateway gồm những thành phần chính nào?
Một data plane xử lý lưu lượng (listener, xác thực, bộ giới hạn tốc độ, bộ biến đổi, cache, bộ định tuyến, lớp chịu lỗi và telemetry) và một control plane lưu trữ và phân phối cấu hình.
API gateway có giống load balancer không?
Không. Load balancer phân phối lưu lượng giữa các instance của một dịch vụ. API gateway bổ sung các tính năng nhận biết API như xác thực theo consumer, hạn mức, biến đổi payload và định tuyến qua nhiều dịch vụ. Hầu hết hệ thống dùng cả hai.
LLM gateway là gì?
LLM gateway là API gateway chuyên cho lưu lượng mô hình AI. Nó định tuyến theo mô hình và nhà cung cấp, giới hạn theo token và chi tiêu, chuyển đổi giữa các định dạng API của nhà cung cấp, fallback khi nhà cung cấp gặp sự cố và ghi log lượng token sử dụng cùng chi phí.
API gateway có phải là điểm lỗi duy nhất không?
Có thể, nếu bạn chỉ chạy một instance. Hãy chạy nhiều instance trên nhiều zone sau load balancer, lưu cấu hình trong kho lưu trữ có sao chép và giám sát chính gateway.
