API gateway là gì? Khác reverse proxy và load balancer ra sao

API gateway là lớp đứng trước toàn bộ API của một hệ thống, nhận mọi yêu cầu từ ứng dụng di động, trang web hay đối tác rồi chuyển tới đúng dịch vụ phía sau. Ngoài việc chuyển tiếp, nó còn lo xác thực, giới hạn tần suất, ghi nhật ký và gom dữ liệu. Bài này ProxyVN giải thích API gateway làm gì, khác reverse proxy và load balancer ở điểm nào, các sản phẩm phổ biến và khi nào đội nhỏ thực sự cần dùng. Tham khảo dịch vụ tại ProxyVN.

Tổng quan về API gateway

Khái niệm này xuất hiện nhiều cùng với kiến trúc microservice. Khi một ứng dụng bị chia thành hàng chục dịch vụ nhỏ, câu hỏi đầu tiên là người dùng sẽ gọi vào đâu.

Định nghĩa ngắn gọn

API gateway là một dạng reverse proxy chuyên cho API. Nó là điểm vào duy nhất cho mọi client, nhận yêu cầu, áp các chính sách chung như kiểm tra token hay giới hạn số lần gọi, rồi định tuyến tới dịch vụ phù hợp. Kết quả trả về cũng đi ngược qua nó.

Tài liệu của Amazon gọi dịch vụ này là "cửa trước" để ứng dụng truy cập dữ liệu, logic nghiệp vụ hay chức năng ở phía sau. Cách hình dung đơn giản nhất là quầy lễ tân của một toà nhà văn phòng: khách không tự đi tìm phòng, lễ tân kiểm tra giấy tờ, ghi sổ rồi chỉ đúng tầng.

Bài toán mà nó giải quyết

Theo mô tả mẫu API Gateway trên microservices.io, khi không có lớp này, client phải gọi trực tiếp từng dịch vụ và gặp nhiều vấn đề:

• API của microservice rất chi tiết, một màn hình phải gọi nhiều dịch vụ mới đủ dữ liệu.
• Mỗi loại client cần dữ liệu khác nhau, trang chi tiết sản phẩm trên máy tính thường nhiều thông tin hơn trên điện thoại.
• Mạng di động chậm và trễ cao hơn mạng nội bộ, gọi nhiều lần sẽ làm ứng dụng ì ạch.
• Địa chỉ và số lượng phiên bản dịch vụ thay đổi liên tục.
• Cách chia dịch vụ có thể đổi theo thời gian, client không nên biết điều đó.
• Một số dịch vụ dùng giao thức không thân thiện với web.

Ví dụ trong tài liệu là trang chi tiết sản phẩm của một cửa hàng online. Nó cần thông tin sản phẩm, giá, lịch sử đơn hàng, tồn kho và đánh giá, mỗi thứ nằm ở một dịch vụ riêng. Không có cổng gom lại, ứng dụng di động phải gọi năm lần cho một màn hình.

Hai cách xử lý yêu cầu

Cổng API xử lý yêu cầu theo hai kiểu. Với yêu cầu đơn giản, nó chỉ định tuyến thẳng tới một dịch vụ. Với yêu cầu phức tạp, nó gọi song song nhiều dịch vụ rồi ghép kết quả thành một phản hồi duy nhất, kỹ thuật gọi là API composition hay fan-out.

Kiểu thứ hai là nơi giá trị của nó thể hiện rõ nhất với ứng dụng di động. Một yêu cầu đi qua mạng chậm, năm yêu cầu còn lại chạy trong mạng nội bộ tốc độ cao của máy chủ.

Các chức năng chính của API gateway

Một cổng vào cho nhiều dịch vụ

Mỗi sản phẩm có danh sách tính năng khác nhau, nhưng có một nhóm chức năng gần như luôn có mặt. Phần này đi qua từng chức năng và lý do nên đặt nó ở cổng thay vì ở từng dịch vụ.

Xác thực và phân quyền

