Bởi James Beswick | 30 OCT 2023 | Amazon API Gateway, Amazon DynamoDB, Amazon EventBridge, Amazon Simple Storage Service (S3), AWS Lambda, AWS Step Functions, Serverless

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

Thường được gọi là API đảo ngược (reverse APIs) hoặc API đẩy (push APIs), 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 các sự kiện cho 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, hoặc thông báo giao dịch từ nhà cung cấp, webhooks đóng một vai trò quan trọng trong việc mở ra 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 (Webhooks Provider): Ứng dụng SaaS gửi webhooks tới API bên ngoài
• Người sử dụng Webhooks (Webhooks Consumer): API nhận webhooks với khả năng xử lý tải trọng (payload) lớn

Nó cung cấp các kiến trúc tham chiếu tổng quan đi kèm với các lưu ý, các biện pháp thực hành tốt nhất và ví dụ mã nguồn để hướng dẫn bạn triển khai.

Gửi webhook

Để gửi webhooks, bạn tạo ra các sự kiện, và phân phối chúng tới API 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ụ, một 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 sử dụng) vận chuyển hàng hóa sau khi được 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 2 dịch vụ:

• Phân phối webhook: Ứng dụng cung cấp webhook đến điểm cuối (endpoints) 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 việc chỉ định điểm cuối để phân phối, và những sự kiện nào để đăng ký.

Những điều cân nhắc và biện pháp thực hành tốt nhất để gửi webhooks

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 DynamoDB Streams và gửi tới Amazon EventBridge Pipes. Sau đó, bạn có thể đơn giản hóa định dạng phản hồi của DynamoDB bằng cách sử dụng một bộ chuyển đổi đầu vào.

Với EventBridge, bạn gửi các sự kiện gần với 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 xác định bằng cách sử dụng EventBridge Scheduler. Để tạo sự kiện từ các nguồn dữ liệu khác, xem xét các cách tiếp cận tương tự với Amazon Simple Storage Service (S3) Event Notifications hoặc Amazon Kinesis.

Lọc: EventBridge Pipes hỗ trợ lọc bằng cách so khớp với các mẫu sự kiện, trước khi sự kiện được định tuyến đến mục tiêu đích. 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 cách gọi REST API. Để 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 có thể thiết lập một giới hạn tỷ lệ gọi. Ngoài ra, các lần thử lại với 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 payload: Xem xét cách người tiêu dùng xử lý các payload của sự kiện. Ví dụ này sử dụng bộ chuyển đổi đầu vào để tạo một payload có cấu trúc, phù hợp với đặc tả của CloudEvents. CloudEvents cung cấp định dạng tiêu chuẩn ngành và cấu trúc payload 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 payload: Để phân phối nhanh chóng và đáng tin cậy, hãy giữ kích thước payload ở 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ư định danh 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 một kết nối bằng phương thức ủy quyền như OAuth. Bên trong hệ thống, 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 các 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.

Monetization Kiếm tiền: Cân nhắc tính phí cho người tiêu dùng dựa trên lưu lượng hoặc cấp độ sử dụng của họ. Ví dụ: bạn có thể cung cấp một gói 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 lưu lượng nhất định. Để có thêm lưu 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 lưu lượng lớn, bạn cung cấp một gói 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 họ. Ví dụ, Amazon Simple Notification Service (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 payload và xác thực, cũng như AWS Step Functions để điều phối mẫu circuit breaker nhằm hủy kích hoạt những người đăng ký không đáng tin cậy.

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 trường hợp sử dụng nâng cao có thể xử lý các payload lớn bằng cách sử dụng mẫu claim-check.

Ở 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 payload: S3 cung cấp dung lượng lưu trữ có thể mở rộng cho các payload lớn.
• Xử lý Webhook: EventBridge Pipes cung cấp một kiến trúc mở rộng cho việc xử lý sự kiện. Nó có khả năng gộp nhóm (batch), lọc (filter), bổ sung dữ liệu (enrich) và gửi sự kiện đến nhiều dịch vụ xử lý khác nhau làm đích đến.

Những điều cân nhắc và biện pháp thực hành tốt nhất để gửi webhooks

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, việc cấu hình giới hạn tỷ lệ và giới hạn bùng nổ phù hợp là rất quan trọng. Kiểm soát lưu lượng truy cập (Throttling) các yêu cầu ngay tại điểm vào sẽ giảm thiểu tác động đến các dịch vụ phía dưới, bởi mỗi dịch vụ này đều có cá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 phía dưới. Do đó, các dịch vụ này chỉ gửi sự kiện ở một giới hạn tỷ lệ ngưỡng, thường là tối đa 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 lỗi, và bảo vệ chống lại tấn công 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 Layer 7 và Layer 3, là những mối đe dọa phổ biến đối với người tiêu dùng webhook do chúng thường xuyên bị lộ ra ngoài.

Ủ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 Hash-based Message Authentication Code (HMAC), trong đó một bí mật dùng chung được thiết lập và lưu trữ trong Secrets Manager. 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 payload: Nhà cung cấp có thể gửi nhiều kích cỡ payload 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 payload 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ó thể mở rộng cho các tin nhắn lớn) điều này có thể trở thành điểm nghẽn.

Thay vì xử lý toàn bộ payload, S3 lưu trữ payload đó. Sau đó, nó được tham chiếu trong DynamoDB thông qua tên bucket và khóa đối tượng của nó. Điều này được gọi là mẫu claim-check. Với cách tiếp cận này, kiến trúc hỗ trợ  các payload lên tới 6 Mb, theo hạn mức tải của 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ự. Để thể hiện thứ tự, các sự kiện có thể bao gồm dấu thời gian (timestamp) hoặc mã định danh chuỗi (sequence identifier) trong nội dung dữ liệu (payload). Nếu không, việc sắp xếp thứ tự các sự kiện sẽ phụ thuộc [nhiều nhất] vào thời điểm nhận được webhook. Để đảm bảo thứ tự xử lý đáng tin cậy, hãy lựa chọn các dịch vụ theo sự kiện (event-driven services) có khả năng đảm bảo tính sắp xếp thứ tự. Ví dụ này sử dụng DynamoDB Streams và EventBridge Pipes.

Xử lý linh hoạt: EventBridge Pipes cung cấp khả năng tích hợp với nhiều dịch vụ theo sự kiện (event-driven services) khác nhau làm đích đến (targets). 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 (buffer) 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 payload cần thiết và bổ sung thông tin nếu cần.

Chi phí: Ví dụ này xem xét trường hợp sử dụng có thể xử lý payload lớn. Tuy nhiên, nếu bạn có thể đảm bảo rằng nhà cung cấp gửi payload tối thiểu, hãy xem xét kiến trúc đơn giản hơn mà không có mẫu claim-check để 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ề webhook, 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 về serverless, truy cập Serverless Land.

TAGS: contributed, serverless