Kiến trúc để mở rộng microservice với tích hợp riêng API Gateway

by James Beswick | on 26 SEP 2023 | in Amazon API Gateway, Serverless | Permalink |  Share

This post is written by Lior Sadan, Sr. Solutions Architect, and Anandprasanna Gaitonde,

Sr. Solutions Architect

Các tổ chức sử dụng  Amazon API Gateway để dựng APIs an toàn hơn và mạnh mẽ hơn để giao tiếp với các services nội bộ tới các ứng dụng khác và người dùng bên ngoài. Khi môi trường phát triển tới nhiều microservices, khách hàng phải đảm bảo API layer có thể giải quyết khả năng mở rộng mà không làm giảm bảo mật và hiệu năng. API Gateway cung cấp nhiều loại API và tùy chọn tích hợp khác nhau, và người xây dựng phải cân nhắc các lựa chọn ảnh hưởng của khả năng mở rộng tới bảo mật và hiệu năng khi mà môi trường microservices được mở rộng

Blog này so sánh kiến trúc khác nhau để xây dựng các tích hợp riêng tư với API Gateway cho sự mở rộng của microservices. Nó bao gồm REST và HTTP APIs và sử dụng VPC Link , và chỉ cách triển khai mở rộng microservices

Overview

Đây là các loại triển khai API Gateway với backend tích hợp nhiều microservices

API Gateway xử lý API layer, trong khi tích hợp với backend microservices đang chạy trên Amazon EC2, Amazon Elastic Container Service (ECS), or Amazon Elastic Kubernetes Service (EKS). Blog này tập trung vào microservice đã được container hóa để giao tiếp nội bằng endpoints qua API layer rồi giao tiếp qua bên ngoài

Để giữ microservices an toàn và chặn traffic từ bên người, chúng ta thường triển khai trong một Amazon Virtual Private Cloud (VPC) trong một private subnet, chúng không có khả năng truy cập vào từ bên ngoài. API Gateway cung cấp cách để tiếp xúc các tài nguyên này một cách an toàn bên ngoài VPC thông qua tích hợp riêng bằng VPC link. Cách tích hợp này chuyển tiếp traffic từ bên ngoài gửi đến cho APIs tới resources bên trong mà không tiếp xúc với bất kì services nào thông qua internet và không rời khỏi mạng AWS. Đọc tìm hiểu thêm thông qua Best Practices for Designing Amazon API Gateway Private APIs and Private Integration.

Kịch bản ví dụ là có 4 microservices chúng được đặt tại một hoặc nhiều VPCs, Nó chỉ ra những khuôn mẫu tích hợp microservices với front-end load balancers và API Gateway thông qua VPC links.

Trong khi VPC links có khả năng kết nối riêng tư tới microservices, khách hàng có thể sẽ có những yêu cầu bổ sung sau:

  • Tăng khả năng mở rộng: Hỗ trợ lượng lớn microservices đằng sau API Gateway
  • Triển khai độc lập: Bộ cân bằng tải chuyên dụng cho mỗi microservice cho phép các nhóm thực hiện triển khai blue/green độc lập mà không ảnh hưởng tới các team khác
  • Giảm sự phức tạp: Có khả năng sử dụng những microservice cân bằng tải hiện có thay vì giới thiệu cái mới để tích hợp được API Gateway
  • Độ trễ thấp: Đảm bảo tối thiểu trễ trong luồng API gửi và trả

API Gateway cung cấp 2 lựa chọn HTTP APIs và REST APIs  (see Choosing between REST APIs and HTTP APIs) để dựng RESTful APIs. Dành cho kiến trúc microservices lớn, Các loại API ảnh hướng tới việc tích hợp:

VPC link hỗ trợ tích hợpTrạng thái VPC links cho mỗi account cho mỗi Region
RestAPINetwork Load Balancer (NLB)20
HTTP APINetwork Load Balancer (NLB), Application Load Balancer (ALB), and AWS Cloud Map10

Bài đăng này đại diện cho 4 cách tích hợp nội bộ tính cho những khả năng, trạng thái VPC link cho REST và HTTP APIs khác nhau:

  • HTTP API sử dụng VPC link tới nhiều NLVs hoặc ALBs
  • REST API sử dụng nhiều VPC links
  • REST API sử dụng VPC link với NLB
  • REST API sử dụng VPC link với NLB và ALBs targets