Thay vì mỗi dịch vụ tự kiểm tra token, cổng làm việc này một lần cho tất cả. Các cơ chế phổ biến gồm khoá API, JWT, OAuth 2.0 và OpenID Connect. Sau khi xác thực, cổng có thể đính thông tin người dùng vào header rồi chuyển xuống, dịch vụ phía sau chỉ cần đọc.

Lợi ích lớn nhất là nhất quán. Khi có lỗ hổng xác thực, anh em sửa ở một chỗ thay vì đi vá từng dịch vụ. Với Amazon API Gateway, các lựa chọn gồm chính sách IAM, hàm Lambda authorizer và nhóm người dùng Cognito.

Giới hạn tần suất và hạn mức

Rate limiting chặn một client gọi quá nhiều trong một khoảng thời gian, ví dụ 60 lần mỗi phút. Hạn mức theo gói cho phép bán API theo tầng: gói miễn phí 1.000 lần mỗi ngày, gói trả phí nhiều hơn. Giới hạn có thể tính theo IP, khoá API hay người dùng.

Đây là chức năng mà người làm thu thập dữ liệu hay gặp ở phía bên kia. Mã lỗi 429 Too Many Requests mà anh em thấy khi gọi API công khai quá nhanh thường chính là cổng API của bên đó đang làm việc của nó.

Định tuyến, chuyển đổi và gom dữ liệu

Cổng định tuyến theo đường dẫn, phương thức, header hay phiên bản API. Ví dụ `/v1/orders` đi tới dịch vụ cũ, `/v2/orders` đi tới dịch vụ mới. Nó còn có thể chuyển đổi định dạng, ví dụ client gửi JSON qua REST còn dịch vụ phía sau dùng gRPC.

Chức năng gom dữ liệu thường được viết thành mã tuỳ biến trong cổng. Netflix là ví dụ nổi tiếng, cổng của họ có mã chuyển đổi riêng cho từng loại thiết bị để mỗi thiết bị nhận đúng dữ liệu nó cần.

Giám sát, nhật ký và bộ đệm

Vì mọi yêu cầu đều đi qua cổng, đây là chỗ lý tưởng để đo độ trễ, đếm lỗi và ghi nhật ký truy cập. Các sản phẩm thường tích hợp sẵn với Prometheus, Grafana, CloudWatch hay công cụ truy vết phân tán. Bộ đệm phản hồi giúp giảm tải cho dịch vụ phía sau với dữ liệu ít thay đổi như danh mục sản phẩm.

Ngoài ra còn các chức năng phụ như ngắt mạch khi dịch vụ phía sau lỗi liên tục, thử lại tự động, phát hành thử nghiệm cho một phần nhỏ người dùng. Tài liệu Amazon gọi kiểu phát hành này là canary release.

So sánh API gateway với reverse proxy, load balancer và service mesh

Những việc một cổng API đảm nhận

Đây là phần nhiều người nhầm nhất, vì bốn thành phần này đều đứng giữa client và máy chủ. Khác biệt nằm ở tầng hoạt động và mức độ hiểu nội dung yêu cầu.

Bảng so sánh bốn thành phần

Bảng dưới tóm tắt vai trò chính của từng thành phần:

Nói gọn, reverse proxy là nền tảng, load balancer là một chức năng, cổng API là reverse proxy có thêm lớp hiểu nghiệp vụ API, còn service mesh lo phần bên trong. Nếu chưa rõ hai chiều proxy, anh em đọc trước bài phân biệt forward proxy và reverse proxy.

Khác reverse proxy ở điểm nào

Mọi cổng API đều là reverse proxy, nhưng không phải reverse proxy nào cũng là cổng API. Nginx hay Caddy cấu hình cơ bản chỉ biết chuyển yêu cầu theo tên miền và đường dẫn. Cổng API biết thêm ai đang gọi, gọi bao nhiêu lần, dùng khoá nào, được phép gọi đường dẫn nào.

Ranh giới ngày càng mờ vì nhiều reverse proxy có thêm plugin xác thực và giới hạn tần suất. Thực tế Kong, một trong những cổng API phổ biến nhất, được xây trên nền Nginx và OpenResty. Bài reverse proxy là gì giải thích phần nền tảng này.

