API Gateway là gì? Khác gì Load Balancer, khi nào cần dùng?

API Gateway là máy chủ trung gian đứng giữa client và toàn bộ microservices (các dịch vụ nhỏ, độc lập hợp thành hệ thống) phía sau. Nó tiếp nhận mọi request tại một địa chỉ duy nhất, rồi định tuyến, xác thực và áp chính sách chung trước khi chuyển tới đúng service. Nhưng câu hỏi đáng hỏi không phải “API Gateway có tốt không”. Bởi vì thêm gateway đồng nghĩa thêm một điểm lỗi tập trung, thêm độ trễ, thêm một thành phần phải vận hành.

Câu hỏi đúng là hệ thống của bạn đã đủ phức tạp để việc không có cổng vào tập trung còn tốn kém hơn việc phải gánh những chi phí đó chưa. Bài này giải thích API Gateway khác Load Balancer và Reverse Proxy ở đâu, đảm nhiệm những chức năng nào, và quan trọng nhất: ngưỡng cụ thể nào cho thấy hệ thống thực sự cần nó thay vì thêm cho chắc.

API Gateway là gì?

Nói ngắn gọn, API Gateway đóng vai trò cổng vào duy nhất giữa client và tập hợp microservices phía sau. Nó xử lý các tác vụ dùng chung như xác thực, định tuyến, giới hạn tần suất, rồi mới chuyển request tới đúng service.

Hình dung lại tình huống quen thuộc: một hệ thống thương mại điện tử tách thành nhiều service riêng: Đơn hàng, Thanh toán, Kho, Người dùng. Nếu không có gateway, ứng dụng mobile hoặc web phải biết địa chỉ và gọi riêng từng service. Code phía client rối dần theo thời gian, và mỗi lần thêm một service mới lại là một lần phải sửa phía client. Với API Gateway, ứng dụng chỉ gọi một địa chỉ duy nhất. Gateway lo phần định tuyến còn lại.

API Gateway khác Load Balancer và Reverse Proxy ở điểm nào?

Khác biệt cốt lõi nằm ở mức độ “hiểu” nghiệp vụ, không phải ở việc ai đứng trước ai trong luồng request. Đây là điểm dễ nhầm nhất với người mới làm quen với kiến trúc microservices. Bảng dưới đây so sánh ba thành phần theo mức độ hiểu nghiệp vụ, layer hoạt động và bối cảnh sử dụng:

Reverse proxy (một dạng máy chủ proxy đứng giữa client và server) chuyển tiếp request tới đúng server nhưng không quan tâm request đó gọi API nào, thuộc nghiệp vụ gì. Load balancer phân phối tải giữa nhiều instance của cùng một service để tránh quá tải, nhưng cũng không phân biệt được endpoint hay phiên bản API. API Gateway bao gồm cả hai khả năng đó, cộng thêm nhận thức ngữ cảnh API: route theo endpoint, theo version, áp policy riêng cho từng service phía sau. Nói cách khác, API Gateway hoạt động như một reverse proxy được mở rộng thêm cho kiến trúc microservices, theo mô tả so sánh của ByteByteGo.

Trong hệ thống thực tế, ba thành phần này thường đứng cạnh nhau chứ không loại trừ nhau: API Gateway route theo nghiệp vụ, đứng trước một load balancer phân phối tải cho từng service, còn reverse proxy có thể vẫn đảm nhiệm việc cache nội dung tĩnh ở lớp ngoài cùng.

Cách API Gateway xử lý một request

Một request đi qua bốn chặng theo thứ tự cố định:

1. Client gửi request tới địa chỉ duy nhất của gateway.
2. Gateway xác thực danh tính và kiểm tra giới hạn tần suất (rate limit).
3. Gateway định tuyến request tới đúng service, hoặc gọi nhiều service rồi gộp kết quả lại (API composition) nếu client cần dữ liệu tổng hợp từ nhiều nguồn.
4. Gateway trả response về client.

Bước API composition đáng chú ý nhất vì đây là nơi gateway tạo giá trị vượt ngoài việc chuyển tiếp thuần túy. Gộp nhiều lời gọi API thành một response duy nhất giúp giảm đáng kể thời gian tải trang, đặc biệt trên mạng di động. Lý do là mỗi vòng round-trip (một lượt gửi request và nhận phản hồi) trên mạng di động đều cộng dồn độ trễ, theo phân tích của Oso.

API Gateway đảm nhiệm những chức năng nào?

