API Gateway Pattern

API Gateway Pattern trong Kiến trúc Microservices

Bài viết này sẽ giới thiệu về API Gateway Pattern, một trong những Design Pattern thường dùng trong Kiến trúc Microservices. Như chúng ta đã biết, việc học hỏi và áp dụng các practices cùng pattern sẽ giúp xây dựng một bộ công cụ thiết kế hữu ích. Những pattern và practices này sẽ được sử dụng trong quá trình thiết kế kiến trúc microservices.

Mục tiêu của bài viết là giúp bạn đọc nắm được:

• Where and When to apply áp dụng API Gateway Pattern như thế nào trong Kiến trúc Microservices

• Sử dụng các nguyên tắc KISS, YAGNI, SoC và SOLID để thiết kế hệ thống ứng dụng thương mại điện tử.

Lưu ý:

• KISS: Keep It Simple, Stupid (Giữ đơn giản)

• YAGNI: You Aren't Gonna Need It (Bạn sẽ không cần nó)

• SoC: Separation of Concerns (Phân tách theo chức năng)

• SOLID: Các nguyên tắc thiết kế hướng đối tượng (Object-Oriented Design Principles)

API Gateway pattern được khuyến khích sử dụng khi bạn thiết kế và xây dựng các ứng dụng phức tạp, lớn dựa trên microservices với nhiều ứng dụng người dùng khác nhau (client application). Pattern này tương tự như mẫu facade (facade pattern) trong lập trình hướng đối tượng, nhưng nó là một phần của hệ thống phân tán, hoạt động như một reverse proxy hoặc gateway routing để sử dụng trong mô hình giao tiếp đồng bộ (synchronous communication model).

Tương tự như facade pattern, API Gateway Pattern cung cấp một điểm truy cập duy nhất cho các API (single entry point) bằng cách đóng gói kiến trúc hệ thống bên dưới.

Pattern này cung cấp một reverse proxy để chuyển hướng hoặc định tuyến các yêu cầu đến các điểm cuối (endpoint) của microservices nội bộ . API Gateway cung cấp một điểm cuối duy nhất cho các ứng dụng client và tự nó ánh xạ các yêu cầu đến các microservices nội bộ.

Tóm lại, API Gateway nằm giữa clients và các microservices nội bộ. Nó hoạt động như một reverse proxy, định tuyến các yêu cầu từ client đến các dịch vụ backend. Bên cạnh đó, nó còn xử lý các vấn đề liên quan như authentication, SSL termination, and cache.

Hình ảnh đã minh họa việc API Gateway nhận yêu cầu từ nhiều ứng dụng client ở một điểm vào duy nhất (single entrypoint) và định tuyến chúng đến các microservice bên trong. Mặc dù tiện lợi, cách tiếp cận này tiềm ẩn một số rủi ro:

Single Point of Failure (SPOF): Nếu chỉ có một API Gateway, nó trở thành điểm SPOF. Nghĩa là, nếu API Gateway gặp sự cố, tất cả các ứng dụng khách sẽ ngừng hoạt động. Điều này đi ngược lại tính sẵn sàng cao (high availability) - một trong những lợi ích chính của kiến trúc microservices.

Anti-Pattern: Khi số lượng ứng dụng khách tăng lên hoặc logic xử lý trong API Gateway phức tạp hơn, nó có thể trở thành một Anti-Pattern. API Gateway nên tập trung vào việc định tuyến và các tác vụ liên quan (xác thực, SSL termination, cache). Nếu nó chứa quá nhiều logic nghiệp vụ, nó sẽ trở nên khó bảo trì và dễ xảy ra lỗi.

Để khắc phục những vấn đề này, chúng ta có thể áp dụng một số giải pháp:

• Triển khai nhiều API Gateway: Cân nhắc triển khai nhiều API Gateway theo mô hình High Availability (HA) để đảm bảo tính sẵn sàng cao. Mỗi Gateway có thể xử lý một phần lưu lượng truy cập, giúp hệ thống vẫn hoạt động ngay cả khi một Gateway gặp sự cố.

• Giảm thiểu logic trong API Gateway: Chỉ nên đặt các logic cần thiết cho việc định tuyến và xử lý các vấn đề liên quan (xác thực, SSL termination, cache) vào API Gateway. Logic nghiệp vụ phức tạp nên được xử lý bởi các microservice chuyên biệt.

• Kiểm soát tỉ lệ và giới hạn: Sử dụng các dịch vụ riêng biệt để xử lý giới hạn tốc độ và hạn ngạch người dùng thay vì nhúng chúng vào API Gateway.

API Gateway có thể phát triển và thay đổi dựa trên nhiều yêu cầu khác nhau từ các ứng dụng client . Do đó, chia nhỏ API Gateway thành nhiều dịch vụ hoặc nhiều API Gateway nhỏ hơn là một practices hữu hiệu.

Chúng ta sẽ tìm hiểu về mô hình BFF (Backend for Frontend) sau.

Tóm lại, cần thận trọng khi sử dụng một API Gateway duy nhất. Nó nên được phân tách dựa trên ranh giới nghiệp vụ của các ứng dụng khách chứ không nên là bộ gom duy nhất cho tất cả các microservice nội bộ.

Lợi ích của việc phân tách API Gateway:

• Giảm thiểu SPOF: Tránh rủi ro SPOF bằng cách phân tán chức năng của API Gateway trên nhiều dịch vụ.

• Cải thiện khả năng mở rộng: Dễ dàng mở rộng quy mô API Gateway theo nhu cầu bằng cách thêm các Gateway mới.