Khác load balancer ở điểm nào

Load balancer chỉ có một nhiệm vụ: chia yêu cầu cho nhiều máy giống nhau để không máy nào quá tải. Nó có thể hoạt động ở tầng 4 chỉ nhìn IP và cổng, hoặc tầng 7 nhìn thêm HTTP. Nó không quan tâm ai đang gọi hay có được phép gọi không.

Cổng API thường có sẵn chức năng chia tải bên trong, nhưng trong hệ thống lớn, người ta vẫn đặt load balancer chuyên dụng phía trước cụm cổng. Hai thành phần bổ trợ nhau, không thay thế nhau. HAProxy là ví dụ load balancer mạnh, anh em xem thêm bài HAProxy là gì.

Khác service mesh ở điểm nào

Cổng API lo lưu lượng từ ngoài vào, gọi là chiều bắc nam. Service mesh lo lưu lượng giữa các dịch vụ với nhau, gọi là chiều đông tây. Hai lớp này thường cùng tồn tại trong hệ thống microservice lớn.

Bài service mesh proxy đã có phần riêng về quan hệ giữa hai thành phần, ProxyVN không nhắc lại chi tiết. Điểm cần nhớ là đội nhỏ hiếm khi cần service mesh, còn cổng API thì cần sớm hơn nhiều.

Mô hình Backends for Frontends trong API gateway

Khi một cổng phải phục vụ quá nhiều loại client khác nhau, nó dễ phình to và trở thành nút thắt. Mô hình Backends for Frontends ra đời để xử lý vấn đề này.

Mỗi loại client một cổng riêng

Thay vì một cổng chung, đội phát triển dựng ba cổng: một cho ứng dụng web, một cho ứng dụng di động, một cho đối tác bên thứ ba. Mỗi cổng chỉ phục vụ nhu cầu của đúng loại client đó. Ví dụ trên microservices.io dùng đúng cách chia này.

Lợi ích là đội làm ứng dụng di động có thể tự sửa cổng của mình mà không ảnh hưởng tới đội web. Dữ liệu trả về cũng được may đo cho màn hình nhỏ, giảm dung lượng truyền qua mạng di động.

Khi nào nên áp dụng

Mô hình này hợp với tổ chức có nhiều đội độc lập phụ trách từng loại client. Với đội nhỏ năm đến mười người, một cổng chung là đủ, chia nhỏ sớm chỉ thêm việc vận hành. Dấu hiệu nên tách là khi cổng chung có quá nhiều mã đặc thù cho từng client và mỗi lần sửa phải phối hợp nhiều đội.

Các sản phẩm API gateway phổ biến

Bốn lớp trung gian đứng ở đâu

Thị trường có rất nhiều lựa chọn, từ mã nguồn mở tự vận hành tới dịch vụ đám mây trả tiền theo lượt gọi. Phần này điểm qua những cái tên anh em hay gặp nhất.

Kong Gateway

Theo tài liệu Kong Gateway, đây là cổng API gọn nhẹ, chạy trước bất kỳ API RESTful nào và mở rộng bằng plugin. Các khái niệm chính là Service (dịch vụ phía sau), Route (đường vào), Consumer (người gọi) và Plugin (chính sách). Kong hỗ trợ ba chế độ triển khai: truyền thống có cơ sở dữ liệu, hybrid tách lớp điều khiển với lớp dữ liệu, và DB-less chỉ dùng tệp cấu hình.

Chế độ DB-less hợp với đội muốn quản lý cấu hình bằng Git. Dưới đây là ví dụ cấu hình khai báo minh hoạ, một dịch vụ đơn hàng có giới hạn 60 lần mỗi phút và yêu cầu khoá API:

_format_version: "3.0"
services:
  - name: orders
    url: http://orders:8080
    routes:
      - name: orders-route
        paths:
          - /orders
    plugins:
      - name: rate-limiting
        config:
          minute: 60
          policy: local
      - name: key-auth