Lựa chọn 1: HTTP API sử dụng VPC link tới nhiều NLVs hoặc ALBs

HTTP APIs cho phép kết nối một VPC link cho nhiều ALBs, NLBs hoặc tài nguyên đã đăng kí với AWS Cloud Map. Điều này cung cấp một cách tiếp cận phân nhánh để kết nối với nhiều backend microservices. Tuy nhiên, cân bằng tải được tích hợp với một VPC cụ thể nên được đặt trong một VPC

Hai microservices đặt trong một VPC, mỗi microservice cùng với ALB chuyên dụng riêng. ALB listener hướng HTTPs traffic tới từng nhóm backend microservice tương ứng. Một VPC link được kết nối tới 2 ALBs trong VPC. API Gateway sử dụng quy tắc định tuyến dựa trên đường dẫn để chuyển tiếp yêu cầu tới bộ cân bằng tải và microservice được gắn thích hợp. Cách tiếp cận này được bao gồm trong Best Practices for Designing Amazon API Gateway Private APIs and Private Integration – HTTP API. Ví dụ mẫu CloudFormation để triển khai giải pháp hiện có ở trên GitHub.

Bạn có thể thêm ALBs và microservices ở trong khoảng giới hạn VPC IP. Sử dụng Network Address Usage (NAU) để thiết kế phân phối các microservices qua các VPCs. Mở rộng vượt qua một VPC bằng cách thêm VPC links để kết nối tới nhiều VPCs, ở trong giới hạn VPC link. Bạn có thể mở rộng thêm chúng bằng cách sử dụng quy tắc định tuyến dựa trên đường dẫn tại ALB để kết nối nhiều services đằng sau một ALB(see Quotas for your Application Load Balancers). Kiến trúc này cũng được xây dựng khi sử dụng một NLB

Lợi ích:

  • Khả năng mở rộng cao. Phân tán tới nhiều microservices bằng cách sử dụng một VPC link hoặc khả năng ghép kênh của ALB/ NLB
  • Trực tiếp tích hợp với những microservice cân bằng tải hiện có giúp loại bỏ nhu cầu giới thiệu thành phần mới và giản gánh nặng vận hành
  • Độ trễ thấp hơn cho API gửi/ trả nhờ trực tiếp tích hợp
  • bộ cân bằng tải chuyên dụng riêng cho mỗi microservice có khả năng độc lập triển khai cho microservices teams

Lựa chọn 2: REST API sử dụng nhiều VPC links

Dành cho REST APIs, kiến trúc hỗ trợ nhiều microservice có thể khác vì những cân nhắc sau:

  • NLB chỉ hõ trợ tích hợp riêng cho REST APIs
  • VPC links cho REST APIs có thể có chỉ một mục tiêu NLB

Mỗi VPC link được đáp ứng mỗi NLB, thậm chí nếu nhiều NLBs ở cùng một VPC. Mỗi NLB phục vụ một microservice, với mỗi port để định tuyến API Gateway traffic tới một nhóm mục tiêu. Đường dẫn API Gateway dựa trên định tuyến gửi yêu cầu tới NLV và microservice tương ứng. Cách setup yêu cầu cho tích hợp riêng tư là ví dụ thường gặp được mô tả trong  Tutorial: Build a REST API with API Gateway private integration.

Để mở rộng hơn, thêm VPC link và tích hợp NLB cho mỗi microservice, trông mỗi hoặc khác VPC dựa trên nhu cầu và yêu cầu cash li. Cách tiếp cận này bị hạn chế bởi giới hạn VPC link cho mỗi account cho môi Region

Lợi ích:

  • Mỗi NLB trong đường dẫn yêu cầu thì giảm độ phức tạp khi vận hành
  • NLVs chuyên biệt cho phép triển khai microservice độc lập

Cân nhắc:

  • Hạn chế sự mở rộng bởi vì kết nối 1 với 1 của VPC linsk tới NLBs và microservices bị giới hạn bởi giới hạn của VPC links cho mỗi acc cho mỗi Region

Lựa chọn 3: REST API sử dụng VPC link với NLB

Ánh xạ 1-1 của VPC links tới NLBs và microservices trong option 2 giới hạn khả năng mở rộng vì giới hạn của VPC link. Một sự thay thế là sử dụng nhiều microservice cho mỗi NLBB.

