bởi Talia Nassi | ngày 09 tháng 5 2022 | in Amazon EventBridge, Events, Serverless | Permalink |  Share

Hai phương pháp phổ biến khi xây dựng ứng dụng là kiến ​​trúc request-response và kiến ​​trúc event-driven. Trong kiến​​ 2trúc request-response, các thành phần của ứng dụng giao tiếp thông qua lệnh gọi API. Máy khách gửi yêu cầu và mong đợi phản hồi trước khi thực hiện công việc tiếp theo. Trong kiến ​​trúc event-driven, máy khách tạo ra một sự kiện và có thể ngay lập tức chuyển sang công việc tiếp theo. Các phần khác nhau của ứng dụng saukhi đó sẽ phản hồi sự kiện nếu cần.

Trong bài viết này, bạn sẽ tìm hiểu về những lí do cần xem xét chuyển từ kiến trúc request-response sang kiến trúc event-driven.

Những thách thức của kiến trúc request-response:

Khi bắt đầu xây dựng một ứng dụng mới, nhiều nhà phát triển thường mặc định sử dụng kiến trúc request-response. Một kiến trúc request-response có thể tích hợp chặt chẽ các thành phần và các thành phần này giao tiếp thông qua các cuộc gọi đồng bộ. Mặc dù phương pháp request-response thường dễ triển khai ban đầu hơn bắt đầu hơn, nhưng nó có thể trở nên khó khăn khi ứng dụng của bạn phát triển ngày càng phức tạp.

Trong bài viết này, tôi sẽ xem xét một ví dụ về ứng dụng thương mại điện tử sử dụng kiến trúc request-response và chỉ ra những thách thức của việc tích hợp chặt chẽ giữa các thành phần. Sau đó, tôi sẽ chỉ cho bạn cách xây dựng cùng một ứng dụng với kiến trúc event-driven, nó có thể mang lại khả năng mở rộng, khả năng chống lỗi và tăng tốc độ phát triển cho ứng dụng của bạn. cho bạn thấy việc xây dựng cùng một ứng dụng với kiến trúc event-driven có thể mang lại khả năng mở rộng, khả năng chống lỗi và tốc độ phát triển như thế nào.

Sự phối hợp chặt chẽ giữa các microservice

Trong một ứng dụng thương mại điện tử điển hình sử dụng một API đồng bộ, khách hàng gửi một yêu cầu để đặt hàng và dịch vụ đặt hàng gửi yêu cầu xuống dịch vụ hóa đơn. Nếu thành công, dịch vụ đặt hàng sẽ phản hồi với một tin nhắn thành công hoặc số xác nhận.

Ở giai đoạn ban đầu này, đây là một kết nối đơn giản giữa hai dịch vụ. Thách thức đến khi bạn thêm nhiều dịch vụ khác tích hợp với dịch vụ đặt hàng.

Nếu bạn thêm một dịch vụ thực hiện đơn hàng và một dịch vụ dự báo thì dịch vụ đặt hàng sẽ có nhiều trách nhiệm và phức tạp hơn. Dịch vụ đặt hàng phải biết cách gọi API của từng dịch vụ, từ cấu trúc cuộc gọi API đến cách xử lý lại của API. Nếu có bất kỳ thay đổi không tương thích ngược trở lại trong các API, nhóm dịch vụ đặt hàng phải cập nhật chúng. Hệ thống chuyển tiếp các đợt tăng cường lưu lượng nặng về phụ thuộc của dịch vụ đặt hàng, có thể không có khả năng mở rộng như vậy. Ngoài ra, các dịch vụ phụ thuộc có thể truyền các lỗi trở lại ngăn xếp cho khách hàng.

Xử lý lỗi và thử lại

Bây giờ, bạn thêm các dịch vụ mới ở hạ nguồn phía dưới để thực hiện và vận chuyển đơn hàng từ ứng dụng thương mại điện tử.