Bảng dưới đây tóm tắt các chức năng cốt lõi mà một API Gateway đảm nhiệm:

Từng chức năng riêng lẻ trong bảng trên không có gì mới: reverse proxy cũng cache được, load balancer cũng phân phối tải được. Giá trị thật nằm ở việc gộp toàn bộ các mối quan tâm dùng chung này vào một điểm cấu hình duy nhất, thay vì lặp lại rải rác ở từng service.

Trong số các chức năng ở bảng trên, xác thực và phân quyền tập trung quan trọng hơn vẻ ngoài của nó. Đây là chức năng mà hầu hết tài liệu về API Gateway đều liệt kê. Nhưng ít nơi giải thích rõ tại sao nó thường là lý do chính khiến một đội kỹ thuật quyết định thêm gateway.

Nếu không có gateway, mỗi service phải tự cài đặt xác thực riêng: kiểm tra JWT (JSON Web Token, một chuỗi mã hóa dùng để xác thực danh tính), xử lý OAuth2 (giao thức ủy quyền chuẩn), hoặc validate API Key (khóa định danh cho từng ứng dụng gọi API). Việc này vừa lặp code giữa các service, vừa tạo rủi ro thật. Chỉ cần một service mới được thêm vào mà đội phát triển quên implement đúng bước xác thực, service đó trở thành lỗ hổng cho toàn hệ thống. Rủi ro không nằm ở việc thiếu tài liệu, mà ở chỗ mỗi service có thể tự làm sai mà không ai biết.

Gateway giải quyết vấn đề bằng cách xác thực một lần duy nhất tại cổng vào. Các service phía sau tin tưởng rằng request đã qua kiểm tra, nên không cần tự triển khai lại toàn bộ logic xác thực. Cách làm này giảm cả rủi ro bảo mật lẫn khối lượng code trùng lặp. Đổi lại, nó tạo ra một giả định ngầm quan trọng: mọi service phía sau phải tin gateway tuyệt đối. Nếu gateway bị qua mặt, toàn bộ lớp phòng thủ tập trung đó sụp đổ theo.

Ưu điểm và đánh đổi khi thêm API Gateway

Ưu điểm

Lợi ích chính của API Gateway đến từ việc tách bạch hai phía. Phía client chỉ cần biết một địa chỉ duy nhất, còn phía backend được tự do tái cấu trúc, tách hoặc gộp service mà không phá vỡ hợp đồng với client. Các mối quan tâm dùng chung như bảo mật hay giám sát chỉ cần cấu hình một lần tại gateway, thay vì lặp lại ở từng service (nhóm nhu cầu này thường được gọi là cross-cutting concerns).

Đánh đổi phải chấp nhận

Nhưng mọi lợi ích ở trên đều có giá. Gateway giảm độ phức tạp phía client như đã nói ở phần định nghĩa, nhưng đổi lại tăng độ phức tạp phía vận hành hạ tầng. Đây là hai loại phức tạp khác nhau, cái này không thay thế được cái kia. Ba đánh đổi sau không phải rủi ro lý thuyết, mà là chi phí vận hành thật mà một đội kỹ thuật phải chủ động xử lý:

• Điểm lỗi tập trung (single point of failure): gateway sập đồng nghĩa toàn hệ thống sập, trừ khi có cơ chế dự phòng (redundancy). Theo Microsoft Learn, dùng một API Gateway cho kiến trúc microservices tạo thêm một single point of failure tiềm ẩn. Đáng chú ý, bản thân gateway sinh ra để giảm rủi ro phân tán, nhưng lại âm thầm trở thành điểm tập trung mới: mọi quyết định routing, bảo mật và giám sát hệ thống (observability) dồn vào một điểm logic duy nhất, kể cả khi gateway đã scale vật lý ra nhiều instance.
• Thêm độ trễ (latency): mọi request phải đi qua thêm một chặng mạng. Trong đa số trường hợp, chặng thêm này có tác động nhỏ hơn việc để client gọi trực tiếp nhiều service cùng lúc (giao tiếp “chatty”). Nhưng độ trễ sẽ rõ rệt hơn nếu gateway chạy thêm plugin tùy chỉnh hoặc logic nghiệp vụ nặng.
• Thêm một thành phần phải vận hành: gateway cần được giám sát, vá lỗi, nâng cấp như bất kỳ hệ thống production nào khác. Đây là điểm hay bị bỏ qua nhất: thêm gateway là thêm độ phức tạp vận hành, không phải giảm.

