1. API gateway là gì?
Giả sử bạn có một hệ thống triển khai bằng kiến trúc microservice. Và đây là những điều sẽ xảy ra trên thực tế khi không có API gateway.
- Mỗi service sẽ phải xử lý authentication trên chính nó, ngay cả khi request đã được authentication một lần rồi và request gọi qua một service khác, request này sẽ vẫn phải authentication một lần nữa.
- Các nhu cầu về log API, xử lý hành vi của API dựa trên request/response... cần implement trên mỗi service riêng lẻ, bất tiện khi có service mới hoặc thay đổi global trên những nhu cầu tập trung này.
- Mất kiểm soát giữa api internal và public api cho client, không có giải pháp limit giữa các nhóm api có quyền truy cập khác nhau.
- Lộ các địa chỉ truy cập của dịch vụ đầu cuối và kiến trúc dịch vụ bên trong (do url thường kèm tên dịch vụ hoặc các địa chỉ IP khác nhau) của hệ thống do cần cung cấp trực tiếp địa chỉ public để client kết nối. Gia tăng rủi ro bảo mật của hệ thống.
2. Các ứng dụng của API gateway
2.1 Routing
Ứng dụng phổ biến nhất của API gateway là chức năng routing. Do mục đích đồng nhất entry point cho hệ thống và dễ dàng quản lý các kết nối từ phía client . Lúc này API gateway đóng vai trò như bộ phận một cửa, tất cả các request sẽ đi vào đây và được chuyển đến các microservice phía sau theo các rule được thiết lập sẵn.
Client request phổ biến là các Rest API nhưng cũng có thể là các dạng connection khác. API gateway nhận diện các request từ các dữ liệu bao gồm: đường dẫn url, header, body... sau đó so sánh với các rule routing được cài đặt để điều hướng request đến các target service phía sau. Target service là các microservice triển khai cùng hệ thống, các VM hoặc bất cứ dịch vụ nào được chỉ định bằng domain hoặc địa chỉ IP.
2.2 Caching
Nhà phát triển đặt các bộ dữ liệu đệm (cache) ngay trên API gateway để tăng cường hiệu năng hệ thống. Bằng cách kết hợp thêm với một số công vụ phục vụ lưu trữ và phân phối dữ liệu cache như Redis, dữ liệu được trả về ngay khi request tới API gateway mà không cần request tới backend service phía sau
2.3 Rate limiting
Tính năng Rate limit giúp ngăn chặn việc lạm dụng hoặc lượng đột biến các traffic bất thường gây hại cho hệ thống. Rate Limit sẽ giúp bảo vệ tài nguyên hệ thống microservice phía sau bằng cách ngăn chặn khi có quá nhiều traffic đến.
Trong thực tế rate limit được sử dụng trong các trường hợp
- Ngăn chặn brutal force
- Giảm nguy cơ bị DDoS
- Ngăn chặn các hành vi crawler data
- Cân bằng lượng sử dụng giữa các người dùng trong trường hợp một số khách hàng phát sinh quá nhiều request
API gateway sẽ giới hạn tần suất truy cập của các API trên các resource khác nhau. Ngoài việc chỉ định pattern của request nào sẽ bị giới hạn, điều kiện giới hạn các request sẽ dựa trên những thông số đặc trưng cho một native request như địa chỉ IP hoặc các thông tin về authentication nằm trong header hoặc cookie.
2.4 API composition và aggregation
Request aggregation là một pattern cho phép kết hợp dữ liệu nằm phân tán trên các service khác nhau trong một response duy nhất. Việc gọi api cross qua nhiều service sẽ làm giảm hiệu năng chung, do các request phải xử lý tuần tự, thêm vào việc quản lý các request cũng trở lên khó khăn khi debug. Request aggregation sẽ tổng hợp các request trên, fetching data và trả về trong một lần xử lý .
2.5 Logging và monitoring
API gateway collect metrics và logs từ các request, cung cấp cái nhìn thực tế về lượng sử dụng và performance của hệ thống. Việc collect log bao gồm phương thức đơn giản như log dữ liệu ra console, gửi tới các queue để tổng hợp hay áp dụng các giải pháp thu thập log enterprise như Fluentd kết hợp với ELK, EFK
2.6 Authentication và Authorization
Khi hệ thống microservice không có API gateway, mỗi service phải thực hiện authentication trên chính nó. Cho dù việc authentication được ủy quyền cho một service riêng biệt, Khi một request cần gọi qua nhiều service, việc authentication sẽ thực hiện lại khi một service gọi tới một service khác. Điều này là không cần thiết và lãng phí thêm một số round chip trên mỗi request.
Thiết kế đúng sẽ thực hiện Authentication và Authorization tập trung tại API gateway. Lúc này, các request được thực hiện xác thực một lần duy nhất tại API gateway, thông tin xác thực của tài khoản sẽ đi cùng với request vào các service backend bên trong mà không cần thực hiện xác thực lại.
2.7 Giới hạn điểm truy cập
Trong hệ thống microservice, số lượng các dịch vụ có thể lên tới hàng chục, hàng trăm service. Việc quản lý các endpoint cho các mục đích khác nhau sẽ trở nên khó khăn. Sẽ có những API public internet phục vụ cho phía client web, một số cho mobile, một số lại phục vụ cho external rest API hoặc callback cho người dùng tích hợp, một số khác lại chỉ dành cho nội bộ giữa các service... Việc public toàn bộ các API của hệ thống ra internet là rất rủi ro cho hệ thống
Sự đa dạng mục đích các endpoint này đòi hỏi các phương thức log, authentication và authorization khác nhau. API gateway sẽ tập trung các công cụ và giải pháp thực hiện quản lý truy cập tại một điểm nút duy nhất, giúp dễ dàng trong quản lý các kết nối một cách hiệu quả
3. Lựa chọn API gateway
Lựa chọn giải pháp API gateway phù hợp rất quan trọng với việc phát triển và mở rộng hệ thống về sau. Các nhu cầu về ứng dụng của API gateway chưa xuất hiện ngay khi hệ thống mới phát triển, chính vì vậy nên nếu nhà phát triển lựa chọn một giải pháp không phù hợp trong giai đoạn đầu, họ có thể phải thay thế giải pháp đó trong giai đoạn sau của hệ thống. Nhà phát triển lựa chọn một trong các framework opensource có sẵn để cài đặt API gateway, hoặc tự xây dựng một api gateway cho riêng hệ thống với bằng cách custom hoặc kết hợp với một số thư viện sẵn có.
3.1 Sử dụng Framework opensource
| Framework | Language | Key Feature | Best For |
|---|---|---|---|
| Kong | Lua | Many plugins | Large deployments |
| NGINX | C | Speed | High-traffic sites |
| Tyk | Go | User-friendly dashboard | Easy management |
| Express Gateway | JavaScript | Node.js compatible | JS dev teams |
| KrakenD | Go | No database required | Microservices |
| Apache APISIX | Lua | Cloud-native | Kubernetes setups |
3.2 Cân nhắc các tiêu chí lựa chọn
- Team stack: Đôi khi nhà phát triển sẽ cần mở rộng tính năng của Framework sẵn có tích hợp với một thành phần sẵn có của hệ thống. Lúc này việc custom plugin hoặc đọc hiểu để chỉnh sửa các cấu hình của framework để đáp ứng nhu cầu sẽ phụ thuộc vào ngôn ngữ mà framework có phù hợp với tech stack của team hay không. Việc học thêm Lua chỉ để custom Kong gateway sẽ không phải là một quyết định sáng suốt với một team Java
- Tính năng: Api gateway có rất nhiều tính năng hữu ích nhưng không phải tất cả các framework đều hỗ trợ các tính năng này. Nhà phát triển cần xác định phạm vi những feature cần thiết nhất cho hệ thống của mình.
- Chi phí: API gateway hỗ trợ tính năng ở các package khác nhau, một số chỉ có ở bản trả phí mà không có ở bản community hay opensource.
- Khả năng mở rộng, tích hợp: API gateway cần có khả năng mở rộng, custom và tích hợp. Sẽ ra sao nếu như API gateway bạn chọn chỉ hỗ trợ authentication bằng JWT nhưng lại không hỗ trợ phương thức basic authentication hoặc api-key và lại không có phương án nào custom, mở rộng.
- Khả năng scale/Performance: Nếu như hệ thống phải chịu tải tới hàng triệu request trong một thời gian ngắn thì lúc này hiệu năng của API gateway lại cần được đặt lên hàng đầu. Ví dụ như NGINX rất nhẹ, chiếm ít tài nguyên xử lý nhưng lại có thể xử lý gấp 2.6 lần số request khi so với Kong API gateway với các response 1Kb
- Khả năng Triển khai, cài đặt: Khả năng dễ dàng triển khai hoặc cài đặt bằng các file cấu hình hoặc deploy trên VM hoặc trên container. Điều này sẽ quyết định framwork sẽ triển khai đồng bộ với hệ thống phần mềm, tiết kiệm effort cho việc maintain.
3.3 Tự xây dựng API gateway
Một giải pháp khác cho API gateway là việc tự xây dựng một API gateway hoặc sử dụng kết hợp cả giải pháp custom với framework. Tự xây dựng API gateway có ưu điểm là dễ triển khai, gần với techstack của team, dễ dàng tích hợp với các giải pháp về authentication và authorization sẵn có của hệ thống. Các thành phần khác của hệ thống cũng dễ dàng được tích hợp và tái sử dụng cùng với gateway mà không cần tuân theo bản mẫu của framework. Nhưng ngược lại, việc tự xây dựng API gateway có thể gặp các rủi ro về bảo mật và hiệu năng kém hơn so với sử dụng framework.
Nguyên lý cơ bản của Tự xây dựng API gateway sẽ dựa trên nền tảng một proxy server, request đến sẽ được bóc tách ra thành các thành phần, từ đó sử dụng logic code để áp dụng các chức năng của API gateway như routing, authentication, logging...
Kết
Đón đọc bài tiếp theo trong loạt bài về API gateway:
Hướng dẫn xây dựng API gateway với Nodejs
Không có nhận xét nào:
Đăng nhận xét