consumers:
  - username: app-mobile
    keyauth_credentials:
      - key: doi-thanh-khoa-bi-mat

Client gọi API kèm header `apikey`, Kong kiểm tra khoá, đếm số lần gọi rồi chuyển tới dịch vụ `orders`. Vượt 60 lần trong một phút, client nhận mã 429.

Amazon API Gateway

Theo tài liệu Amazon API Gateway, dịch vụ hỗ trợ ba loại API: REST API, HTTP API và WebSocket API. Nó xử lý tới hàng trăm nghìn lời gọi đồng thời, tích hợp với Lambda để chạy mã không cần máy chủ, có ghi nhật ký qua CloudWatch và CloudTrail, chống tấn công web qua AWS WAF.

Điểm cần cân nhắc khi chọn giữa REST API và HTTP API là tính năng và chi phí. Trang so sánh REST API và HTTP API liệt kê chi tiết. Nhìn chung HTTP API rẻ hơn và độ trễ thấp hơn, REST API có nhiều tính năng hơn như bộ đệm và gói sử dụng.

Các lựa chọn khác

Ngoài hai cái tên trên, anh em sẽ gặp:

• Apigee của Google Cloud, mạnh về quản lý vòng đời API và phân tích, hướng tới doanh nghiệp lớn.
• Azure API Management cho hệ sinh thái Microsoft.
• Traefik, ban đầu là reverse proxy cho container, nay có bản mở rộng thành cổng API.
• Spring Cloud Gateway cho đội dùng Java và Spring Boot, viết định tuyến bằng mã.
• Tyk, KrakenD, Apache APISIX là các lựa chọn mã nguồn mở khác.

Trên Kubernetes, nhiều đội dùng Ingress controller có thêm tính năng cổng API, hoặc chuẩn Gateway API mới của Kubernetes. Lựa chọn phụ thuộc vào hạ tầng đang có hơn là tính năng thuần.

Khi nào doanh nghiệp nhỏ cần API gateway

Không phải hệ thống nào cũng cần một cổng riêng. Dựng sớm quá thì tốn công vận hành, dựng muộn quá thì mỗi dịch vụ tự làm xác thực một kiểu.

Dấu hiệu nên dựng

Một số tín hiệu cho thấy đã tới lúc:

• Có từ ba dịch vụ trở lên phải lộ ra ngoài, mỗi dịch vụ tự kiểm tra token theo cách riêng.
• Bắt đầu mở API cho đối tác hoặc khách hàng, cần cấp khoá và đặt hạn mức.
• Ứng dụng di động phải gọi nhiều dịch vụ cho một màn hình, người dùng than chậm.
• Cần thống kê ai gọi API nào, bao nhiêu lần, để tính phí hoặc phát hiện lạm dụng.

Nếu chỉ có một ứng dụng nguyên khối phục vụ một trang web, reverse proxy như Nginx hay Caddy reverse proxy là đủ. Thêm cổng API lúc này chỉ tăng độ phức tạp.

Nhược điểm cần chấp nhận

Microservices.io nêu hai nhược điểm chính. Thứ nhất, cổng là thêm một thành phần phải phát triển, triển khai và vận hành. Thứ hai, nó thêm một bước nhảy mạng, làm tăng độ trễ, dù với phần lớn ứng dụng mức tăng này không đáng kể.

Còn một rủi ro nữa là điểm lỗi đơn. Cổng sập là toàn bộ API sập, nên ở môi trường thật phải chạy ít nhất hai phiên bản phía sau load balancer. Đội nhỏ nên cân nhắc dịch vụ đám mây có sẵn tính sẵn sàng cao để khỏi lo phần này.

Cổng API là nơi tập trung chính sách. Tập trung thì dễ quản lý, nhưng cũng là nơi một lỗi cấu hình ảnh hưởng tới mọi thứ.

Triển khai API gateway từng bước cho đội nhỏ

Chọn cổng API theo quy mô

