bởi James Beswick | ngày 30 tháng 10 năm 2023 | trong Amazon API Gateway, Amazon DynamoDB, Amazon EventBridge, Amazon Simple Storage Service (S3), AWS Lambda, AWS Step Functions, Serverless | Liên kết cố định | Chia sẻ

Bài đăng này được viết bởi Daniel Wirjo, Solutions Architect, and Justin Plock, Principal Solutions Architect.

Thường được gọi là API đảo ngược hoặc API đẩy, webhooks cung cấp cách để các ứng dụng tích hợp với nhau và giao tiếp gần như theo thời gian thực. Nó cho phép tích hợp cho các sự kiện kinh doanh và hệ thống.

Cho dù bạn đang xây dựng một ứng dụng phần mềm dưới dạng dịch vụ (SaaS) tích hợp với quy trình làm việc của khách hàng hay thông báo giao dịch từ nhà cung cấp, webhooks đều đóng một vai trò quan trọng trong việc thúc đẩy sự đổi mới, nâng cao trải nghiệm người dùng và hợp lý hóa hoạt động.

Bài đăng này giải thích cách xây dựng bằng webhook trên AWS và bao gồm hai tình huống:

• Nhà cung cấp Webhooks: Ứng dụng SaaS gửi webhook tới API bên ngoài.
• Người sử dụng Webhooks: API nhận webhook có khả năng xử lý tải trọng lớn.

Nó bao gồm các kiến trúc tham chiếu cấp cao có cân nhắc, các biện pháp thực hành tốt nhất và mẫu mã để hướng dẫn bạn triển khai.

Gửi webhook

Để gửi webhook, bạn tạo sự kiện và phân phối chúng tới API của bên thứ ba. Những sự kiện này tạo điều kiện thuận lợi cho việc cập nhật, quy trình làm việc và hành động trong hệ thống của bên thứ ba. Ví dụ: nền tảng thanh toán (nhà cung cấp) có thể gửi thông báo về trạng thái thanh toán, cho phép các cửa hàng thương mại điện tử (người tiêu dùng) vận chuyển hàng hóa sau khi xác nhận.

Kiến trúc tham chiếu AWS dành cho nhà cung cấp webhook

Kiến trúc bao gồm hai dịch vụ:

• Phân phối webhook: Một ứng dụng phân phối webhook đến điểm cuối bên ngoài do người dùng chỉ định.

• Quản lý đăng ký: API quản lý cho phép người tiêu dùng quản lý cấu hình của họ, bao gồm chỉ định điểm cuối để phân phối và sự kiện nào để đăng ký.

Những điều cần cân nhắc và phương pháp hay nhất để gửi webhook

Khi xây dựng một ứng dụng để gửi webhook, hãy xem xét các yếu tố sau:

Tạo sự kiện: Xem xét cách bạn tạo sự kiện. Ví dụ này sử dụng Amazon DynamoDB làm nguồn dữ liệu. Các sự kiện được tạo bằng cách thu thập dữ liệu thay đổi cho Luồng DynamoDB và gửi đến Amazon EventBridge Pipes. Sau đó, bạn đơn giản hóa định dạng phản hồi của DynamoDB bằng cách sử dụng biến áp đầu vào.

Với EventBridge, bạn gửi sự kiện gần như theo thời gian thực. Nếu các sự kiện không phụ thuộc vào thời gian, bạn có thể gửi nhiều sự kiện cùng lúc. Điều này có thể được thực hiện bằng cách thăm dò các sự kiện mới ở tần suất được chỉ định bằng cách sử dụng Trình lập lịch EventBridge. Để tạo sự kiện từ các nguồn dữ liệu khác, hãy xem xét các phương pháp tương tự với Thông báo sự kiện của Amazon Simple Storage Service (S3) hoặc Amazon Kinesis.

Lọc: EventBridge Pipes hỗ trợ lọc bằng cách khớp các mẫu sự kiện trước khi sự kiện được định tuyến đến đích mục tiêu. Ví dụ: bạn có thể lọc các sự kiện liên quan đến hoạt động cập nhật trạng thái trong bảng thanh toán DynamoDB tới điểm cuối API của người đăng ký có liên quan.