Trường hợp tốt nhất, mọi thứ đều hoạt động như mong đợi: Dịch vụ đặt hàng kích hoạt tính năng lập hóa đơn, hệ thống thanh toán và dự báo cập nhật. Sau khi thanh toán hoàn tất, thao tác này sẽ kích hoạt quá trình thực hiện và đóng gói đơn hàng, sau đó thông báo cho dịch vụ vận chuyển để yêu cầu thông tin theo dõi.

Tuy nhiên, nếu trung tâm xử lý đơn hàng không thể tìm thấy sản phẩm vì hết hàng thì bộ phận xử lý đơn hàng có thể phải thông báo cho dịch vụ hóa đơn, sau đó hủy thanh toán hoặc hoàn lại tiền. Nếu quá trình thực hiện không thành công thì hệ thống kích hoạt vận chuyển cũng có thể không thành công. Dự báo cũng phải được cập nhật để phản ánh sự thay đổi. Quy trình khắc phục này hoàn toàn chỉ nhằm giải quyết một trong nhiều “đường dẫn unhappy” tiềm ẩn có thể xảy ra trong ứng dụng thương mại điện tử dựa trên API này.

Phối hợp chặt chẽ giữa các nhóm phát triển

Trong một ứng dụng được tích hợp đồng bộ, các nhóm phải phối hợp mọi dịch vụ mới được thêm vào ứng dụng. Điều này có thể làm chậm khả năng phát hành tính năng mới của mỗi nhóm phát triển. Hãy tưởng tượng nhóm của bạn làm việc trên dịch vụ thanh toán nhưng bạn không được thông báo rằng nhóm khác đã thêm dịch vụ phần thưởng mớidịch vụ mới là phần thưởng. Điều gì sẽ xảy ra khi dịch vụ xử lý đơn hàng xảy ra lỗi?

Dịch vụ điều hành Dịch vụ đáp ứng nhu cầu có thể điều phốitổ chức tất cả các dịch vụ khác. Nhóm thanh toán của bạn nhận được một thông báo và bạn hoàn tác thanh toán nhưng bạn có thể không biết ai xử lý các lần thử lại và logic lỗi. Nếu dịch vụ phần thưởng thay đổi nhà cung cấp và có API mới nhưng không thông báo cho nhóm của bạn, thì bạn có thể không biết về dịch vụ mới.

Cuối cùng, có thể khó để phối hợp các quy trình và luồng công việc này khi hệ thống trở nên phức tạp hơn và việc phải quản lý thêm nhiều dịch vụ hơn. Đây là một lý do khiến việc chuyển sang kiến ​​trúc hướng sự kiện có thể có lợi.

Lợi ích của kiến ​​trúc event-drivenhướng sự kiện

Kiến trúc event-driven có thể giúp giải quyết các vấn đề liên quan đến việc phối hợp chặt chẽ giữa các microservice, xử lý lỗi và thử lại cũng như việc phối hợp giữa các nhóm phát triển.

Sự phối hợp chặt chẽ giữa các microservices

Trong kiến ​​trúc event-driven, publisher phát ra một sự kiện được event bus xác nhận. Event bus định tuyến các sự kiện đến subscribers, nó sẽ xử lý các sự kiện bằng logic nghiệp vụ self-contained và sẽ không có thông tin liên lạc trực tiếp giữa publisher và subscribers.

Các ứng dụng đượckhi tách rời cho phép các nhóm hoạt động độc lập hơn, điều này có thể tăng tốc độ cho chúng. Ví dụ: với tính năng tích hợp dựa trên API, nếu nhóm của bạn muốn biết về thay đổi đã xảy ra trong microservice của nhóm khác, bạn có thể phải yêu cầu nhóm đó thực hiện lệnh gọi API tới dịch vụ của bạn. Do đó, bạn có thể phải xem xét việc xác thực, phối hợp với nhóm khác về cấu trúc của lệnh gọi API. Do đó, các nhóm phải trao đổi với nhau khiến họ làm chậm thời gian phát triển. Với ứng dụng theo event-driven, bạn có thể đăng ký các sự kiện được gửi từ microservice của mình và event bus (ví dụ: Amazon EventBridge) sẽ đảm nhiệm việc định tuyến sự kiện và xử lý việc xác thực.