Phần này gợi ý một lộ trình thực tế cho đội vài người đang có vài dịch vụ, muốn chuyển sang mô hình có cổng mà không làm gián đoạn người dùng.

Bước 1: Liệt kê API và chính sách

Trước khi chọn sản phẩm, anh em lập bảng gồm mọi đường dẫn API đang có, dịch vụ nào xử lý, ai được gọi, giới hạn bao nhiêu. Bảng này sau trở thành cấu hình của cổng. Nhiều đội phát hiện ra những API cũ không ai dùng nữa ngay ở bước này.

Bước 2: Chọn sản phẩm theo hạ tầng

Đang chạy trên AWS và dùng Lambda thì Amazon API Gateway là lựa chọn tự nhiên. Tự vận hành máy chủ, muốn mã nguồn mở thì Kong DB-less hoặc APISIX. Đội Java thuần thì Spring Cloud Gateway viết bằng mã quen thuộc. Đừng chọn theo bảng xếp hạng, hãy chọn cái đội mình vận hành được.

Bước 3: Chuyển dần từng nhóm API

Đặt cổng trước, ban đầu chỉ chuyển tiếp nguyên trạng không áp chính sách gì. Kiểm tra mọi thứ vẫn chạy, rồi bật dần xác thực, giới hạn tần suất cho từng nhóm đường dẫn. Cách làm từng bước này giúp khoanh vùng lỗi dễ hơn nhiều so với bật tất cả một lúc.

Bước 4: Theo dõi và điều chỉnh

Sau khi chạy, xem nhật ký và số liệu để điều chỉnh hạn mức. Hạn mức quá chặt làm khách hàng thật bị chặn, quá lỏng thì không có tác dụng. Thường phải điều chỉnh vài vòng trong tháng đầu.

Bảo mật cho API gateway

Vì đứng ở cửa ngõ, cổng API vừa là lớp bảo vệ vừa là mục tiêu tấn công hấp dẫn. Cấu hình sai một chính sách có thể mở toang mọi dịch vụ phía sau, nên phần bảo mật cần được làm kỹ ngay từ đầu.

Không tin vào dữ liệu client tự gửi

Client có thể tự gửi header như `X-User-Id` hay `X-Forwarded-For` để giả danh. Cổng phải xoá các header nhạy cảm do client gửi lên, rồi mới gắn header của chính nó sau khi xác thực. Dịch vụ phía sau chỉ nên tin header do cổng đặt, và chỉ nhận kết nối từ cổng.

Lỗi này phổ biến hơn anh em nghĩ. Nhiều hệ thống đặt cổng xong nhưng dịch vụ phía sau vẫn mở cổng ra Internet, kẻ xấu gọi thẳng vào dịch vụ, bỏ qua toàn bộ lớp xác thực. Dịch vụ phía sau phải nằm trong mạng riêng, chỉ cổng gọi được.

Quản lý khoá và token

Khoá API cấp cho đối tác cần có hạn dùng, có thể thu hồi, và gắn với phạm vi quyền cụ thể. Không nên cấp một khoá dùng cho mọi API. Với JWT, cổng phải kiểm tra chữ ký, thời hạn và đối tượng nhận token, không chỉ giải mã để đọc.

Khoá bí mật dùng để ký token nên lưu trong kho bí mật như Vault hay dịch vụ quản lý khoá của nhà cung cấp đám mây. Ghi thẳng vào tệp cấu hình rồi đẩy lên Git là sai lầm kinh điển, đã khiến không ít công ty lộ dữ liệu.

Chống lạm dụng và tấn công từ chối dịch vụ

Giới hạn tần suất là lớp chống lạm dụng đầu tiên, nhưng không đủ trước tấn công quy mô lớn. Các nhà cung cấp đám mây thường kết hợp cổng API với tường lửa ứng dụng web và dịch vụ chống DDoS ở tầng mạng. Với cổng tự vận hành, anh em nên đặt thêm một lớp CDN hoặc dịch vụ chống DDoS phía trước.