Phân phối: Đích API EventBridge phân phối các sự kiện bên ngoài AWS bằng lệnh gọi API REST. Để bảo vệ điểm cuối bên ngoài khỏi sự gia tăng lưu lượng truy cập, bạn đặt giới hạn tốc độ gọi. Ngoài ra, các lần thử lại có thời gian chờ theo cấp số nhân được xử lý tự động tùy thuộc vào lỗi. Hàng đợi thư chết của Amazon Simple Queue Service (SQS) sẽ giữ lại những tin nhắn không thể gửi được. Chúng có thể cung cấp khả năng phân phối có thể mở rộng và linh hoạt.

Cấu trúc tải trọng: Xem xét cách người tiêu dùng xử lý tải trọng sự kiện. Ví dụ này sử dụng biến áp đầu vào để tạo tải trọng có cấu trúc, phù hợp với thông số kỹ thuật của CloudEvents. CloudEvents cung cấp định dạng tiêu chuẩn ngành và cấu trúc tải trọng chung, cùng với các công cụ dành cho nhà phát triển và SDK dành cho người tiêu dùng.

Kích thước tải trọng: Để phân phối nhanh chóng và đáng tin cậy, hãy giữ kích thước tải trọng ở mức tối thiểu. Hãy cân nhắc việc chỉ cung cấp những thông tin chi tiết cần thiết, chẳng hạn như số nhận dạng và trạng thái. Để biết thêm thông tin, bạn có thể cung cấp cho người tiêu dùng một API riêng. Sau đó, người tiêu dùng có thể gọi riêng API này để lấy thông tin bổ sung.

Bảo mật và ủy quyền: Để phân phối sự kiện một cách an toàn, bạn thiết lập kết nối bằng phương thức ủy quyền như OAuth. Dưới lớp vỏ bọc, kết nối sẽ lưu trữ thông tin xác thực trong AWS Secrets Manager, nơi mã hóa thông tin xác thực một cách an toàn.

Quản lý đăng ký: Xem xét cách người tiêu dùng có thể quản lý đăng ký của họ, chẳng hạn như chỉ định điểm cuối HTTPS và loại sự kiện để đăng ký. DynamoDB lưu trữ cấu hình này. Amazon API Gateway, Amazon Cognito và AWS Lambda cung cấp API quản lý cho hoạt động.

Chi phí: Trong thực tế, việc gửi webhook sẽ phát sinh chi phí. Chi phí này có thể trở nên đáng kể khi bạn phát triển và tạo ra nhiều sự kiện hơn. Hãy cân nhắc triển khai các chính sách sử dụng, hạn ngạch và chỉ cho phép người tiêu dùng đăng ký các loại sự kiện mà họ cần.

Kiếm tiền: Cân nhắc tính phí cho người tiêu dùng dựa trên khối lượng hoặc cấp độ sử dụng của họ. Ví dụ: bạn có thể cung cấp cấp độ miễn phí để cung cấp quyền truy cập ít tốn kém vào webhooks nhưng chỉ tối đa một khối lượng nhất định. Để có thêm khối lượng, bạn tính phí sử dụng phù hợp với giá trị doanh nghiệp mà webhook của bạn cung cấp. Với số lượng lớn, bạn cung cấp cấp cao cấp nơi bạn cung cấp cơ sở hạ tầng dành riêng cho một số người tiêu dùng nhất định.

Giám sát và xử lý sự cố: Ngoài kiến trúc, hãy xem xét các quy trình cho hoạt động hàng ngày. Vì điểm cuối được quản lý bởi các bên bên ngoài nên hãy cân nhắc việc bật tính năng tự phục vụ. Ví dụ: cho phép người tiêu dùng xem trạng thái, phát lại sự kiện và tìm kiếm nhật ký webhook trước đây để chẩn đoán sự cố.

Kịch bản nâng cao: Ví dụ này được thiết kế cho các trường hợp sử dụng phổ biến. Đối với các kịch bản nâng cao, hãy xem xét các dịch vụ tích hợp ứng dụng thay thế lưu ý Hạn ngạch dịch vụ của chúng. Ví dụ: Dịch vụ thông báo đơn giản của Amazon (SNS) để phân phát cho số lượng người tiêu dùng lớn hơn, Lambda để linh hoạt tùy chỉnh tải trọng và xác thực, cũng như AWS Step Functions để điều phối mẫu cầu dao nhằm hủy kích hoạt những người đăng ký không đáng tin cậy.

