Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn xây dựng một ứng dụng giao đồ ăn kiểu ShopeeFood hay Baemin. Ban đầu, ứng dụng chỉ có một backend duy nhất, mọi thứ gọn gàng. Nhưng khi lớn lên, bạn tách nó thành hàng chục microservice: dịch vụ đăng nhập, dịch vụ đơn hàng, dịch vụ thanh toán, dịch vụ theo dõi tài xế, dịch vụ khuyến mãi... Mỗi service chạy trên một địa chỉ riêng, cổng riêng, có thể nằm ở nhiều máy chủ khác nhau.
Câu hỏi đặt ra: ứng dụng di động của khách hàng phải gọi vào đâu? Nếu app phải nhớ hàng chục địa chỉ IP, tự xử lý đăng nhập cho từng service, tự giới hạn số lần gọi... thì đó là một cơn ác mộng. Mỗi khi bạn đổi kiến trúc bên trong, app lại phải cập nhật. Đây chính là bài toán mà API Gateway ra đời để giải quyết.
API Gateway là một trong những thành phần nền tảng nhất của kiến trúc cloud hiện đại. Nó đứng ở "cửa ngõ" giữa thế giới bên ngoài (app di động, web, đối tác) và hệ thống backend bên trong. Trong khóa học này, khi bạn đã hiểu về compute, storage, message queue ở các bài trước, thì API Gateway chính là mảnh ghép giúp phơi bày (expose) toàn bộ những thứ đó ra ngoài một cách an toàn và có kiểm soát. Nắm vững nó, bạn sẽ hiểu được cách các hệ thống lớn như Grab, Momo, Tiki tổ chức tầng giao tiếp của mình.
Khái niệm cốt lõi
API Gateway là gì
API Gateway là một dịch vụ đóng vai trò điểm vào duy nhất (single entry point) cho tất cả các yêu cầu (request) từ client đến hệ thống backend. Thay vì client gọi trực tiếp vào từng microservice, mọi request đều đi qua Gateway trước. Gateway nhận request, xử lý một loạt tác vụ chung, rồi định tuyến (route) đến đúng service phía sau, cuối cùng gom kết quả trả về cho client.
Bạn có thể hình dung Gateway như lễ tân của một tòa nhà văn phòng lớn. Khách đến không tự ý đi vào từng phòng ban. Họ phải qua quầy lễ tân: được kiểm tra danh tính, phát thẻ, hướng dẫn lên đúng tầng, và nếu quá đông thì phải xếp hàng chờ. Backend service giống như các phòng ban bên trong, còn lễ tân chính là API Gateway.
Ba loại API phổ biến Gateway hỗ trợ
Tiêu đề bài học nhắc đến ba kiểu API mà một Gateway hiện đại thường phục vụ. Hiểu rõ khác biệt giúp bạn chọn đúng công cụ:
REST API là kiểu truyền thống và phổ biến nhất. Client gửi request theo các phương thức HTTP (GET, POST, PUT, DELETE) tới các "tài nguyên" có cấu trúc rõ ràng như /orders/123. REST API thường đi kèm nhiều tính năng nâng cao: kiểm tra dữ liệu đầu vào theo schema, chuyển đổi định dạng request/response, tạo tài liệu tự động. Trên AWS, đây là loại "REST API" trong dịch vụ API Gateway.
HTTP API là phiên bản nhẹ hơn, nhanh hơn và rẻ hơn của REST API (AWS ra mắt để tối ưu chi phí). Nó bỏ bớt một số tính năng nâng cao để đổi lấy độ trễ thấp và giá thành thấp hơn khoảng 70%. Với đa số ứng dụng chỉ cần định tuyến và xác thực cơ bản, HTTP API là lựa chọn hợp lý.
WebSocket API phục vụ giao tiếp hai chiều, thời gian thực. Khác với REST/HTTP (client hỏi, server trả rồi đóng kết nối), WebSocket giữ một kết nối mở liên tục để server có thể chủ động đẩy dữ liệu về client. Đây là nền tảng cho tính năng chat, thông báo tức thời, theo dõi vị trí tài xế trên bản đồ theo thời gian thực, hay bảng giá chứng khoán cập nhật liên tục.
Những việc API Gateway đảm nhận
Giá trị lớn nhất của Gateway là gom các mối quan tâm chung (cross-cutting concerns) về một chỗ, thay vì bắt mỗi service tự lo:
- Định tuyến (routing): Nhìn vào đường dẫn và phương thức của request để chuyển đến đúng service. Ví dụ
/orders/đi tới order-service,/payments/đi tới payment-service. - Xác thực và phân quyền (AuthN/Z): Đây là điểm cực kỳ quan trọng. Gateway kiểm tra JWT (JSON Web Token — một chuỗi token chứa thông tin người dùng đã được ký), API key (khóa định danh cấp cho đối tác), hoặc luồng OAuth. Nhờ vậy, các service phía sau không cần lặp lại logic đăng nhập — chúng tin rằng request đã qua Gateway là đã được xác thực.
- Rate limiting và throttling: Giới hạn số request mỗi client được gửi trong một khoảng thời gian. "Rate limiting" là đặt trần cứng (ví dụ 100 request/phút), còn "throttling" là làm chậm/xếp hàng khi vượt ngưỡng. Đây là tấm khiên chống lạm dụng và bảo vệ backend khỏi bị quá tải.
- Chuyển đổi request/response: Sửa header, đổi định dạng, gộp nhiều lời gọi thành một.
- Ghi log, đo lường (metrics), giám sát: Vì mọi traffic đều đi qua đây, Gateway là nơi lý tưởng để thu thập số liệu.
- Caching: Lưu tạm kết quả của các request lặp lại để giảm tải backend.
Các sản phẩm thực tế
Trên các cloud lớn: Amazon API Gateway (AWS), API Gateway / Apigee (GCP), Azure API Management (Microsoft). Ngoài ra có các giải pháp mã nguồn mở tự vận hành như Kong, KrakenD, Tyk, và NGINX. Ở Việt Nam, nhiều đội kỹ thuật của FPT, VNG, Viettel dùng Kong hoặc NGINX vì có thể triển khai trên hạ tầng nội bộ, chủ động về dữ liệu và chi phí.
Tình huống thực tế
Ví dụ 1: Sàn thương mại điện tử "ChoTot Express" mở API cho đối tác
Giả sử một sàn TMĐT tại TP.HCM tên ChoTot Express muốn cho các shop lớn tích hợp hệ thống kho của họ vào sàn. Họ cần mở API cho khoảng 500 đối tác. Vấn đề: mỗi đối tác có mức độ tin cậy khác nhau, và họ không muốn một đối tác nào đó (vô tình hay cố ý) bắn 100.000 request/phút làm sập hệ thống.
Đội kỹ thuật đặt Amazon API Gateway ở phía trước. Mỗi đối tác được cấp một API key riêng, gắn với một usage plan (gói sử dụng): đối tác hạng thường được 1.000 request/phút, đối tác hạng vàng được 10.000 request/phút. Gateway tự động từ chối (trả về mã lỗi HTTP 429 — "Too Many Requests") khi ai đó vượt ngưỡng. Ngoài ra, Gateway xác thực API key trước, nên order-service phía sau không bao giờ nhận request rác.
Bài học rút ra: Rate limiting theo từng client không chỉ là kỹ thuật chống tấn công, mà còn là công cụ kinh doanh — bạn có thể bán các gói API cao cấp hơn với hạn mức cao hơn. API Gateway biến "giới hạn truy cập" thành một sản phẩm.
Ví dụ 2: Ứng dụng gọi xe theo dõi tài xế thời gian thực
Một startup gọi xe ở Đông Nam Á cần hiển thị vị trí tài xế di chuyển mượt mà trên bản đồ khi khách đang chờ. Nếu dùng REST API, app phải "hỏi" server mỗi giây một lần (polling) — vừa tốn pin, vừa tốn băng thông, vừa trễ. Với hàng trăm nghìn chuyến xe đồng thời, cách này tạo ra hàng triệu request thừa mỗi phút.
Họ chuyển sang WebSocket API của API Gateway. Khi khách mở màn hình theo dõi, app mở một kết nối WebSocket duy nhất và giữ mở. Mỗi khi GPS của tài xế cập nhật, hệ thống backend đẩy tọa độ mới xuống qua kết nối đó — không cần app phải hỏi. Kết quả: độ trễ giảm từ trung bình 1 giây xuống dưới 200 mili-giây, và lượng request giảm hơn 90%.
Bài học rút ra: Chọn đúng loại API quyết định trải nghiệm. Với dữ liệu thời gian thực, WebSocket vượt trội so với việc gọi REST liên tục. API Gateway hỗ trợ cả hai, nên bạn có thể dùng REST cho phần đặt xe và WebSocket cho phần theo dõi, trong cùng một hệ thống.
Ví dụ 3: Ngân hàng số hợp nhất xác thực qua Gateway
Một ngân hàng số tại Hà Nội có 12 microservice: tài khoản, chuyển tiền, sổ tiết kiệm, thẻ tín dụng, lịch sử giao dịch... Ban đầu, mỗi service tự viết code kiểm tra JWT. Hậu quả: khi có lỗ hổng bảo mật trong logic xác thực, họ phải sửa và triển khai lại 12 chỗ, mất nhiều ngày và rủi ro cao vì dễ sót.
Họ tái cấu trúc: đặt Kong Gateway ở cửa ngõ, dùng một custom authorizer (bộ xác thực tùy biến) tập trung tại Gateway để validate JWT, kiểm tra chữ ký và thời hạn token. Các service phía sau chỉ đọc thông tin người dùng đã được Gateway giải mã và gắn vào header. Giờ đây, khi cần thay đổi chính sách bảo mật, họ chỉ sửa một nơi.
Bài học rút ra: Tập trung hóa xác thực tại Gateway giảm bề mặt tấn công và giảm chi phí bảo trì đáng kể. Tuy nhiên, đừng tin tưởng mù quáng — các service nhạy cảm về tiền bạc vẫn nên có thêm lớp kiểm tra riêng (defense in depth).
Hướng dẫn từng bước
Dưới đây là quy trình thiết kế và triển khai một API Gateway cho một hệ thống thực tế, minh họa bằng Amazon API Gateway nhưng nguyên tắc áp dụng cho mọi nền tảng:
- Xác định loại API cần dùng. Đặt câu hỏi: giao tiếp là request-response một chiều hay cần thời gian thực hai chiều? Nếu một chiều và cần tối ưu chi phí, chọn HTTP API. Nếu cần tính năng nâng cao (validate schema, transform), chọn REST API. Nếu cần realtime, chọn WebSocket API.
- Thiết kế cấu trúc route và resource. Vẽ sơ đồ các đường dẫn:
/v1/orders,/v1/orders/{id},/v1/payments. Luôn đưa số phiên bản (/v1/) vào ngay từ đầu để sau này nâng cấp không phá vỡ client cũ.
- Kết nối route tới backend (integration). Với mỗi route, chỉ định nơi request sẽ được chuyển đến: một hàm serverless, một load balancer, hay một service qua HTTP. Đây là bước "đấu dây" giữa Gateway và hệ thống của bạn.
- Cấu hình xác thực. Bật authorizer cho các route cần bảo vệ. Chọn cơ chế: JWT authorizer cho người dùng cuối, API key cho đối tác, hoặc IAM cho service nội bộ. Để công khai một số route (như trang chủ), bạn có thể để chúng không cần xác thực.
- Đặt giới hạn rate limiting và throttling. Cấu hình hạn mức mặc định cho toàn Gateway, rồi tạo các usage plan riêng cho từng nhóm client. Luôn có một mức trần chung để bảo vệ backend.
- Bật logging, metrics và tracing. Cho phép Gateway ghi log truy cập và đẩy số liệu lên hệ thống giám sát. Bạn sẽ cần dữ liệu này khi có sự cố (các bài sau trong khóa sẽ nói kỹ về monitoring và tracing).
- Bật cache nếu phù hợp. Với các endpoint trả về dữ liệu ít thay đổi (danh mục sản phẩm, cấu hình), bật cache để giảm tải và tăng tốc.
- Kiểm thử và triển khai theo stage. Deploy lên môi trường staging trước, chạy thử tải (load test), rồi mới đưa lên production. API Gateway thường có khái niệm "stage" (dev, staging, prod) để bạn tách biệt các môi trường.
Lỗi thường gặp & mẹo
Biến Gateway thành "God object". Nhiều đội nhồi quá nhiều logic nghiệp vụ vào Gateway — tính toán, xử lý dữ liệu phức tạp. Đừng. Gateway chỉ nên lo các tác vụ hạ tầng chung: routing, auth, rate limit, transform nhẹ. Logic nghiệp vụ thuộc về các service. Nếu không, Gateway trở thành nút thắt cổ chai và điểm chết duy nhất của cả hệ thống.
Quên rằng Gateway là single point of failure. Vì mọi traffic đi qua đây, nếu Gateway sập thì cả hệ thống sập. Luôn triển khai Gateway có tính sẵn sàng cao, phân tán qua nhiều vùng khả dụng (multi-AZ). Các dịch vụ managed như Amazon API Gateway đã lo sẵn phần này, nhưng nếu bạn tự vận hành Kong/NGINX thì phải tự thiết kế dự phòng.
Đặt rate limit quá chặt hoặc quá lỏng. Quá chặt thì chặn nhầm người dùng thật vào giờ cao điểm (nghĩ đến đợt sale 12/12). Quá lỏng thì không bảo vệ được gì. Mẹo: theo dõi số liệu thực tế trong vài tuần, rồi đặt ngưỡng dựa trên dữ liệu, và luôn có cơ chế cảnh báo khi lượng request tăng đột biến.
Bỏ qua timeout. Nếu một backend service treo, request qua Gateway cũng treo theo, làm cạn kiệt tài nguyên. Luôn đặt timeout hợp lý cho mỗi integration (ví dụ 29 giây là giới hạn của Amazon API Gateway) và có cơ chế fallback.
Không quản lý phiên bản. Đổi cấu trúc response mà không có versioning sẽ làm hỏng các app đang chạy. Luôn dùng /v1/, /v2/ và cho phép hai phiên bản chạy song song trong giai đoạn chuyển tiếp.
Mẹo về chi phí: Với AWS, nếu không cần tính năng nâng cao, dùng HTTP API thay vì REST API để tiết kiệm khoảng 70% chi phí. Với lưu lượng cực lớn và ổn định, tự vận hành Kong/NGINX trên VM có thể rẻ hơn managed service — đây là bài toán đánh đổi giữa chi phí và công sức vận hành.
Bài tập thực hành
- Thiết kế trên giấy: Vẽ sơ đồ API Gateway cho một ứng dụng đặt lịch khám bệnh online có 4 service: đăng nhập, tìm bác sĩ, đặt lịch, thanh toán. Xác định route nào cần xác thực JWT, route nào công khai, và đặt rate limit hợp lý cho từng nhóm.
- Chọn loại API: Với mỗi tính năng sau, hãy chọn REST, HTTP hay WebSocket API và giải thích: (a) lấy danh sách bác sĩ, (b) chat trực tiếp với tổng đài, (c) nhận thông báo khi có lịch trống.
- Triển khai thực tế (nâng cao): Nếu có tài khoản AWS free tier, tạo một HTTP API kết nối tới một hàm serverless đơn giản trả về "Xin chào". Sau đó thêm một API key và usage plan giới hạn 5 request/phút, rồi dùng công cụ gửi request liên tục để quan sát Gateway trả về lỗi 429.
- Phân tích tình huống: Đọc lại Ví dụ 3 (ngân hàng số). Hãy liệt kê 3 lý do vì sao các service liên quan đến tiền vẫn nên tự kiểm tra thêm dù đã có Gateway xác thực. Gợi ý: nghĩ về defense in depth và rủi ro nội bộ.
Tóm tắt
API Gateway là điểm vào duy nhất đứng giữa client và các microservice, giúp che giấu sự phức tạp bên trong và tập trung hóa các tác vụ chung. Ba trách nhiệm cốt lõi bạn cần nhớ: định tuyến request đến đúng service, xác thực và phân quyền (JWT, API key, OAuth) để backend không phải lặp lại, và rate limiting/throttling để bảo vệ hệ thống cũng như tạo ra các gói dịch vụ.
Gateway hiện đại phục vụ ba loại API: REST (đầy đủ tính năng), HTTP (nhẹ, rẻ, nhanh), và WebSocket (thời gian thực hai chiều) — chọn đúng loại quyết định trải nghiệm và chi phí. Các sản phẩm phổ biến gồm Amazon API Gateway, Apigee, Azure API Management, và Kong/NGINX cho triển khai tự chủ.
Cuối cùng, hãy nhớ những cạm bẫy: đừng nhồi logic nghiệp vụ vào Gateway, đừng quên nó là single point of failure nên phải có dự phòng, và luôn quản lý phiên bản, timeout, cùng rate limit dựa trên dữ liệu thực tế. Nắm vững API Gateway, bạn đã có trong tay mảnh ghép then chốt để xây dựng những hệ thống cloud vừa an toàn, vừa dễ mở rộng như các nền tảng lớn tại Việt Nam và khu vực.