• Tăng tính linh hoạt: Cho phép tùy chỉnh API Gateway cho từng nhóm ứng dụng khách cụ thể, cung cấp trải nghiệm API phù hợp hơn.

• Giảm phức tạp: Giữ cho mỗi API Gateway nhỏ gọn và dễ quản lý, tránh logic phức tạp.

BFF (Backend for Frontend):

BFF là một mẫu thiết kế khác liên quan đến API Gateway. Nó là một microservice riêng biệt được thiết kế để phục vụ các nhu cầu cụ thể của một ứng dụng client (frontend). BFF có thể kết hợp dữ liệu từ nhiều microservice nội bộ và định dạng lại nó theo cách tối ưu hóa cho ứng dụng khách đó.

Bằng cách sử dụng sự kết hợp của API Gateway được phân tách và BFF, bạn có thể tạo ra một kiến trúc linh hoạt và có thể mở rộng để đáp ứng các yêu cầu của các ứng dụng khách khác nhau.

Các Tính năng Chính của API Gateway Pattern

Như đã đề cập trước đó, API Gateway Pattern mang lại nhiều lợi ích. Bên cạnh việc tiếp nhận yêu cầu từ client và định tuyến chúng đến các microservice nội bộ, API Gateway còn có thể xử lý một số tính năng hữu ích:

1. Định tuyến thông minh (Smart Routing):

• API Gateway có thể định tuyến các yêu cầu đến microservice phù hợp dựa trên các tiêu chí khác nhau, chẳng hạn như đường dẫn URL, tiêu đề header, hoặc nội dung yêu cầu.

• Điều này giúp cải thiện hiệu suất và giảm tải cho các microservice.

2. Bảo mật (Security):

• API Gateway có thể tập trung logic xác thực và ủy quyền, loại bỏ sự cần thiết để mỗi microservice tự triển khai các chức năng này.

• Nó có thể thực hiện các kiểm tra bảo mật khác nhau, chẳng hạn như kiểm tra token hoặc kiểm soát truy cập dựa trên vai trò (RBAC).

3. Giám sát và phân tích (Monitoring and Analytics):

• API Gateway có thể cung cấp thông tin chi tiết về lưu lượng truy cập API, chẳng hạn như số lượng yêu cầu, thời gian phản hồi và các lỗi.

• Điều này giúp bạn theo dõi hiệu suất của API và nhanh chóng xác định các vấn đề.

4. Giới hạn tốc độ và Kiểm soát tỉ lệ (Rate Limiting and Throttling):

• API Gateway có thể giới hạn tốc độ của các yêu cầu để ngăn chặn các cuộc tấn công DoS (Denial-of-Service) và đảm bảo tính sẵn sàng của API cho tất cả người dùng.

• Nó cũng có thể áp dụng các giới hạn tỉ lệ để kiểm soát việc sử dụng tài nguyên của các ứng dụng khách khác nhau.

5. Phiên bản API (API Versioning):

• API Gateway cho phép bạn quản lý các phiên bản khác nhau của API của mình. Điều này giúp bạn giới thiệu các thay đổi API một cách an toàn và kiểm soát cách các ứng dụng khách tương tác với các phiên bản khác nhau.

6. Chuyển đổi dữ liệu (Data Transformation):

• Trong một số trường hợp, API Gateway có thể chuyển đổi dữ liệu giữa các định dạng khác nhau để đáp ứng các yêu cầu của các ứng dụng khách khác nhau.

7. Caching:

• API Gateway có thể lưu trữ tạm thời các kết quả của các yêu cầu API thường xuyên để cải thiện hiệu suất và giảm tải cho các microservice phía sau.

8. SSL Termination

• API Gateway có thể xử lý việc mã hóa và giải mã SSL, loại bỏ sự cần thiết để mỗi microservice tự thực hiện việc này.

Reverse Proxy trong API Gateway Pattern

Reverse Proxy là một phần của tính năng định tuyến gateway trong API Gateway Pattern. API Gateway hoạt động như một reverse proxy, giúp định hướng các yêu cầu đến các điểm cuối (endpoint) của các microservice nội bộ.

Thông thường, API Gateway sử dụng định tuyến lớp 7 (layer 7 ) cho các yêu cầu HTTP để thực hiện chuyển hướng yêu cầu. Tính năng định tuyến này cung cấp những lợi ích:

• Phân tách ứng dụng khỏi microservice nội bộ: API Gateway đóng vai trò trung gian, tách biệt các ứng dụng client khỏi các microservice nội bộ, giúp phân tách trách nhiệm trên lớp mạng.

• Giấu các hoạt động nội bộ: API Gateway cung cấp tính năng trừu tượng hóa (abstraction) đối với các microservice phía sau. Ngay cả khi có thay đổi trên các microservice backend, nó cũng sẽ không ảnh hưởng đến các ứng dụng client. Điều này có nghĩa là bạn không cần cập nhật lại ứng dụng client mỗi khi thay đổi dịch vụ backend.

Lợi ích của việc sử dụng Reverse Proxy:

• Cải thiện tính linh hoạt: Reverse Proxy cho phép bạn dễ dàng thêm hoặc loại bỏ các microservice mà không cần thay đổi code của ứng dụng client.

• Tăng tính sẵn sàng (availability): API Gateway có thể được cấu hình để định tuyến các yêu cầu đến các microservice dự phòng trong trường hợp một microservice gặp sự cố.

• Cải thiện bảo mật: API Gateway có thể thực hiện các kiểm tra bảo mật tập trung trước khi định tuyến các yêu cầu đến các microservice nội bộ.

.....