Có hai cách giảm nhẹ rủi ro điểm lỗi tập trung:

• Circuit breaker (cơ chế ngắt mạch tự động): khi một service phía sau bắt đầu lỗi hoặc phản hồi chậm, gateway tự động ngắt tạm thời việc gửi request tới service đó. Cách này ngăn lỗi lan ra toàn hệ thống, theo mô tả của Apache APISIX.
• Chia nhỏ theo nghiệp vụ hoặc theo loại client: ví dụ mô hình BFF (Backend for Frontend, gateway riêng cho từng loại client, nói kỹ hơn ở phần cuối bài), để một gateway không phải gánh toàn bộ traffic của cả hệ thống.

Hệ thống của bạn có thực sự cần API Gateway?

Ngưỡng nên cân nhắc thêm

Ba tín hiệu sau cho thấy hệ thống của bạn đã chạm ngưỡng nên cân nhắc thêm API Gateway:

• Số lượng service đã đủ nhiều: hệ thống của bạn khiến client phải quản lý quá nhiều địa chỉ và hợp đồng API khác nhau, và mỗi lần bạn thay đổi backend đều kéo theo sửa đổi phía client.
• Nhiều loại client cùng gọi vào hệ thống của bạn: web, mobile, đối tác bên thứ ba, mỗi loại cần cách bạn xử lý dữ liệu hoặc chính sách khác nhau.
• Cần áp chính sách chung đồng loạt: bảo mật, rate limit hoặc logging phải áp dụng nhất quán cho nhiều service, mà bạn không muốn lặp lại cấu hình ở từng nơi.

Khi nào chưa cần, hoặc nên trì hoãn

Ngược lại, ba dấu hiệu sau cho thấy thêm gateway lúc này là chi phí vận hành thừa, không phải một khoản đầu tư đúng lúc:

• Hệ thống của bạn còn là monolithic hoặc chỉ có vài service, với một loại client duy nhất.
• Đội của bạn chưa có ai chịu trách nhiệm vận hành thêm một thành phần hạ tầng mới. Đây là rủi ro thật: khi gateway gặp sự cố (đúng như rủi ro single point of failure đã nêu ở phần trước), không có ai đủ thẩm quyền hoặc kiến thức để xử lý kịp.
• Bạn đang phân vân giữa có và chưa cần.

Nếu rơi vào trường hợp thứ ba, hãy bắt đầu bằng một reverse proxy đơn giản. Chỉ nâng cấp lên API Gateway đầy đủ khi hệ thống thực sự chạm một trong ba ngưỡng ở phần trên. Bởi vì nâng cấp sớm hơn mức cần thiết đồng nghĩa gánh toàn bộ đánh đổi ở phần trước mà chưa thu được lợi ích tương xứng.

Chọn giải pháp: tự triển khai hay dùng dịch vụ quản lý sẵn?

Self-host (Kong, Nginx, Apache APISIX) so với managed cloud (AWS, GCP, Azure API Gateway)

Bảng dưới đây so sánh hai hướng triển khai theo bốn tiêu chí quyết định: tự vận hành gateway trên hạ tầng của bạn (self-host) so với dùng dịch vụ gateway do nhà cung cấp cloud quản lý sẵn (managed cloud):

Kong Gateway bản mã nguồn mở miễn phí về bản quyền, nhưng chi phí thật nằm ở đội ngũ vận hành, vá lỗi và scale hạ tầng. AWS API Gateway theo mô hình serverless, tính phí khoảng 1 đến 3,5 USD mỗi triệu request tùy loại (HTTP API hoặc REST API), không có chi phí cố định ban đầu, theo bảng giá chính thức của AWS. Ở quy mô nhỏ, managed cloud thường rẻ hơn vì bạn không phải trả cho hạ tầng nhàn rỗi. Ngược lại, theo kinh nghiệm chung trong ngành, khi traffic vượt ngưỡng vài chục triệu request mỗi tháng, chi phí theo request thường bắt đầu vượt chi phí hạ tầng cố định của self-host. Ngưỡng chính xác vẫn phụ thuộc vào loại API và cấu hình hạ tầng của từng hệ thống.

