Thiết kế để mở rộng với tích hợp riêng tư của Amazon API Gateway

bởi James Beswick | Vào ngày 26 tháng 9 năm 2023 | trong Amazon API Gateway, Serverless | Permalink |  Share

Bài viết này được viết bời Lior Sadan, kiến trúc sư giải pháp cấp cao và Anandprasanna Gaitonde, kiến trúc sư giải pháp cáp cao.

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

Bài đăng trên blog này so sánh các lựa chọn kiến trúc để xây dựng tích hợp riêng tư, có khả năng mở rộng với API Gateway cho các dịch vụ microservices. Nó bao gồm REST và HTTP APIs và cách chúng sử dụng tích hợp riêng tư, đồng thời chỉ ra cách phát triển các kiến trúc microservices an toàn, có khả năng mở rộng.

Tổng Quan

Dưới đây là một cách triển khai điển hình của API Gateway tích hợp backend vào các microservices khác nhau: 

A typical API Gateway implementation with backend integrations to various microservices

API Gateway xử lý API layer, đồng thời tích hợp với các microservices backend đang chạy trên Amazon EC2, Amazon Elastic Container Service (ECS), hoặc Amazon Elastic Kubernetes Service (EKS). Blog này tập trung vào các microservices được đóng gói thành container mà tiết lộ các endpoints nội bộ mà sau đó API layer có thể tiếp tục tiết lộ ra ngoài.

Để giữ cho các microservices an toàn và được bảo vệ khỏi lưu lượng mạng bên ngoài, chúng thường được triển khai trong Amazon Virtual Private Cloud (VPC) trong một private subnet, cái mà không thể truy cập từ internet. API Gateway cung cấp một cách để tiết lộ những tài nguyên này một cách an toàn ngoài VPC thông qua các tích hợp riêng tư sử dụng VPC link. Tích hợp riêng tư chuyển tiếp lưu lượng bên ngoài được gửi đến các API đến các tài nguyên riêng tư, mà không tiết lộ các dịch vụ ra ngoài internet và không rời khỏi mạng AWS. Để biết thêm thông tin, hãy đọc Best Practices for Designing Amazon API Gateway Private APIs and Private Integration.

Tình huống ví dụ này có bốn microservices mà có thể được lưu trữ trong một hoặc nhiều VPC. Nó hiển thị các mẫu tích hợp các microservices với các bộ cân bằng tải front-end và API Gateway thông qua các liên kết VPC.

Mặc dù các liên kết VPC cho phép kết nối riêng tư tới các microservices, khách hàng có thể có các nhu cầu bổ sung:

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

API Gateway cung cấp HTTP APIs and REST APIs (xem Choosing between REST APIs and HTTP APIs) để xây dựng RESTful APIs. Đối với các kiến trúc microservices lớn hơn, loại API ảnh hưởng đến các yếu tố tích hợp:

Liên kết VPC hỗ trợ tích hợpHạn ngạch trên các liên kết VPC mỗi tài khoản mỗi Vùng
REST APINetwork Load Balancer (NLB)20
HTTP APINetwork Load Balancer (NLB), Application Load Balancer (ALB), and AWS Cloud Map10

Bài đăng này trình bày bốn tùy chọn tích hợp riêng tư, xem xét các khả năng và hạn ngạch khác nhau của liên kết VPC cho REST và HTTP APIs:

  • Tuỳ chọn 1: HTTP API sử dụng liên kết VPC tới nhiều NLBs hoặc ALBs.
  • Tuỳ chọn 2: REST API sử dụng nhiều liên kết VPC.
  • Tuỳ chọn 3: REST API sử dụng liên kết VPC với NLB.
  • Tuỳ chọn 4: REST API sử dụng liên kết  VPC với NLB và ALB targets.

Lựa chọn 1: HTTP API sử dụng liên kết VPC tới nhiều NLBs hoặc ALBs

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

Option 1: HTTP API using VPC link to multiple NLB or ALBs

