API gateway là gì?

Mục lục

1. API gateway là gì?
2. Vì sao cần một điểm vào chung cho API?
3. Một request đi qua API gateway như thế nào?
4. Các chức năng chính và điểm dễ bị bỏ sót
5. API gateway khác reverse proxy, load balancer và service mesh thế nào?
6. Có những kiểu triển khai nào?
7. Ví dụ minh hoạ: chuỗi cửa hàng mở API cho đối tác giao hàng
8. Ưu điểm và nhược điểm
9. Khi nào nên và không nên dùng API gateway?
10. Lỗi thường gặp khi dùng API gateway
11. Tiêu chí chọn giải pháp API gateway
12. Câu hỏi thường gặp

API gateway là gì?

API gateway là một thành phần phần mềm (hoặc dịch vụ đám mây) nhận toàn bộ yêu cầu gọi API từ bên ngoài, áp dụng các chính sách chung rồi chuyển yêu cầu đến dịch vụ backend phù hợp. Bạn có thể hình dung nó như quầy lễ tân của một toà nhà văn phòng: khách không tự đi vào từng phòng mà phải qua quầy, được kiểm tra thẻ, ghi sổ, rồi chỉ đường đến đúng tầng.

Nếu cần nền tảng về khái niệm giao diện lập trình, bạn có thể đọc bài giải thích API và các loại API. Bài này tập trung vào lớp đứng trước API: nó làm gì, đặt ở đâu và khi nào đáng triển khai.

Các bài hướng dẫn tiếng Việt đang xếp hạng cho từ khoá này thường dừng ở hình ảnh “người gác cổng” và danh sách chức năng. Phần dưới đi thêm vào thứ tự xử lý một request, các điểm lỗi thường gặp và cách quyết định có nên dùng hay không.

Vì sao cần một điểm vào chung cho API?

Khi hệ thống còn một ứng dụng, client gọi thẳng vào máy chủ và mọi thứ đơn giản. Vấn đề xuất hiện khi hệ thống tách thành nhiều dịch vụ nhỏ, ví dụ dịch vụ tài khoản, giỏ hàng, thanh toán, thông báo. Nếu để ứng dụng di động gọi trực tiếp từng dịch vụ, bạn gặp ba rắc rối cụ thể:

• Lặp logic bảo mật. Mỗi dịch vụ phải tự kiểm tra token, tự giới hạn tốc độ. Chỉ cần một đội quên cấu hình là có một cửa hở.
• Lộ cấu trúc nội bộ. Địa chỉ và cách chia dịch vụ bị gắn cứng vào ứng dụng đã phát hành. Muốn gộp hai dịch vụ lại, bạn phải ép người dùng cập nhật app.
• Nhiều lần gọi mạng. Một màn hình “Đơn hàng của tôi” có thể cần dữ liệu từ ba dịch vụ. Trên mạng di động chậm, ba lượt gọi nối tiếp làm màn hình tải lâu.

API gateway giải quyết ba việc này bằng cách đặt chính sách, địa chỉ công khai và việc gom dữ liệu vào một lớp. Kiến trúc chia nhỏ dịch vụ được trình bày riêng trong bài kiến trúc microservices; gateway là phần thường đi kèm khi chia nhỏ như vậy, nhưng không phải chỉ dùng được với microservices.

Một request đi qua API gateway như thế nào?

Thứ tự các bước quan trọng hơn danh sách chức năng, vì nó quyết định lỗi nào bị chặn sớm và lỗi nào lọt vào backend. Cách sắp xếp cụ thể khác nhau tuỳ sản phẩm, nhưng luồng điển hình như sau.