Nói ngắn gọn: self-host phù hợp nếu đội của bạn đã có kinh nghiệm DevOps và cần toàn quyền kiểm soát cấu hình. Self-host cũng hợp lý khi traffic của bạn đủ lớn để chi phí hạ tầng cố định rẻ hơn phí theo request. Managed cloud phù hợp nếu bạn cần dựng nhanh và traffic còn nhỏ đến vừa. Managed cloud cũng hợp lý khi bạn chấp nhận đánh đổi một phần kiểm soát lẫn rủi ro vendor lock-in để giảm gánh nặng vận hành.

Tự triển khai ở đâu?

Nếu chọn hướng self-host, gateway cần chạy trên một server luôn bật và ổn định, tách biệt khỏi các service backend để tránh cạnh tranh tài nguyên. Kong hay Nginx Gateway thường được triển khai trên một VPS hoặc Cloud Server riêng cho đúng mục đích này.

API Gateway là một vai trò, không phải một sản phẩm bắt buộc

Câu hỏi đúng không phải “có nên dùng API Gateway” mà là “hệ thống đã tới ngưỡng cần một cổng vào tập trung chưa”. Câu trả lời phụ thuộc vào ba yếu tố đã nêu ở phần trước: số lượng service, số loại client, và nhu cầu áp chính sách chung. Trả lời sai câu hỏi này theo hướng “thêm cho chắc” nghĩa là bạn gánh cả ba đánh đổi (điểm lỗi tập trung, độ trễ, chi phí vận hành) mà không thu lại lợi ích tương xứng.

Một biến thể đáng biết tiếp theo là Backend for Frontend (BFF). Khi hệ thống có nhiều loại client (web, mobile) với nhu cầu dữ liệu khác nhau, một gateway chung đôi khi không tối ưu cho cả hai: mobile cần response gọn nhẹ, web có thể cần dữ liệu chi tiết hơn. BFF là biến thể tạo một gateway riêng cho từng loại client, thay vì ép tất cả dùng chung một cấu hình.

Dù bạn chọn API Gateway thuần hay biến thể BFF, nếu đang thử nghiệm triển khai Kong hoặc Nginx Gateway theo hướng self-host, gateway cần một nơi chạy ổn định, tách biệt khỏi service backend, trước khi bạn quyết định đầu tư dài hạn cho hạ tầng đó. Cloud VPS của Tenten.vn hỗ trợ cấu hình linh hoạt theo tải và tính phí theo giờ. Bạn có thể dùng nó để chạy thử nghiệm cấu hình gateway ở quy mô nhỏ, trước khi mở rộng theo tải thật.

Các câu hỏi thường gặp về API Gateway

API Gateway có phải là Load Balancer không?

Không. Load Balancer chỉ phân phối tải giữa nhiều instance của cùng một service, không hiểu ngữ cảnh API. API Gateway hiểu route, version và áp policy riêng cho từng service, nên có thể xem là vai trò rộng hơn bao gồm cả năng lực phân phối tải.

Dự án nhỏ, ít service có cần API Gateway không?

Thường là chưa cần. Nếu hệ thống còn monolithic hoặc chỉ vài service với một loại client duy nhất, thêm gateway là chi phí vận hành thừa. Hãy bắt đầu bằng reverse proxy đơn giản và chỉ nâng cấp khi chạm ngưỡng nêu ở phần trên.

API Gateway có làm chậm hệ thống không?

Có, vì mọi request đi qua thêm một chặng mạng. Nhưng độ trễ này thường nhỏ hơn tác động của việc client gọi trực tiếp nhiều service, và có thể giảm thêm bằng caching hoặc scale gateway đúng cách.

Nên chọn Kong, Nginx hay AWS API Gateway?

Tùy quy mô đội và mức độ bạn cần kiểm soát. Nếu đội của bạn đã có kinh nghiệm DevOps và cần toàn quyền cấu hình, hãy chọn self-host; nếu bạn cần dựng nhanh và chấp nhận trả phí theo request, hãy chọn managed cloud như AWS API Gateway.

API Gateway có thay thế được hệ thống quản lý người dùng không?

Không hoàn toàn. Gateway có thể xử lý xác thực tập trung tại cổng vào, nhưng vẫn cần một hệ thống quản lý người dùng (Authentication Service) riêng để lưu trữ danh tính và cấp token.

API Gateway và Backend for Frontend (BFF) khác nhau thế nào?

BFF là một gateway chuyên biệt, dựng riêng cho từng loại client (web, mobile), không phải khái niệm thay thế API Gateway. Nhiều hệ thống dùng cả hai: một BFF cho mỗi loại client, đứng trước một API Gateway chung ở lớp sâu hơn.