GIỚI THIỆU VỀ KONG GATEWAY

1. Vấn đề của Microservice và vì sao dùng KONG Gateway

Tham khảo: https://docs.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/direct-client-to-microservice-communication-versus-the-api-gateway-pattern

Trong kiến trúc microservices, mỗi service là một API endpoint phục vụ một chức năng cụ thể.

Một cách tiếp cận khả thi là sử dụng kiến trúc giao tiếp trực tiếp từ client-to-service. Theo cách tiếp cận này, mỗi một request có thể được gửi trực tiếp tới một API endpoint. Hình dưới đây là minh họa cho kiến trúc này.

Kiến trúc này rất phù hợp với các cách tổ chức monolith hay các hệ thống microservice nhỏ. Tuy nhiên khi phát triển thành các hệ thống microservice quy mô lớn hơn: về số lượng request, về số lượng server cung cấp API, v.v... Một số câu hỏi mà lúc này kiến trúc này chưa đáp ứng được:

• Làm cách nào để các client có thể giảm thiểu số lượng request đến back end và giảm giao tiếp trò chuyện với nhiều microservices?
• Làm cách nào bạn có thể xử lý các mối quan tâm xuyên suốt như ủy quyền, chuyển đổi dữ liệu và gửi yêu cầu động?
• Làm cách nào để client có thể giao tiếp với các dịch vụ sử dụng giao thức không thân thiện?
• Mỗi service sẽ expose ra một port nhất định với Internet, làm sao để đảm bảo một mức độ security với tất cả service và port đang được triển khai? Attacker thường chỉ cần một openning port để tấn công hệ thống.

Để khác phục những vấn đề trên thì kiến trúc sử dụng API Gateway đã được tin dùng và vượt qua những trở ngại đó. Hình minh họa dưới đây mô tả một API Gateway phổ biến là KONG Gateway (KG) được đặt giữa Client và các services.

• KG cho phép chúng ta hướng mọi request đến một / nhiều port do KG quản lý, từ đó việc quản lý, monitor, logging, auth, v.v... sẽ hoàn toàn ủy thác cho KG quản trị. Việc này giảm tải khối lượng công việc của Backend / API Developer và giúp họ tập trung vào công việc hơn.

• Về mặt Security, user từ bên ngoài sẽ chỉ biết rằng có server đang mở một vài port duy nhất, và mọi dự định tấn công sẽ được KG xử lý và giữ lại ở tầng API Gateway, từ đó tránh được server bị khai thác.

• Các port đang mở của API cần dùng sẽ được che giấu đi và hạn chế truy cập. Vì không cần mở port trực tiếp với bên ngoài qua tường lửa --> Request từ bên ngoài hệ thống không thể truy cập được những API này trừ khi đã đi qua KG.

• Load Balancing và Request Caching để tối ưu hóa hệ thống

2. Chức năng quản lý service và route của KG

Mỗi service sẽ được đăng kí tại KG và chúng ta có thể tạo thêm nhiều Route ứng với mỗi service. Tức là một đường dẫn của chúng ta hiện có thể có nhiều URL khác nhau cùng trỏ về một Service.

Ví dụ sau đây là:

• Ta có một service service a đang triển khai tại server (ip=26.17.xx.xxx) và port để sử dụng là port 8000. API sẽ là: http://26.17.xx.xxxx:8000/ KG có ip=172.26.xx.xxx và port=5000.

• Sau khi ta đăng ký trên KG service này, ta lần lượt tạo ra 3 route là /service-a, /service-nay-la-service-a, /service-a-la-service-nay

      + URL 1: http://172.26.xx.xxx:5000/service-a
      + URL 2: http://172.26.xx.xxx:5000/service-nay-la-service-a
      + URL 3: http://172.26.xx.xxx:5000/service-a-la-service-nay
  

• Client giờ có thể gọi cả 3 URL này, và chúng đều trỏ vào service a. Và client cũng hoàn toàn không thể biết đang dùng port nào để gọi đến service này. Trong trường hợp client biết được port=8000 và biết chính xác server ip=26.17.xx.xxxx, họ cũng không thể gọi trực tiếp API này vì port 8000 không được tường lửa (deny from firewall) của HĐH cho phép nhận request từ bên ngoài.

• Hướng dẫn về việc đăng ký Service và Route tại Hướng dẫn đăng ký service và routing.

3. Chức năng quản lý cấu hình Load-Balancing của KG

• Việc chia tải giữa các server khác nhau để đảm bảo service luôn hoạt động với latency trễ nhất là vô cùng CRITICAL với microservice. KG cung cấp giải pháp Load-Balancing với tên gọi là Upstream. Một Upstream sau khi được cấu hình sẽ đón request được gửi đến và phân phối request đến một hay nhiều server có service đang chạy cùng một lúc. Việc phân phối này có thể là chia đều, hoặc theo một trọng số do người dùng quy định.

• Thay vì kiến trúc: "1 request - 1 service" thì thông qua Load-Balancing của KG đã trở thành "1 request - multiple service"

4. Các chức năng khác của KG

5. Dễ dàng tích hợp 3rd-Plugin và customizable Plugin