Hai microservices đang ở trong một VPC duy nhất, mỗi microservice có một ALB riêng. The ALB listeners định hướng lưu lượng HTTPS đến các nhóm mục tiêu microservice backend tương ứng. Một liên kết VPC duy nhất được kết nối đến 2 ALB trong VPC đó. API Gateway sử dụng các quy tắc định tuyến path-based để chuyển tiếp các yêu cầu tới bộ cân bằng tải phù hợp và microservice liên quan. Phương pháp này được đề cập trong Best Practices for Designing Amazon API Gateway Private APIs and Private Integration – HTTP API. Mẫu CloudFormation templates để triển khai giải pháp này hiện có sẵn trên GitHub.

Bạn có thể thêm các ALBs và microservices trong giới hạn không gian IP của VPC. Sử dụng Network Address Usage (NAU) để thiết kế phân phối các microservice qua các VPCs. Mở rộng hơn một VPC bằng cách thêm các liên kết VPC để kết nối thêm nhiều VPCs, trong các hạn ngạch của liên kết VPC. Bạn cũng có thể mở rộng điều này bằng cách sử dụng các quy tắc định tuyến như path-based tại ALB để kết nối thêm dịch vụ sau một ALB duy nhất (xem Quotas for your Application Load Balancers). Kiến trúc này cũng có thể được xây dựng bằng cách sử dụng NLB.

Các lợi ích:

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

Lựa chọn 2: REST API sử dụng nhiều liên kết VPC

Đối với các REST APIs, kiến trúc để hỗ trợ nhiều microservices có thể khác nhau do những điều sau đây:

  • NLB là tích hợp riêng tư duy nhất được hỗ trợ cho REST APIs.
  • Liên kết VPC cho REST APIs chỉ có thể có duy nhất một NLB đích.
Option 2: REST API using multiple VPC links

Một liên kết VPC được yêu cầu cho mỗi ALB, ngay cả khi các NLBs đang trong cùng VPC. Mỗi NLB phục vụ một microservice, với một listener để định tuyến lưu lượng của API Gateway đến nhóm mục tiêu. Định tuyến API Gateway path-based gửi yêu cầu tới NLB phù hợp và microservice tương ứng. Việc thiết lập cần thiết cho tích hợp riêng tư này tương tự như ví dụ được mô tả trong Tutorial: Build a REST API with API Gateway private integration.

Để mở rộng hơn, thêm liên kết VPC và tích hợp NLB cho mỗi microservice, trong cùng một VPC hoặc các VPC khác nhau dựa trên nhu cầu và yêu cầu cô lập của bạn. Phương pháp này bị hạn chế bởi hạn ngạch của liên kết VPC mỗi tài khoản mỗi vùng.

Các lợi ích:

  • Một NLB duy nhất trong đường dẫn yêu cầu giảm độ phức tạp vận hành.
  • NLB riêng cho mỗi microservice cho phép triển khai microservice một cách độc lập.
  • Không có các bước tiếp theo trong đường dẫn yêu cầu API dẫn đến độ trễ thấp hơn.

Sự cân nhắc:

  • Hạn chế khả năng mở rộng do ánh xạ one-to-one của liên kết VPCs tới NLBs và microservices bị giới hạn bởi hạn ngạch của liên kết VPC mỗi tài khoản mỗi vùng.

Lựa chọn 3: REST API sử dụng liên kết VPC với NLB

Việc ánh xạ one-to-one các liên kết VPC tới NLB và microservice trong lựa chọn 2 có khả năng mở rộng giới hạn bởi vì hạn ngạch của liên kết VPC. Một lựa chọn thay thế là sử dụng nhiều microservices cho mỗi NLB.

Option 3: REST API using VPC link with NLB