Một NLB trước nhiều microservices trong một VPC bằng cách sử dụng nhiều port, với mỗi port cho mỗi microservice. Tại đây, NLB1 trước 2 microservices trong một VPC. Với nhiều microservice cho mỗi NLB, định tuyến được định nghĩa cho REST API khi chọn điển tích hợp cho cách thức. Bạn định nghĩa mỗi service bằng cách sử dụng kết hợp việc chọn VPC link, chúng được tích hợp với mỗi NLB cụ thể, và một port cụ thể rằng chung được truyền cho mỗi microservice tại port và xử lý từ Endpoint URL

Để mở rộng thêm, thêm port tới NLB sẵn có, bị hạn chế bởi Quotas for your Network Load Balancers. Trong trường hợp mỗi microservice có bộ cân bằng tải chuyên dụng hoặc điểm truy cập, chúng được cấu hình giống như những mục tiêu tới NLB. Ngoài ra, tích hợp thêm các microservices bằng cách bổ sung thêm VPC links

Lợi ích:

  • Khả năng mở rộng lớn hơn – bị giới hạn bởi số lượng NLB listener và VPC link
  • Quản lý ít NLB hỗ trợ nhiều microservices giảm độ phức tạp khi vận hành
  • Độ trễ thấp với một NLV trong đường dẫn 

Cân nhắc:

  • Cùng cáu hình NLB giới hạn triển khai độc lập cho các microservices teams

Lựa chọn 4: REST API sử dụng VPC link với NLB và ALBs targets

Khách hàng thường xây dựng microservices với ALB như những điểm truy cập. Để tiếp xúc với những điểm truy cập này thông qua API Gateway REST APIs, bạn có thể tận dụng  ALB as a target for NLB. Khuôn mẫu này cũng tăng số lượng microservices được hỗ trợ so sánh với kiến trúc của lựa chọn 3

Một VPC link(VPCLink1) được tạo với NLB1 trong VPC1. ALB1 và ALB2 tới 2 microservices mS1 và mS2. Được thêm như NLB target trên mỗi listener riêng biệt. VPC2 có một cấu hình tương tự. Nhu cầu cô lập và vùng IP xác định xem nếu microservice có thể đặt trong một hoặc nhiều VPC.

Để mở rộng quy mô hơn nữa: 

  • Tạo thêm VPC link để tích hợp với NLB
  • Thêm NLB listener để hỗ hợp nhiều ALB target
  • Cấu hình ALB với quy tắc dựa trên đường dẫn để định truyến request tới nhiều microservice

Lợi ích:

  • Các dịch vụ tích hợp có khả năng mở rộng dịch vụ cao sử dụng NLB và ALB
  • Triển khai độc lập mỗi team có khả thi khi mỗi ALB là chuyên biệt riêng tới mỗi microservice

Cân nhắc:

  • Nhiều bộ cân bằng tải trong đường dẫn yêu cầu có thể tăng trễ

Cân nhắc và tối ưu

Ngoài những cân nhắc về quy mô với việc tích hợp liên kết VPC được thảo luận, còn có những cân nhắc khác:

Kết luận

Bài viết này khám phá cách xây dựng tích hợp API Gateway để có thể mở rộng cho microservice sử dụng VPC links. VPC links cho phép chuyển tiếp traffic bên ngoài tới backend microservice mà không tiếp xúc với internet hoặc rời mạng AWS. Bài đăng đề cập đến những cân nhắc về việc mở rộng quy mô dựa trên việc sử dụng API REST so với API HTTP và cách chúng tích hợp với NLB hoặc ALB trên VPC

Trong khi loại API và lựa chọn LB có những nhân tố thiết kế khác, điều quan trọng là ghi nhớ các cân nhắc về tỷ lệ được thảo luận trong blog khi thiết kế kiến trúc API layer của bạn. Bằng cách tối ưu sự triển khia API Gateway để đạt được hiệu suất, độ trễ, và nhu cầu vận hành, Bạn có thể xây dựng một API an toàn và mạnh mẽ để giao tiếp với microservice khi mở rộng

For more serverless learning resources, visit Serverless Land.

TAGS: contributed, serverless

One response to “Kiến trúc để mở rộng microservice với tích hợp riêng API Gateway”

  1. How can i using one API gateway to public service for ALB in cross account? Because we deploy ingress VPC in Network Account and run workload & ALB in Workload Account.

    Like

Leave a comment