Đang nhận webhook

Để nhận webhook, bạn cần có API để cung cấp cho nhà cung cấp webhook. Ví dụ: cửa hàng thương mại điện tử (người tiêu dùng) có thể dựa vào thông báo do nền tảng thanh toán (nhà cung cấp) của họ cung cấp để đảm bảo hàng hóa được vận chuyển kịp thời. Webhooks đưa ra một kịch bản đặc biệt vì người tiêu dùng phải có khả năng mở rộng, linh hoạt và đảm bảo rằng tất cả các yêu cầu đều được nhận.

Kiến trúc tham chiếu AWS dành cho người tiêu dùng webhook

Trong trường hợp này, hãy xem xét một trường hợp sử dụng nâng cao có thể xử lý tải trọng lớn bằng cách sử dụng mẫu xác nhận quyền sở hữu.

Ở cấp độ cao, kiến trúc bao gồm:

• API: Điểm cuối API để nhận webhook. Sau đó, một hệ thống hướng sự kiện sẽ ủy quyền và xử lý các webhooks đã nhận.
• Cửa hàng tải trọng: S3 cung cấp dung lượng lưu trữ có thể mở rộng cho tải trọng lớn.
• Xử lý Webhook: Ống EventBridge cung cấp kiến trúc có thể mở rộng để xử lý. Nó có thể bó, lọc, làm phong phú và gửi các sự kiện đến một loạt các dịch vụ xử lý làm mục tiêu.

Những điều cần cân nhắc và các phương pháp hay nhất để nhận webhook

Khi xây dựng một ứng dụng để nhận webhook, hãy xem xét các yếu tố sau:

Khả năng mở rộng: Nhà cung cấp thường gửi các sự kiện khi chúng xảy ra. API Gateway cung cấp điểm cuối được quản lý có thể mở rộng để nhận sự kiện. Nếu không có sẵn hoặc bị hạn chế, nhà cung cấp có thể thử lại yêu cầu, tuy nhiên, điều này không được đảm bảo. Vì vậy, điều quan trọng là phải cấu hình các giới hạn tốc độ và số lần truyền phù hợp. Yêu cầu điều tiết tại điểm đầu vào sẽ giảm thiểu tác động đến các dịch vụ hạ nguồn, trong đó mỗi dịch vụ có hạn ngạch và giới hạn riêng. Trong nhiều trường hợp, nhà cung cấp cũng nhận thức được tác động lên các hệ thống hạ nguồn. Do đó, họ gửi các sự kiện ở giới hạn tốc độ ngưỡng, thường lên tới 500 giao dịch mỗi giây (TPS).

Ngoài ra, API Gateway cho phép bạn xác thực các yêu cầu, giám sát mọi lỗi và bảo vệ khỏi việc từ chối dịch vụ phân tán (DDoS). Điều này bao gồm các cuộc tấn công Lớp 7 và Lớp 3, là những mối đe dọa phổ biến đối với người tiêu dùng webhook khi bị lộ ra công chúng.

Ủy quyền và Xác minh: Nhà cung cấp có thể hỗ trợ các phương thức ủy quyền khác nhau. Hãy xem xét một tình huống phổ biến với Mã xác thực thư dựa trên hàm băm (HMAC), trong đó một bí mật chung được thiết lập và lưu trữ trong Trình quản lý bí mật. Sau đó, hàm Lambda sẽ xác minh tính toàn vẹn của tin nhắn, xử lý chữ ký trong tiêu đề yêu cầu. Thông thường, chữ ký chứa một nonce được đánh dấu thời gian có thời hạn sử dụng để giảm thiểu các cuộc tấn công lặp lại, trong đó kẻ tấn công gửi các sự kiện nhiều lần. Ngoài ra, nếu nhà cung cấp hỗ trợ OAuth, hãy cân nhắc việc bảo mật API bằng Amazon Cognito.

Kích thước tải trọng: Nhà cung cấp có thể gửi nhiều kích cỡ tải trọng khác nhau. Các sự kiện có thể được gộp thành một yêu cầu lớn hơn hoặc chúng có thể chứa thông tin quan trọng. Xem xét giới hạn kích thước tải trọng trong hệ thống hướng sự kiện của bạn. API Gateway và Lambda có giới hạn là 10 Mb và 6 Mb. Tuy nhiên, DynamoDB và SQS bị giới hạn ở 400kb và 256kb (có phần mở rộng cho các tin nhắn lớn), điều này có thể gây ra tắc nghẽn cổ chai.