Xử lý lỗi và thử lại

Một lý do khác để chuyển sang kiến ​​trúc event-driven là để xử lý lưu lượng truy cập không thể đoán trước. Các trang web thương mại điện tử như Amazon.com có ​​lượng truy cập thay đổi tùy theo ngày. Một khi bạn đặt hàng thì một số sự việc sẽ xảy ra.

Đầu tiên, Amazon kiểm tra thẻ tín dụng của bạn để đảm bảo rằng còn tiền. Sau đó, Amazon phải đóng gói hàng hóa và chất lên xe tải. Tất cả điều đó xảy ra tại một trung tâm xử lý đơn hàng của Amazon. Không có lệnh gọi API đồng bộ nào dành cho hệ thống backend của Amazon để đóng gói và vận chuyển sản phẩm. Sau khi hệ thống xác nhận khoản thanh toán của bạn, giao diện người dùng sẽ tạo một số thông tin mô tả sự kiện và đưa số tài khoản, thông tin thẻ tín dụng của bạn cũng như những gì bạn đã mua vào một sự kiện đã được đóng gói và đưa nó vào đám mây và vào một hàng đợi. Sau đó, một phần mềm khác sẽ loại bỏ sự kiện khỏi hàng đợi và bắt đầu quá trình đóng gói và vận chuyển.

Điểm mấu chốt là tất cả các quy trình này có thể chạy ở các tốc độ khác nhau. Thông thường, tốc độ mà khách hàng đặt hàng và tốc độ các nhà kho có thể đóng gói các thùng hàng gần như tương đương nhau. Tuy nhiên, vào những ngày bận rộn như Prime Day, thì khách hàng đặt hàng nhanh hơn nhiều so với khả năng hoạt động của kho.

Các ứng dụng thương mại điện tử, như Amazon.com, phải có khả năng mở rộng quy mô để xử lý lưu lượng truy cập không thể đoán trước. Khi khách hàng đặt hàng, event bus như Amazon EventBridge sẽ nhận được sự kiện và tất cả các microservice bên dưới đều có thể chọn sự kiện đặt hàng để xử lý. Vì mỗi microservice có thể bị lỗi một cách độc lập nên không có điểm lỗi duy nhất.

Sự phối hợp lỏng lẻo giữa các nhóm phát triển

Kiến trúc event-driven thúc đẩy tính độc lập của nhóm phát triển do sự liên kết lỏng lẻo giữa publishernhà xuất bản và subscriberngười đăng ký. Ứng dụng có thể đăng ký các sự kiện có yêu cầu định tuyến và logic nghiệp vụ tách biệt với nhà xuất bản và những người đăng ký khác. Điều này cho phép nhà xuất bản và người đăng ký thay đổi độc lập với nhau, mang lại sự linh hoạt hơn cho kiến ​​trúc tổng thể.

Các ứng dụng tách rời cũng cho phép bạn xây dựng các tính năng mới nhanh hơn. Việc thêm các tính năng mới hoặc mở rộng các tính năng hiện có có thể đơn giản hơn với kiến ​​trúc hướng sự kiện vì bạn có thể thêm các sự kiện mới hoặc sửa đổi các sự kiện hiện có. Quá trình này loại bỏ sự phức tạp trong ứng dụng của bạn.

Phần kết luận

Trong bài đăng này, bạn tìm hiểu về những thách thức trong việc phát triển ứng dụng với kiến ​​trúc request-responseđáp ứng yêu cầu. Trong kiến ​​trúc request-response, máy khách phải gửi yêu cầu và chờ phản hồi trước khi chuyển sang nhiệm vụ tiếp theo. Khi các ứng dụng ngày càng phức tạp, kiến ​​trúc liên kết chặt chẽ này có thể gây ra sự cố. Kiến trúc event-driven có thể tăng khả năng mở rộng, khả năng chịu lỗi và tốc độ của nhà phát triển bằng cách tách các thành phần trong ứng dụng của bạn.

Để biết thêm về serverless, hãy truy cập serverlessland.com.