1. Kết thúc kết nối TLS. Gateway giải mã HTTPS, nên chứng chỉ chỉ cần quản lý ở một nơi.
2. Xác thực. Gateway kiểm tra khoá API, token OAuth 2.0 hoặc JWT. Token sai hoặc hết hạn bị từ chối bằng mã 401 mà backend không hề biết.
3. Phân quyền thô. Gateway kiểm tra token này có được gọi nhóm API này không (mã 403 nếu không). Quyền chi tiết theo từng bản ghi vẫn phải do dịch vụ xử lý.
4. Giới hạn tốc độ và hạn mức. Khi vượt ngưỡng, gateway trả mã 429 (Too Many Requests), thường kèm thông tin thời điểm được thử lại.
5. Kiểm tra cấu trúc yêu cầu. Nhiều gateway đối chiếu yêu cầu với đặc tả OpenAPI hoặc JSON Schema để loại sớm dữ liệu sai định dạng hay quá kích thước.
6. Định tuyến và chuyển đổi. Gateway chọn dịch vụ đích theo đường dẫn, phiên bản hoặc tiêu đề, có thể đổi định dạng, rồi chuyển tiếp.
7. Ghi log và số đo. Gateway lưu thời gian phản hồi, mã trạng thái, định danh client để theo dõi và tính phí theo gói.

Hệ quả thực tế: nếu giới hạn tốc độ nằm sau bước định tuyến, backend đã phải xử lý yêu cầu rồi mới bị từ chối, và chính mục đích bảo vệ bị mất. Khi cấu hình, bạn nên kiểm tra rằng chính sách chặn được áp dụng trước bước chuyển tiếp.

Các chức năng chính và điểm dễ bị bỏ sót

Định tuyến và quản lý phiên bản

Gateway ánh xạ đường dẫn công khai sang dịch vụ nội bộ. Ví dụ minh hoạ: đường dẫn /v1/don-hang trỏ tới hệ thống cũ, còn /v2/don-hang trỏ tới dịch vụ mới, nên hai thế hệ ứng dụng cùng chạy trong thời gian chuyển đổi. Đây là lý do gateway hữu ích cả khi bạn chưa hề dùng microservices mà chỉ đang thay dần hệ thống cũ.

Xác thực tập trung

Gateway thường kiểm tra chữ ký và hạn của token, còn việc cấp token do máy chủ định danh riêng đảm nhận. Nếu tổ chức có yêu cầu xác thực mạnh cho người dùng cuối, phần này gắn với xác thực đa yếu tố ở khâu đăng nhập, không phải ở gateway.

Giới hạn tốc độ, hạn mức và bảo vệ tài nguyên

Theo OWASP API Security Top 10 phiên bản 2023, mục API4 là “Unrestricted Resource Consumption”, đổi tên từ “Lack of Resources and Rate Limiting” của bản 2019. OWASP khuyến nghị tinh chỉnh giới hạn theo nghiệp vụ và siết chặt hơn với các thao tác nhạy cảm như xác thực OTP hay khôi phục mật khẩu. Gateway là nơi thuận tiện để đặt giới hạn, nhưng tài liệu OWASP phiên bản này cũng nhắc cần kiểm tra phía máy chủ đối với tham số quyết định số bản ghi trả về, tức là gateway không thay được kiểm tra trong ứng dụng.

Gom dữ liệu và chuyển đổi

Gateway có thể nhận một lời gọi từ app, gọi song song ba dịch vụ rồi trả một phản hồi gộp. Ở mô hình “backend for frontend”, mỗi loại client (web, di động) có một gateway riêng với dạng dữ liệu vừa đủ cho màn hình của nó. Cái giá là logic nghiệp vụ dễ rò vào gateway; nên giữ gateway ở mức ghép nối, không tính toán nghiệp vụ.

Bộ nhớ đệm, giám sát và cổng cho nhà phát triển

Gateway lưu đệm phản hồi cho dữ liệu ít đổi như danh mục sản phẩm, đồng thời thu số lần gọi theo từng client. Các nền tảng quản lý API đầy đủ còn có cổng thông tin cho đối tác tự đăng ký lấy khoá và xem tài liệu. Đây là phần quyết định khi bạn mở API ra bên ngoài như một sản phẩm.