Ngoài ra nên giới hạn kích thước thân yêu cầu, thời gian chờ và độ sâu của dữ liệu JSON. Một yêu cầu nặng bất thường có thể làm dịch vụ phía sau treo, kéo theo cả hệ thống.

Những sai lầm thường gặp khi dùng API gateway

Nhiều đội dựng cổng xong lại thấy hệ thống phức tạp và chậm hơn trước. Nguyên nhân thường nằm ở cách dùng chứ không phải ở bản thân công cụ.

Nhét logic nghiệp vụ vào cổng

Cổng nên lo chính sách chung, không nên chứa logic nghiệp vụ như tính giá, kiểm tra tồn kho. Khi logic dồn vào cổng, nó trở thành một ứng dụng nguyên khối mới, mọi đội đều phải sửa nó và mỗi lần triển khai đều rủi ro. Phần gom dữ liệu nên giữ ở mức ghép kết quả, không xử lý nghiệp vụ phức tạp.

Một cổng cho mọi thứ

Đưa cả lưu lượng nội bộ giữa các dịch vụ qua cổng sẽ tạo nút thắt và tăng độ trễ không cần thiết. Lưu lượng nội bộ nên đi thẳng giữa các dịch vụ, hoặc qua service mesh khi hệ thống đủ lớn. Cổng chỉ nên đứng ở ranh giới giữa bên ngoài và bên trong.

Bỏ qua phiên bản API

Không có chiến lược phiên bản, mỗi lần sửa API là ứng dụng di động cũ của người dùng bị lỗi. Cổng hỗ trợ định tuyến theo phiên bản rất tốt, anh em nên tận dụng để chạy song song bản cũ và bản mới một thời gian, rồi mới ngừng bản cũ khi số lượt gọi về gần bằng không.

API gateway nhìn từ phía người thu thập dữ liệu

Phần lớn bài viết về cổng API đứng ở góc nhà phát triển. Nhưng nhiều anh em đọc ProxyVN lại đứng ở phía bên kia: gọi API công khai của các trang để lấy dữ liệu giá, tồn kho, xu hướng. Hiểu cổng API giúp làm việc này đúng mực hơn.

Vì sao bị trả về lỗi 429

Khi gọi API quá nhanh, cổng của bên cung cấp đếm số lần gọi theo khoá API hoặc theo IP và trả về 429. Header phản hồi thường kèm thông tin như số lần còn lại và thời điểm reset. Đọc các header này rồi giãn tần suất là cách đúng, thay vì cố gọi tiếp.

Một số cổng giới hạn theo IP cho khách chưa đăng nhập. Khi đó, nhiều tác vụ hợp lệ chạy chung một IP văn phòng có thể chạm hạn mức của nhau. Tách tác vụ ra nhiều IP giúp mỗi tác vụ có hạn mức riêng, miễn là vẫn tôn trọng điều khoản sử dụng của bên cung cấp.

Dùng IP ổn định khi gọi API đối tác

Nhiều đối tác yêu cầu đăng ký danh sách IP được phép gọi API, gọi là whitelist. Nếu máy gọi dùng mạng gia đình có IP thay đổi, mỗi lần đổi IP là API bị từ chối. Proxy IP tĩnh giải quyết việc này gọn gàng, anh em chỉ đăng ký một IP cố định với đối tác.

Khi cần IP tĩnh Việt Nam cho việc này, anh em có thể mua proxy dân cư tĩnh hoặc datacenter Việt Nam tại ProxyVN, hỗ trợ HTTP và SOCKS5, cấp sẵn tên đăng nhập và mật khẩu. IP giữ nguyên suốt thời gian thuê nên đăng ký whitelist một lần là xong.

Kết luận

API gateway là reverse proxy chuyên cho API, gom xác thực, giới hạn tần suất, định tuyến và giám sát vào một cổng duy nhất. Nó bổ trợ chứ không thay thế load balancer hay service mesh. Đội nhỏ nên dựng khi có nhiều dịch vụ lộ ra ngoài. Cần tư vấn thêm về proxy, hãy liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam khi tìm hiểu API gateway.