API Gateway: Anh gác cổng không thể thiếu của Microservices

Bạn đã bao giờ nhìn vào sơ đồ hệ thống microservices mà client gọi thẳng vào từng service chưa? Mình thì rồi. Và nó trông giống một nồi mì tôm sợi nào cũng dính vào sợi nào, không biết đâu là đầu đâu là cuối. Đó chính là lý do API Gateway tồn tại.

Vấn đề thực tế khi không có API Gateway

Hãy tưởng tượng bạn có một hệ thống e-commerce với khoảng 15-20 microservices: user service, product service, order service, payment service, notification service, inventory service... Giờ phía frontend cần render một trang product detail. Nó phải gọi đến product service lấy thông tin sản phẩm, gọi inventory service kiểm tra tồn kho, gọi review service lấy đánh giá, gọi recommendation service lấy sản phẩm gợi ý.

Kết quả? Frontend phải biết địa chỉ của từng service, phải handle authentication riêng cho từng request, phải tự aggregate data từ nhiều nguồn. Code frontend phình to, logic business bị leak ra ngoài, và mỗi lần backend thay đổi cấu trúc service là frontend lại phải sửa theo.

Theo kinh nghiệm của mình, đây là một trong những anti-pattern phổ biến nhất khi team mới chuyển từ monolith sang microservices. Ai cũng hào hứng tách service nhưng quên mất rằng cần một "anh gác cổng" đứng giữa.

API Gateway hoạt động như thế nào?

Nói đơn giản, API Gateway là một reverse proxy đứng giữa client và backend services. Mọi request từ client đều đi qua gateway trước, gateway sẽ xử lý authentication, routing, rate limiting, rồi mới forward request đến service phù hợp.

Nhưng nó không chỉ là một con proxy đơn thuần. Một API Gateway đầy đủ sẽ làm những việc sau:

• Request routing: Dựa vào URL path, HTTP method, headers để điều hướng request đến đúng service
• Authentication & Authorization: Xác thực token, API key ngay tại gateway thay vì mỗi service tự làm
• Rate limiting: Giới hạn số request mỗi client được gọi trong một khoảng thời gian
• Request/Response transformation: Chỉnh sửa request trước khi gửi đến service hoặc transform response trước khi trả về client
• Load balancing: Phân tải request đến nhiều instance của cùng một service
• Caching: Cache response để giảm tải cho backend
• Monitoring & Logging: Ghi log và theo dõi tất cả traffic đi qua

Điều mình thấy hay là với API Gateway, bạn có thể aggregate nhiều API calls thành một. Quay lại ví dụ trang product detail ở trên thay vì frontend gọi 4 requests riêng biệt, gateway có thể nhận một request duy nhất, gọi song song đến 4 services, gom kết quả lại và trả về một response hoàn chỉnh. Frontend chỉ cần biết đến một endpoint duy nhất.

Những lợi ích mà mình thấy rõ nhất trong thực tế

Che giấu sự phức tạp của backend

Client không cần biết hệ thống phía sau có bao nhiêu service, chạy ở đâu, dùng protocol gì. Bạn có thể thoải mái tách, gộp, refactor services mà không ảnh hưởng đến phía client. Mình từng làm một dự án phải tách một service thành ba service nhỏ hơn, nhờ có API Gateway mà team frontend không phải đổi một dòng code nào.

Centralized authentication

Thay vì mỗi service phải tự implement logic xác thực verify JWT, check permission, validate API key bạn chỉ cần config một lần ở gateway. Các service phía sau nhận request đã được xác thực, chỉ cần tập trung vào business logic. Sạch sẽ hơn rất nhiều.

Monitoring tập trung

Khi tất cả traffic đi qua một điểm, việc theo dõi trở nên dễ dàng hơn nhiều. Bạn biết chính xác service nào đang nhận nhiều request nhất, latency ở đâu cao, error rate bao nhiêu. Các gateway phổ biến như Kong, AWS API Gateway, hay Traefik đều có dashboard hoặc tích hợp sẵn với các monitoring tools.

Mặt trái mà bạn cần cân nhắc

Không có giải pháp nào hoàn hảo, và API Gateway cũng vậy.

Single point of failure. Gateway mà chết thì toàn bộ hệ thống chết theo. Đây là rủi ro lớn nhất. Bạn bắt buộc phải deploy gateway dạng high availability nhiều instance, có health check, auto-scaling. Đừng bao giờ chạy single instance gateway trên production.

Thêm latency. Mỗi request phải đi qua thêm một hop nữa. Thông thường con số này chỉ vài milliseconds, nhưng nếu gateway phải làm nhiều việc transform request, call authentication service, check rate limit thì latency có thể tăng đáng kể. Theo kinh nghiệm của mình, với Kong chạy trên hardware ổn, overhead thường dưới 5ms, chấp nhận được.

Bottleneck tiềm ẩn. Tất cả traffic dồn vào một điểm nghĩa là điểm đó phải đủ mạnh. Nếu không scale gateway đúng cách, nó sẽ trở thành nút thắt cổ chai của toàn hệ thống. Mình từng thấy một team không config connection pool hợp lý ở gateway, kết quả là gateway timeout trong khi backend services vẫn khỏe re.

Chi phí vận hành. Thêm một component nữa nghĩa là thêm server, thêm monitoring, thêm người quản lý. Với các bản enterprise của Kong hay Apigee, chi phí license cũng không hề rẻ có thể lên đến hàng chục nghìn đô mỗi năm.

Khi nào nên và không nên dùng?

Nếu hệ thống bạn chỉ có 2-3 services và team nhỏ, thành thật mà nói, bạn có thể chưa cần API Gateway. Một con Nginx reverse proxy đơn giản là đủ. Đừng over-engineer.

Nhưng khi hệ thống bắt đầu phình ra 5 services trở lên, nhiều loại client khác nhau (web, mobile, third-party), cần rate limiting hay authentication tập trung thì đó là lúc bạn nên nghiêm túc cân nhắc.

Một số lựa chọn phổ biến mà mình thấy cộng đồng hay dùng:

• Kong: Open source, plugin ecosystem phong phú, phù hợp đa số use case
• AWS API Gateway: Nếu bạn đã all-in AWS thì đây là lựa chọn tự nhiên nhất
• Traefik: Nhẹ, tích hợp tốt với Docker và Kubernetes
• Spring Cloud Gateway: Nếu team dùng Java/Spring ecosystem
• APISIX: Open source, hiệu năng cao, đang lên mạnh trong cộng đồng

Những điều mình rút ra sau vài năm làm việc với API Gateway

Đầu tiên, đừng nhồi quá nhiều logic vào gateway. Mình thấy nhiều team biến gateway thành một "super service" xử lý business logic, transform data phức tạp, thậm chí query database. Gateway nên làm đúng việc của nó: routing, authentication, rate limiting. Business logic thuộc về services.

Thứ hai, luôn có strategy cho việc gateway fail. Circuit breaker, retry policy, fallback response những thứ này không phải nice-to-have mà là must-have.

Thứ ba, document API ở tầng gateway. Khi mọi API đều đi qua gateway, đây là nơi tốt nhất để maintain API documentation. Nhiều gateway hỗ trợ tích hợp Swagger/OpenAPI spec, tận dụng nó đi.

API Gateway không phải silver bullet, nhưng với một hệ thống microservices đủ lớn, nó gần như là bắt buộc. Hiểu rõ nó làm gì, trade-off ở đâu, sẽ giúp bạn đưa ra quyết định đúng cho hệ thống của mình.