API gateway khác reverse proxy, load balancer và service mesh thế nào?

Bốn thành phần này hay bị nhầm vì đều nằm trên đường đi của lưu lượng và nhiều sản phẩm làm được nhiều vai. Cách phân biệt đơn giản: hỏi xem nó hiểu “yêu cầu” ở mức nào.

Tiêu chí	Load balancer	Reverse proxy	API gateway	Service mesh
Việc chính	Chia tải giữa các bản sao	Đại diện máy chủ, che địa chỉ thật	Quản lý và bảo vệ lời gọi API	Kiểm soát giao tiếp giữa dịch vụ nội bộ
Hiểu ngữ cảnh API (khoá, token, gói)	Thường không	Hạn chế	Có	Có ở mức danh tính dịch vụ
Hướng lưu lượng điển hình	Từ ngoài vào	Từ ngoài vào	Từ ngoài vào (north-south)	Giữa các dịch vụ (east-west)
Quản lý phiên bản, hạn mức theo client	Không	Không phải mục tiêu chính	Có	Không phải mục tiêu chính
Ví dụ công cụ	Bộ cân bằng tải của nhà cung cấp cloud	NGINX, HAProxy	Kong, Apigee, AWS API Gateway, Azure API Management	Istio, Linkerd

Nhiều tài liệu coi API gateway là reverse proxy được mở rộng thêm tính năng cho API, và cách nhìn này đúng ở mặt kỹ thuật. Trong thực tế, tổ chức thường xếp chồng: load balancer ở ngoài cùng, gateway ở giữa, service mesh bên trong cụm container. Về lớp bảo vệ, gateway cũng không thay tường lửa và WAF: WAF nhìn vào mẫu tấn công trong nội dung web, còn gateway nhìn vào danh tính và hạn mức của lời gọi API.

Có những kiểu triển khai nào?

• Dịch vụ do nhà cung cấp cloud quản lý. Bạn cấu hình, nhà cung cấp lo hạ tầng và mở rộng. Phù hợp khi backend đã chạy trên cùng đám mây; đánh đổi là phụ thuộc nhà cung cấp và cách tính phí theo số lời gọi.
• Phần mềm tự vận hành. Cài mã nguồn mở hoặc bản thương mại trên máy chủ hay cụm container của riêng bạn. Bạn kiểm soát dữ liệu và vị trí đặt, nhưng phải tự lo vá lỗi, dự phòng và giám sát.
• Gateway cho hàm không máy chủ. Với kiến trúc serverless, gateway là cửa HTTP để kích hoạt hàm, nên gần như bắt buộc.
• Gateway nhúng trong ứng dụng. Một số khung phát triển cung cấp thư viện định tuyến và lọc ngay trong mã. Cách này nhẹ nhưng khó dùng chung cho nhiều ngôn ngữ.

Trong môi trường doanh nghiệp Việt Nam có ứng dụng cũ chạy tại chỗ và ứng dụng mới trên đám mây, gateway cũng thường được đặt làm cửa chung cho cả hai phía, để đối tác chỉ phải nhớ một địa chỉ.

Ví dụ minh hoạ: chuỗi cửa hàng mở API cho đối tác giao hàng

Ví dụ minh hoạ, không phải số liệu thật: một chuỗi bán lẻ có hệ thống đơn hàng, kho và khách hàng chạy ở ba nơi khác nhau. Họ cho ba đối tác giao hàng truy cập trạng thái đơn qua API.

• Mỗi đối tác nhận một khoá riêng. Gateway cho phép đối tác chỉ gọi nhóm API đơn hàng, không thấy API khách hàng.
• Gateway đặt hạn mức theo đối tác để một đối tác lỗi vòng lặp không làm nghẽn hệ thống kho.
• Khi chuyển hệ thống đơn hàng sang nền tảng mới, đường dẫn công khai giữ nguyên, chỉ đổi đích định tuyến phía sau.
• Log theo khoá giúp xác định đối tác nào gây ra lượng lỗi 5xx tăng đột biến.