Một NLB duy nhất hỗ trợ nhiều microservices trong một VPC bằng cách sử dụng nhiều listener, với mỗi listener trên một cổng riêng biệt cho mỗi microservice.Ở đây, NLB1 đứng trước 2 microservice trong một VPC. NLB2 đứng trước 2 microservices khác trong VPC thứ hai. Với nhiều microservices trên mỗi NLB, việc định tuyến được xác định cho REST API khi chọn điểm tích hợp cho một phương thức. Bạn xác định mỗi dịch vụ bằng cách sử dụng một sự kết hợp của việc chọn liên kết VPC, cái mà được tích hợp với một NLB cụ thể, và một cổng cụ thể được gán cho mỗi microservice tại NLB Listener và được xử lý từ Endpoint URL.

Để mở rộng quy mô thêm, thêm listeners vào các NLBs hiện có, limited by Quotas for your Network Load Balancers. Trong trường hợp mỗi microservice có load balancer hoặc điểm truy cập riêng của mình, chúng được cấu hình làm mục tiêu cho NLB. Ngoài ra, tích hợp thêm các microservices bằng cách thêm các liên kết VPC.

Các lợi ích:

  • Quy mô lớn hơn – bị hạn chế bởi các hạn mức NLB listener và hạn mức liên kết VPC.
  • Quản lý ít NLBs hỗ trợ nhiều microservice giảm độ phức tạp vận hành.
  • Độ trễ thấp nhất với một NLB duy nhất trong đường dẫn yêu cầu.

Sự cân nhắc:

  • Shared NLB configuration limits independent deployments for individual microservices teams.

Lựa chọn 4: REST API sử dụng liên kết VPC với NLB và ALB targets

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

Option 4: REST API using VPC link with NLB and ALB targets

Một liên kết VPC (VPCLink1) được tạo ra với NLB1 trong VPC1. ALB1 và ALB2 front-end các microservices mS1 và mS2, được thêm vào như các targets NLB trên các listeners riêng biệt. VPC2 có cấu hình tương tự. Nhu cầu cô lập của bạn và không gian địa chỉ IP xác định liệu các microservice có thể nằm trong một hoặc nhiều VPCs.

Để mở rộng quy mô thêm:

  • Tạo thêm liên kết VPC để tích hợp với các NLBs mới.
  • Thêm NLB listenrs để hỗ trợ nhiều ALB targets.
  • Cấu hình ALB với luật path-based để định tuyến request tới nhiều microservices.

Các lợi ích:

  • Khả năng mở rộng cao tích hợp các dịch vụ sử dụng NLBs và ALBs.
  • Triển khai độc lập cho từng nhóm là có thể khi mà mỗi ALB được dành riêng cho một microservice.

Sự 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ác cân nhắc và biện pháp thực hành tốt nhất 

Ngoài các xem xét về quy mô với việc tích hợp liên kết VPC được thảo luận trong blog này, còn có các xem xét khác:

Kết luận

Blog này khám phá việc xây dựng các tích hợp API Gateway có khả năng mở rộng cho các microservices sử dụng liên kết VPC. Các liên kết VPC cho phép chuyển tiếp lưu lượng từ bên ngoài đến các backend microservice mà không cần phải tiết lộ ra internet hoặc rời khỏi mạng AWS. Bài đăng bao gồm các cân nhắc mở rộng dựa trên sử dụng REST APIs si với HTTP APIs và cách mà chúng tích hợp với NLBs hoặc NLBs trên các VPC khác nhau.

Mặc dù loại API và lựa chọn cân bằng tải có các yếu tố thiết kế khác, nhưng quan trọng là cần phải ghi nhớ các cân nhắc về quy mô đã được thảo luận trong bài đăng này khi thiết kế kiến trúc API layer của bạn. Bằng cách tối ưu hoá việc triển khai API Gateway cho  các nhu cầu về hiệu suất, độ trễ và vận hành, bạn có thể xây dựng một API mạnh mẽ, an toàn để hiển thị các microservice trên quy mô lớn.

Để biết thêm các tài nguyên học tập serverless, hãy truy cập Serverless Land.

TAGS: contributed, serverless

Mọi người có thể đọc bài viết gốc tại đây