Thay vì xử lý toàn bộ tải trọng, S3 lưu trữ tải trọng đó. Sau đó, nó được tham chiếu trong DynamoDB thông qua tên nhóm và khóa đối tượng. Điều này được gọi là mẫu kiểm tra xác nhận quyền sở hữu. Với phương pháp này, kiến trúc hỗ trợ tải trọng lên tới 6 MB, theo hạn mức tải trọng của lệnh gọi Lambda.

Tính tạm thời: Để đảm bảo độ tin cậy, nhiều nhà cung cấp ưu tiên phân phối ít nhất một lần, ngay cả khi điều đó có nghĩa là không đảm bảo chính xác một lần phân phối. Họ có thể truyền cùng một yêu cầu nhiều lần, dẫn đến trùng lặp. Để xử lý vấn đề này, hàm Lambda sẽ kiểm tra mã định danh duy nhất của sự kiện với các bản ghi trước đó trong DynamoDB. Nếu chưa được xử lý, bạn sẽ tạo một mục DynamoDB.

Thứ tự: Xem xét việc xử lý các yêu cầu theo thứ tự dự kiến. Vì hầu hết các nhà cung cấp đều ưu tiên phân phối ít nhất một lần nên các sự kiện có thể không theo thứ tự. Để biểu thị thứ tự, các sự kiện có thể bao gồm dấu thời gian hoặc mã nhận dạng trình tự trong tải trọng. Nếu không, việc đặt hàng có thể được thực hiện trên cơ sở nỗ lực tối đa dựa trên thời điểm nhận được webhook. Để xử lý việc đặt hàng một cách đáng tin cậy, hãy chọn các dịch vụ hướng sự kiện đảm bảo việc đặt hàng. Ví dụ này sử dụng Luồng DynamoDB và Ống EventBridge.

Xử lý linh hoạt: EventBridge Pipes cung cấp mục tiêu tích hợp cho một loạt dịch vụ hướng đến mục tiêu. Bạn có thể định tuyến các sự kiện đến các mục tiêu khác nhau dựa trên các bộ lọc. Các loại sự kiện khác nhau có thể yêu cầu các bộ xử lý khác nhau. Ví dụ: bạn có thể sử dụng Step Functions để điều phối các quy trình công việc phức tạp, Lambda cho các hoạt động điện toán với thời gian thực hiện dưới 15 phút, SQS để đệm các yêu cầu và Amazon Elastic Container Service (ECS) cho các tác vụ điện toán chạy trong thời gian dài. EventBridge Pipes cung cấp khả năng chuyển đổi để đảm bảo chỉ gửi những tải trọng cần thiết và bổ sung thông tin nếu cần thêm thông tin.

Chi phí: Ví dụ này xem xét trường hợp sử dụng có thể xử lý tải trọng lớn. Tuy nhiên, nếu bạn có thể đảm bảo rằng nhà cung cấp gửi tải trọng tối thiểu, hãy xem xét kiến trúc đơn giản hơn không có mẫu xác nhận quyền sở hữu để giảm thiểu chi phí.

Phần kết luận

Webhooks là một phương pháp phổ biến để các ứng dụng giao tiếp cũng như để các doanh nghiệp cộng tác và tích hợp với khách hàng và đối tác.

Bài đăng này hướng dẫn cách bạn có thể xây dựng các ứng dụng để gửi và nhận webhook trên AWS. Nó sử dụng các dịch vụ serverless như EventBridge và Lambda, rất phù hợp cho các trường hợp sử dụng theo sự kiện. Nó bao gồm các kiến trúc tham chiếu cấp cao, các cân nhắc, cách thực hành tốt nhất và mẫu mã để hỗ trợ xây dựng giải pháp của bạn.

Để biết các tiêu chuẩn và phương pháp hay nhất về webhooks, hãy truy cập tài nguyên cộng đồng nguồn mở Webhooks.fyi và CloudEvents.io.

Để biết thêm tài nguyên học tập không có máy chủ, hãy truy cập Serverless Land.

TAGS: đã đóng góp, không có máy chủ