Với quy mô và nhu cầu như vậy, gateway mang lại lợi ích rõ. Các nghiệp vụ như POS hay kho trong bán lẻ được bàn trong bài chuyển đổi số trong bán lẻ, còn cách đối tác nhận thông báo theo sự kiện thay vì hỏi liên tục thuộc phần so sánh API và webhook.

Ưu điểm và nhược điểm

Ưu điểm	Nhược điểm
Chính sách bảo mật và hạn mức đặt một nơi, dễ kiểm toán	Trở thành điểm lỗi đơn nếu chỉ chạy một bản
Che cấu trúc nội bộ, đổi backend không ảnh hưởng client	Thêm một chặng mạng nên tăng độ trễ
Giảm số lượt gọi của app nhờ gom dữ liệu	Dễ bị nhồi logic nghiệp vụ, thành “khối nguyên khối” thu nhỏ
Có số đo tập trung theo client, theo API	Cần người vận hành, cấu hình sai có thể chặn nhầm toàn bộ
Hỗ trợ chạy song song nhiều phiên bản API	Chi phí theo lời gọi trên nền tảng cloud có thể tăng khi lưu lượng lớn

Điểm yếu lớn nhất cần tính trước là tính sẵn sàng. Vì mọi lưu lượng qua gateway, bạn nên chạy tối thiểu hai bản ở hai vùng sẵn sàng khác nhau, đồng thời đưa gateway vào kế hoạch khôi phục sau thảm hoạ của hệ thống.

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

Nên dùng khi:

• Bạn mở API cho đối tác hoặc ứng dụng di động và cần cấp khoá, đặt hạn mức theo từng bên.
• Bạn có từ vài dịch vụ trở lên và đang thấy cùng một đoạn mã xác thực bị chép nhiều chỗ.
• Bạn đang thay dần hệ thống cũ và cần giữ địa chỉ API ổn định cho client.
• Bạn cần số đo gọi API theo từng client để tính phí hoặc đối soát.

Chưa cần khi:

• Hệ thống chỉ có một ứng dụng web nói chuyện với một cơ sở dữ liệu, không ai bên ngoài gọi API.
• Nhóm vận hành chỉ có một người và chưa có giám sát, trong khi gateway thêm một thành phần phải theo dõi.
• Reverse proxy hiện có đã đáp ứng nhu cầu định tuyến và TLS, còn các API chỉ dùng nội bộ trong một mạng tin cậy.

Nếu bạn đang đi theo hướng bảo mật không mặc định tin mạng nội bộ, gateway là một điểm thực thi chính sách phù hợp với mô hình zero trust, nhưng nó chỉ là một phần của mô hình đó.

Lỗi thường gặp khi dùng API gateway

• Backend vẫn mở cổng ra Internet. Nếu ai biết địa chỉ thật vẫn gọi thẳng được, mọi chính sách ở gateway vô nghĩa. Hãy giới hạn backend chỉ nhận lưu lượng từ gateway.
• Tin gateway làm hết phân quyền. Lỗi phân quyền cấp đối tượng (BOLA) đứng đầu OWASP API Security Top 10 phiên bản 2023; gateway không biết người dùng A có quyền xem đơn của người dùng B hay không, dịch vụ phải kiểm tra.
• Giới hạn tốc độ chung một mức. Giới hạn quá thấp chặn nhầm khách thật, quá cao thì không chặn được gì. Đặt mức riêng cho đăng nhập, OTP và các API đọc.
• Không có API bị bỏ quên trong danh mục. Phiên bản cũ không ai tắt vẫn nhận lưu lượng. Dùng gateway làm nơi liệt kê và đặt thời hạn ngừng cho phiên bản cũ.
• Chỉ có một bản gateway. Một lần nâng cấp hay hỏng nút là toàn bộ API ngừng.
• Trả lỗi không nhất quán. Gateway trả 429 nhưng không kèm hướng dẫn thử lại khiến client thử dồn dập và làm tình hình xấu hơn.

