この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
Ngày 29/09/2020 vừa rồi đã diễn ra sự kiện AWS Summit Online ASEAN RE:CAP. Link sự kiện: https://live.awsevents.com/ASEANSummitreCap/
Chủ để của session lần này là "Các mẫu kiến trúc: Xử lý luồng không cần máy chủ ở quy mô" Diễn giả: Donnie Prakoso, Sr. Developer Advocate, ASEAN Amazon Web Services
Bạn đang thắc mắc làm thế nào để mở rộng và tăng độ chuẩn xác cho hệ thống với kiến trúc theo sự kiện? Trong phiên này, chúng tôi sẽ cung cấp tổng quan về kiến trúc sự kiện và những ưu điểm của nó có thể mang lại cho kinh doanh của bạn. Chương trình cũng bao gồm các kiến trúc mẫu và được demo minh hoạ kiến trúc sự kiện trên AWS.
1. Kiến trúc sự kiện trên AWS (Event-Driven Architecture)
Event-Driven Architecture là kiến trúc sử dụng các event để kích hoạt và giao tiếp giữa các dịch vụ tách rời và phổ biến trong các ưng dụng hiện đại được xây dựng theo hướng Microservices.
Sự kiện là một thay đổi về trạng thái, giống như 1 mặt hàng được đặt trong giỏ hàng trên trang web thương mại điện tử. Các sự kiện có thể có trạng thái như vật phẩm đã mua hoặc là 1 thông báo rằng một đơn đặt hàng đã được chuyển đi.
Event-Driven Architecture có 3 phần chính
- Event Producer: Sản xuất event tới Event Router
- Event Router: Chọn lọc và đẩy các sự kiện tới Event Consumer
- Event Consumer: Xử lý event
Minh hoạ cách chúng ta thực hiện các thành phần của Event-Driven Architecture
- Đây là 1 dịch vụ dựa trên API và được đồng bộ hoá, trong trường hợp này, khi khách hàng đưa ra yêu cầu đối với dịch vụ đặt hàng, nó sẽ được yêu cầu dịch vụ hoá đơn. Và một khi nhận được kết quả thành công, nó có thể phản hồi lại cho khách hàng bằng thông báo cùng với số xác nhận cho khách hàng.
- Với dịch vụ dựa trên API, khi được đồng bộ hoá, điều gì sẽ xảy ra khi chúng ta bắt đầu thêm một vài dịch vụ nữa? Với dịch vụ đặt hàng gọi đến các dịch vụ hoá đơn, dịch vụ thực hiện và dịch vụ dự báo như trong hình dưới. Nhưng vấn đề khi thiết kế API đồng bộ là dịch vụ đặt hàng cần biết thông tin từ các dịch vụ khác. Dịch vụ đặt hàng cần gọi tất cả các yêu cầu phía sau trước khi phản hồi lại cho người dùng. Nếu một trong những dịch vụ phía sau này trục trặc, hệ thống trả lại timeout cho người dùng.
Làm thế nào để giải quyết vấn đề này
Tuy nhiên về lâu dài thì sẽ có thêm các dịch vụ phía sau dịch vụ đặt hàng. Khi đó chúng ta cần một Event Router. Bằng cách sử dụng Event Router trong kiến trúc, chúng ta có thể chuyển dữ liệu giữa các hệ thống. Chúng ta có thể triển khai hệ thống, mở rộng quy mô một cách độc lập, fan-out sự kiện và không cần phải viết code cho từng Event Consumer.
2. Amazon EventBridge
- EventBridge loại bỏ friction của tích hợp poin-to-point bằng cách cho phép bạn truy cập dễ dàng các thay đổi trong dữ liệu trong AWS và ứng dụng SaaS
- Có được một mô hình lập trình đơn giản trong đó có các Event Producer được tách rời khỏi những Event Subscriber
- Đây là một hệ thống fully-managed, nó xử lý mọi thứ từ việc nhập và phân phối sự kiện, bảo mật, xử lý lỗi,...
Có 2 Event-Driven được sử dụng trong Event-Driven Architecture, đó là Event Bus và Event Topic.
- Với Event Bus ta sử dụng Amazon EventBridge. Là lựa chọn tốt khi bạn muốn xây dựng một ứng dụng tương tác với các sự kiện từ các ứng dụng SaaS, dịch vụ AWS hoặc các ứng dụng Custom
- Với Event Topic ta sử dụng Amazon SNS kết hợp với Amazon SQS. Là lựa chọn tốt khi bạn muốn xây dựng một ứng dụng tương tác với các sự kiện có thông lượng cao và low-latency
Chúng ta sẽ thay đổi kiến trúc khi sử dụng EventBridge như một Event Router để xử lý giao tiếp Asynchronous giữa các dịch vụ
- Bất cứ khi nào dịch vụ đặt hàng được nhận yêu cầu, nó sẽ tạo ra một sự kiện được gọi là đơn đặt hàng cho EventBridge
- EventBridge sau đó sẽ đẩy sự kiện tới các dịch vụ tương ứng.
- Hơn nữa, một vài dịch vụ sẽ publish sự kiện của riêng họ và vì vậy, EventBridge cũng sẽ xử lý và đẩy các sự kiện đó tương ứng.
Hãy nhìn vào cách thức hoạt động của EventBridge
- Tất cả bắt đầu với 1 Event Source: AWS Services, Custom events, SaaS apps
- Cốt lõi của EventBridge là Event Bus. Bạn có thể cài đặt các quy tắc trên đó. Các quy tắc cho phép bạn match các giá trị và xác định các sự kiện nào sẽ được chuyển đến đâu.
3. Kiến trúc các loại sự kiện
Chúng tôi muốn giới thiệu tới các bạn Schema Registry and Discovery đang ở chế độ Preview
Schema Registry của Amazon EventBridge lưu cấu trúc của sự kiện hoặc là schema ở một vị trí trung tâm, và liên kết các schema đó thành code cho Java, Python, ... để giúp bạn dễ dàng sử dụng các sự kiện như các Object trong code của mình.
4. Điều phối quy trình nghiệp vụ (business workflow)
Khách hàng sử dụng AWS Step Functions để tự động hoá workflow một cách linh hoạt cho các ứng dụng của họ.
Step Functions tích hợp với AWS Lambda giúp dễ dàng thêm các Lambda Task vào workflow.
5. Demo
Trong Demo này chúng ta sẽ sử dụng Amazon EventBridge để nhận event từ ứng dụng SaaS bằng cách sử dụng tích hợp đối tác và webhook. Bản Demo này là cách xử lý thanh toán và hỗ trợ yêu cầu
Freshworks là một nền tảng tương tác với khách hàng. Stripe là ứng dụng xử lý thanh toán trực tuyến. Freshworks tích hợp với EventBridge để route sự kiện mà không cần webhook (Bạn cũng có thể sử dụng Webhook như với Stripe chẳng hạn)
- Khi có một thanh toán từ Stripe, dịch vụ event consumer là dịch vụ thanh toán
- Sau khi hoàn thành dịch vụ thanh toán sẽ xuất bản sự kiện có tên là thanh toán đã được xử lý cho Event Bridge
- EventBridge sẽ route sự kiện này đến AWS Step Functions để xử lý dữ liệu và tải lên S3
- Sau đó được hiển thị trên Amazon QuickSight dưới dạng bảng
- Mặt khác khi có một yêu cầu hỗ trợ mới được tạo trong freshwork, nó sẽ tự động kích hoạt EventBridge qua tích hợp đối tác.
- Sự kiện được route tới dịch vụ hỗ trợ sử dụng Amazon Comprehend để phân tích
- Sau đó dịch vụ hỗ trợ sẽ xuất bản 1 sự kiện khác và tiếp tục được EventBridge route tới Step Functions rồi S3 và QuickSight
Session kết thúc tại đây. Nếu bạn thấy thú vị và muốn tìm hiểu thêm.. Hay truy cập đường link của sự kiện và tìm video của session "Kiến trúc giải pháp theo sự kiện trên AWS"
Cảm ơn các bạn đã theo dõi blog. Xin chào và hẹn gặp lại!