Giao diện mà gateway công bố thường theo phong cách REST; nếu bạn cần hiểu quy ước đường dẫn, phương thức và mã trạng thái, hãy xem bài RESTful API.

Tiêu chí chọn giải pháp API gateway

1. Vị trí backend. Backend chủ yếu trên một đám mây thì dịch vụ gateway của chính nền tảng đó thường tích hợp sâu nhất. Backend rải nhiều nơi thì cần sản phẩm chạy được ở mọi môi trường.
2. Giao thức cần hỗ trợ. Ngoài REST, bạn có dùng gRPC, WebSocket, GraphQL, SOAP không? Kiểm tra từng giao thức trong tài liệu sản phẩm.
3. Cơ chế xác thực. Có hỗ trợ OAuth 2.0, OpenID Connect, JWT, mTLS, khoá API và kết nối với hệ thống định danh hiện có không?
4. Khả năng mở rộng và dự phòng. Chạy đa bản, đa vùng; cấu hình có được lưu dạng mã để quản lý phiên bản không.
5. Khả năng quan sát. Xuất log và số đo sang công cụ giám sát bạn đang dùng, có che trường nhạy cảm không.
6. Mô hình chi phí. Tính theo số lời gọi, theo giờ máy hay theo giấy phép. Hãy ước lượng với lưu lượng đỉnh của bạn trước khi quyết định, vì giá của các nhà cung cấp thay đổi theo thời điểm.
7. Năng lực vận hành. Nhóm có người biết cấu hình, vá lỗi và xử lý sự cố không, hay cần dịch vụ quản lý sẵn?

Gateway cũng ăn khớp với cách làm của hệ thống cloud native, nơi cấu hình được lưu dạng khai báo và triển khai tự động.

Câu hỏi thường gặp

API gateway có phải là một loại firewall không?

Không. Tường lửa lọc lưu lượng theo địa chỉ, cổng hoặc mẫu tấn công; gateway quản lý lời gọi API theo danh tính client, hạn mức và định tuyến. Hai lớp bổ sung cho nhau, không thay thế nhau.

Chỉ dùng NGINX làm reverse proxy có thay được API gateway không?

Với nhu cầu đơn giản như định tuyến, TLS và giới hạn tốc độ cơ bản thì được. Khi bạn cần cấp khoá cho đối tác, hạn mức theo gói, phiên bản API và cổng tài liệu, bạn sẽ phải tự xây thêm nhiều thứ hoặc chuyển sang sản phẩm quản lý API chuyên biệt.

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

Có thêm một chặng xử lý nên có độ trễ cộng thêm, thường nhỏ so với thời gian xử lý của backend. Đổi lại, bộ nhớ đệm và gom dữ liệu có thể làm tổng thời gian phản hồi của app giảm. Bạn nên đo trên chính hệ thống của mình thay vì dựa vào con số chung.

Hệ thống monolithic có dùng được API gateway không?

Có. Gateway vẫn hữu ích để bảo vệ API công khai, quản lý phiên bản và làm lớp che khi bạn tách dần từng phần ra khỏi khối ứng dụng cũ.

API gateway khác service mesh ở điểm nào?

Gateway xử lý lưu lượng từ bên ngoài đi vào hệ thống. Service mesh xử lý giao tiếp giữa các dịch vụ bên trong, chẳng hạn mã hoá kết nối và thử lại. Một hệ thống lớn có thể dùng cả hai.

Log của API gateway có bị coi là dữ liệu cá nhân không?

Nếu log chứa thông tin xác định được một người, như định danh tài khoản hay địa chỉ IP gắn với người dùng, thì bạn nên coi chúng là dữ liệu cá nhân và áp dụng nguyên tắc tối thiểu hoá cùng thời hạn lưu. Với trường hợp cụ thể, hãy hỏi bộ phận pháp chế hoặc luật sư.