Kiến trúc định hướng theo sự kiện (EDA) là gì?
Kiến trúc định hướng theo sự kiện (EDA) là một mẫu kiến trúc hiện đại được xây dựng từ nhiều dịch vụ nhỏ, tách biệt với khả năng công bố, sử dụng hoặc định tuyến các sự kiện.
Một sự kiện đại diện cho một sự thay đổi về trạng thái hoặc một cập nhật. Ví dụ: một mặt hàng được thêm vào giỏ hàng, một tệp được tải lên hệ thống lưu trữ hoặc một đơn đặt hàng đã sẵn sàng để giao. Sự kiện có thể mang trạng thái (chẳng hạn như tên mặt hàng, giá cả hoặc số lượng trong một đơn đặt hàng) hoặc chỉ chứa mã định danh (ví dụ: “đơn hàng số 8942 đã được giao”) cần cho việc tra cứu thông tin liên quan.
Không giống như những mô hình định hướng theo yêu cầu truyền thống, EDA thúc đẩy tính liên kết ít phụ thuộc giữa dịch vụ dành cho nhà sản xuất và dịch vụ dành cho người tiêu dùng. Điều này giúp đơn giản hóa việc điều chỉnh quy mô, cập nhật và triển khai độc lập các thành phần riêng biệt của hệ thống.
Tại sao một kiến trúc tách biệt lại quan trọng?
Nhiều tổ chức nhận thấy rằng các ứng dụng, cơ sở dữ liệu và công nghệ đơn khối tác động tiêu cực đến sự đổi mới và cải thiện trải nghiệm người dùng. Các ứng dụng và cơ sở dữ liệu cũ hạn chế các tùy chọn giúp bạn áp dụng các khuôn khổ công nghệ hiện đại và hạn chế khả năng cạnh tranh và đổi mới của bạn. Tuy nhiên, khi bạn hiện đại hóa các ứng dụng và kho dữ liệu của chúng, chúng sẽ trở nên dễ điều chỉnh quy mô và phát triển nhanh hơn.
Chiến lược tách biệt dữ liệu cải thiện khả năng chịu lỗi và khả năng phục hồi, giúp rút ngắn thời gian đưa ra thị trường (TTM) đối với các tính năng mới trên ứng dụng của bạn.
Để biết thêm thông tin về những ưu điểm của việc hiện đại hóa các ứng dụng đơn khối, hãy xem Kích hoạt tính lưu trữ lâu dài của dữ liệu trong các vi dịch vụ trong Hướng dẫn quy định của AWS.
Lợi ích từ xây dựng kiến trúc định hướng theo sự kiện (EDA) là gì?
Kiến trúc định hướng theo sự kiện (EDA) thúc đẩy liên kết ít phụ thuộc giữa các thành phần của hệ thống, dẫn đến sự linh hoạt cao hơn. Các vi dịch vụ có thể điều chỉnh quy mô một cách độc lập, gặp lỗi nhưng không ảnh hưởng đến các dịch vụ khác và giảm độ phức tạp của quy trình làm việc. Các sự kiện có thể được định tuyến, lưu vào bộ đệm và ghi nhật ký một cách linh hoạt cho các mục đích kiểm tra. Các luồng sự kiện theo mô hình đẩy có thể hoạt động trong thời gian thực, cắt giảm chi phí liên quan đến việc tạo và vận hành mã để liên tục kiểm tra vòng các thay đổi từ các hệ thống.
Điều chỉnh quy mô và gặp lỗi một cách độc lập
Bằng cách tách riêng các dịch vụ, các thành phần trong kiến trúc định hướng theo sự kiện có thể điều chỉnh quy mô và gặp lỗi một cách độc lập, làm tăng khả năng phục hồi của ứng dụng. Điều này ngày càng trở nên quan trọng khi số lượng tích hợp giữa các dịch vụ ngày càng tăng. Nếu một dịch vụ gặp lỗi, các dịch vụ còn lại vẫn có thể tiếp tục chạy.
Kiến trúc định hướng theo sự kiện cũng có thể giúp thiết kế hệ thống gần như theo thời gian thực dễ dàng hơn, giúp các tổ chức thoát khỏi quá trình xử lý theo hàng loạt. Sự kiện được tạo khi trạng thái ứng dụng thay đổi. Khi các sự kiện tăng quy mô, lớp xử lý các sự kiện cũng tăng theo.
Các sự kiện thường được công bố đến các dịch vụ thông báo hoạt động giống như một bộ đệm linh hoạt giữa các vi dịch vụ và giúp xử lý việc điều chỉnh quy mô. Sự kiện cũng có thể được gửi đến một dịch vụ bộ định tuyến có thể lọc và định tuyến các thông báo dựa trên nội dung của sự kiện. Do đó, các ứng dụng dựa trên sự kiện có quy mô linh hoạt hơn và khả năng dự phòng lớn hơn các ứng dụng đơn khối.
Phát triển nhanh chóng
Với kiến trúc định hướng theo sự kiện và bộ định tuyến sự kiện, các lập trình viên không còn cần phải viết mã tùy chỉnh để kiểm tra vòng, lọc và định tuyến các sự kiện. Bộ định tuyến sự kiện tự động lọc và đẩy các sự kiện đến đối tượng dùng. Bộ định tuyến cũng loại bỏ nhu cầu phối hợp chặt chẽ giữa các dịch vụ của đối tượng tạo và đối tượng dùng, giúp tăng tính linh hoạt của lập trình viên.
Kiến trúc định hướng theo sự kiện được dựa trên mô hình đẩy, có nghĩa là mọi thứ xảy ra theo yêu cầu khi các sự kiện được gửi đến bộ định tuyến và hệ thống hạ nguồn mà không cần thông báo cho các dịch vụ phụ thuộc. Do đó, cơ sở hạ tầng và tài nguyên có thể tăng và giảm quy mô theo khối lượng sự kiện, giúp giảm chi phí xử lý khối lượng công việc và vận hành các ứng dụng đã triển khai.
Xây dựng hệ thống có thể mở rộng
Kiến trúc định hướng theo sự kiện cũng có khả năng mở rộng cao. Các đội ngũ khác có thể mở rộng các tính năng và thêm chức năng mà không ảnh hưởng đến các vi dịch vụ hiện có. Bằng cách công bố các sự kiện, một ứng dụng có thể tích hợp với các hệ thống hiện có, cũng như các ứng dụng trong tương lai có thể tích hợp dễ dàng với tư cách là đối tượng dùng sự kiện mà không cần thay đổi giải pháp hiện có.
Các đối tượng tạo sự kiện không biết về đối tượng dùng sự kiện, vì vậy việc mở rộng hệ thống sẽ ít gây cản trở hơn, đồng thời các tính năng hoặc tích hợp mới cũng không thêm vào các thành phần phụ thuộc làm chậm quá trình phát triển trong tương lai.
Giảm độ phức tạp
Các vi dịch vụ cho phép các lập trình viên và kiến trúc sư phân tách các quy trình làm việc phức tạp. Ví dụ: họ có thể chia nhỏ đơn khối thương mại điện tử thành chấp nhận đơn đặt hàng và xử lý thanh toán với các dịch vụ kiểm kê, thực hiện và kế toán riêng biệt.
Việc quản lý và điều phối một khối lượng công việc trong một đơn khối vốn phức tạp nay sẽ trở thành một loạt các dịch vụ đơn giản, tách biệt được quản lý độc lập và giao tiếp không đồng bộ thông qua các thông báo sự kiện.
Phương pháp tiếp cận định hướng theo sự kiện giúp bạn có thể tập hợp và điều phối các dịch vụ xử lý dữ liệu ở các tốc độ khác nhau. Trong ví dụ sau, một vi dịch vụ chấp nhận đơn đặt hàng sẽ tương tác với hệ thống xử lý thanh toán thông qua hàng đợi.
Trong ví dụ, dịch vụ chấp nhận đơn đặt hàng có thể lưu trữ khối lượng lớn các đơn đặt hàng đến bằng cách đệm các thông báo trong một hàng đợi.
Dịch vụ xử lý thanh toán, thường chậm hơn do sự phức tạp của việc xử lý các khoản thanh toán, có thể chiếm một luồng thông báo ổn định từ hàng đợi. Dịch vụ thanh toán chuyển đổi giữa các trạng thái hệ thống khác nhau là do logic thử lại và xử lý lỗi. Dịch vụ quy trình làm việc điều phối và quản lý các bước thanh toán dựa trên trạng thái hệ thống và sau cùng tạo ra nhiều sự kiện đáng quan tâm hơn cho các dịch vụ Kiểm kê, Thực hiện và Kế toán.
Kiểm tra dễ dàng
Bộ định tuyến sự kiện trong kiến trúc định hướng theo sự kiện hoạt động như một vị trí tập trung để kiểm tra ứng dụng của bạn và xác định các chính sách. Các chính sách này có thể hạn chế những người có thể công khai và đăng ký bộ định tuyến cũng như kiểm soát người dùng và tài nguyên nào có quyền truy cập vào dữ liệu của bạn. Bạn cũng có thể mã hóa các sự kiện của mình cả khi đang chuyển tiếp và ở trạng thái nghỉ.
Cắt giảm chi phí
EDA dựa trên mô hình đẩy, vì vậy mọi thứ đều diễn ra theo yêu cầu khi sự kiện xuất hiện trong bộ định tuyến. Bằng cách này, bạn sẽ không phải trả tiền cho việc kiểm tra vòng liên tục để kiểm tra một sự kiện. Điều này có nghĩa là tiêu thụ ít băng thông mạng hơn, sử dụng ít CPU hơn, ít dung lượng nhóm nhàn rỗi hơn và ít giao tiếp lần đầu qua SSL/TLS hơn.
Kiến trúc định hướng theo sự kiện (EDA) hoạt động như thế nào?
Dưới đây là ví dụ về kiến trúc định hướng theo sự kiện (EDA) dành cho một trang web thương mại điện tử:
%20for%20an%20ecommerce%20site.88b2240905b1b6addd672871b98bcb17bd44d701.jpg)
Trang web ví dụ này hiển thị ba thành phần chính của Đối tượng tạo sự kiện và các sự kiện được tạo ra. Trong trường hợp này, một Bộ định tuyến sự kiện tải nhập và lọc các sự kiện, sau đó nó sẽ gửi một hoặc nhiều sự kiện đến Đối tượng dùng sự kiện.
Kiến trúc định hướng theo sự kiện cho phép trang web phản ứng với các thay đổi từ nhiều nguồn khác nhau trong thời gian cao điểm về nhu cầu, mà không làm ứng dụng bị lỗi hoặc cung cấp tài nguyên quá mức.
Những loại khối lượng công việc nào phù hợp với kiến trúc định hướng theo sự kiện (EDA)?
Kiến trúc định hướng theo sự kiện (EDA) có thể cung cấp một phương pháp hiệu quả để đáp ứng nhu cầu của khối lượng công việc có quy mô cực kỳ linh hoạt và tính sẵn sàng cao. EDA cũng phù hợp với các khối lượng công việc có các mẫu lưu lượng truy cập không thể đoán trước hoặc "tăng đột ngột rồi giảm xuống ngay".
Làm thế nào kiến trúc định hướng theo sự kiện (EDA) cải thiện các ứng dụng?
Kiến trúc định hướng theo sự kiện (EDA) tăng cường liên kết ít phụ thuộc giữa các thành phần, khiến nó trở thành một cách tiếp cận tốt để xây dựng các ứng dụng phân tán, hiện đại.
Đối tượng tạo sự kiện không nhận thức, không quan tâm và không chịu gánh nặng bởi bất kỳ hoạt động nào của đối tượng dùng hạ nguồn đối với các sự kiện mà họ tạo ra. Bản thân các sự kiện đại diện cho sự thay đổi trạng thái và có thể chứa hoặc không chứa dữ liệu. Các sự kiện không nhận thức được hậu quả của sự tồn tại của chúng. Đối tượng dùng lắng nghe và xử lý các sự kiện đáng quan tâm. Bạn có thể kết nối trực tuyến các đối tượng dùng mới để cung cấp chức năng mới mà không làm gián đoạn quy trình làm việc hiện có.
Các EDA thúc đẩy sự phân rã các hệ thống đơn khối thành các mô hình miền nhỏ hơn. Các lập trình viên có thể bắt kịp tiến độ với việc giảm tải nhận thức và trở nên năng suất nhanh hơn. Khi các chức năng quan trọng được tách riêng, sẽ có ít rủi ro hơn khi triển khai các bản cập nhật và tính năng mới.
Một số trường hợp sử dụng kiến trúc định hướng theo sự kiện (EDA) phổ biến là gì?
Giao tiếp vi dịch vụ dành cho backend web và di động
Các trang web bán lẻ hoặc truyền thông và giải trí thường phải tăng quy mô để xử lý lưu lượng truy cập không thể đoán trước. Khách hàng truy cập trang web thương mại điện tử và đặt hàng. Sự kiện đơn hàng được gửi đến một bộ định tuyến sự kiện. Tất cả các vi dịch vụ hạ nguồn có thể nhận sự kiện đặt hàng để xử lý. Ví dụ về các hành động có thể được tiến hành: gửi đơn đặt hàng, ủy quyền thanh toán và gửi chi tiết đơn đặt hàng cho bên cung cấp dịch vụ vận chuyển.
Bởi vì mỗi vi dịch vụ có thể điều chỉnh quy mô và gặp lỗi một cách độc lập, quy trình có thể tăng quy mô trong thời gian đặt hàng cao điểm mà không gặp phải điểm lỗi chí mạng đơn lẻ.
Tự động hóa quy trình làm việc kinh doanh
Nhiều quy trình làm việc kinh doanh, chẳng hạn như các giao dịch dịch vụ tài chính, yêu cầu lặp lại các bước giống nhau. Bạn có thể khởi tạo và tự động hóa các bước đó bằng kiến trúc định hướng theo sự kiện (EDA).
Ví dụ: khi khách hàng đăng ký tài khoản mới với ngân hàng, ngân hàng phải tiến hành kiểm tra một số dữ liệu (giấy tờ tùy thân, địa chỉ, v.v.). Một số tài khoản cũng sẽ yêu cầu giai đoạn phê duyệt của con người. Bạn có thể điều phối tất cả các bước này thông qua một dịch vụ quy trình làm việc tự động chạy các bước khi nhận được các đơn đăng ký tài khoản mới.
Bạn cũng có thể thêm quy trình làm việc để xử lý dữ liệu ứng dụng của khách hàng một cách không đồng bộ với máy học để trích xuất dữ liệu có liên quan, có khả năng tiết kiệm hàng giờ công thu thập và xác thực dữ liệu thủ công.
Tích hợp ứng dụng SaaS
Một thách thức hàng đầu đối với môi trường phần mềm dưới dạng dịch vụ (SaaS) là thiếu khả năng hiển thị đối với hoạt động và dữ liệu của người dùng. Để mở khóa dữ liệu cô lập, các kiến trúc định hướng theo sự kiện có thể tải nhập các sự kiện ứng dụng SaaS hoặc gửi sự kiện đến các ứng dụng SaaS của chúng. Ví dụ: bạn có thể xây dựng phần mềm trung gian để tải nhập dữ liệu đơn đặt hàng gửi đến của đối tác và gửi đơn đặt hàng trực tiếp đến ứng dụng nội bộ xử lý đơn đặt hàng.
Tự động hóa cơ sở hạ tầng
Khi chạy khối lượng công việc nặng về điện toán (chẳng hạn như phân tích tài chính, nghiên cứu bộ gen hoặc chuyển mã nội dung phương tiện), bạn có thể yêu cầu các tài nguyên điện toán phản hồi bằng cách tăng quy mô để đạt khả năng xử lý song song cao và sau đó giảm quy mô sau khi hoàn tất tác vụ.
Ví dụ: trong các ngành được quản lý chặt chẽ, các công ty có EDA có thể thiết lập các nguồn lực về khả năng bảo mật để ứng phó với sự cố hoặc thực hiện hành động khắc phục bất cứ khi nào chính sách bảo mật gửi một sự kiện cảnh báo.
Khi nào bạn nên sử dụng kiến trúc định hướng theo sự kiện (EDA)?
Các kiến trúc định hướng theo sự kiện (EDA) lý tưởng nhất là dùng để cải thiện tính linh hoạt và di chuyển nhanh chóng. Chúng thường được tìm thấy trong các ứng dụng hiện đại sử dụng các vi dịch vụ hoặc bất kỳ ứng dụng nào có các thành phần tách biệt.
Tích hợp các hệ thống không đồng nhất
Nếu bạn có các hệ thống đang chạy trên các ngăn khác nhau, bạn có thể sử dụng EDA để chia sẻ thông tin giữa chúng mà không cần liên kết. Bộ định tuyến sự kiện thiết lập khả năng tham chiếu gián tiếp và khả năng tương tác giữa các hệ thống, vì vậy chúng có thể trao đổi thông báo và dữ liệu trong khi vẫn giữ tính không phụ thuộc.
Sao chép dữ liệu liên Khu vực, liên tài khoản
Bạn có thể sử dụng EDA để điều phối hệ thống giữa các nhóm hoạt động và triển khai trên các Khu vực AWS và tài khoản khác nhau. Bằng cách sử dụng bộ định tuyến sự kiện để truyền dữ liệu giữa các hệ thống, bạn có thể phát triển, điều chỉnh quy mô và triển khai dịch vụ độc lập với các nhóm khác.
Giám sát và cảnh báo trạng thái của tài nguyên
Thay vì liên tục kiểm tra tài nguyên của mình, bạn có thể sử dụng EDA để theo dõi và nhận cảnh báo về bất kỳ sự bất thường, thay đổi và cập nhật nào. Các tài nguyên này có thể bao gồm vùng lưu trữ, bảng cơ sở dữ liệu, các chức năng phi máy chủ, các nút điện toán, v.v.
Phát tán và xử lý song song
Nếu bạn có nhiều hệ thống phải cùng hoạt động để ứng phó với một sự kiện, bạn có thể sử dụng EDA để phát tán sự kiện mà không cần phải viết mã tùy chỉnh để đẩy đến từng đối tượng dùng. Bộ định tuyến đẩy sự kiện đến các hệ thống, trong đó mỗi hệ thống có thể xử lý sự kiện song song với một mục đích khác nhau.
Có những mẫu kiến trúc định hướng theo sự kiện (EDA) phổ biến nào?
Nhiều hàm ngắn
Tạo nhiều hàm ngắn thay vì hàm dài với số lượng ít hơn. Làm cho các hàm được chuyên môn hóa cao cho khối lượng công việc của bạn có nghĩa là làm cho chúng ngắn gọn và giảm thời gian xử lý. Mỗi hàm chỉ nên xử lý sự kiện được truyền vào hàm đó, không cần biết hoặc kỳ vọng về quy trình làm việc tổng thể hoặc khối lượng giao dịch. Điều này làm cho hàm không phụ thuộc vào nguồn của sự kiện và có liên kết tối thiểu với các dịch vụ khác.
Xử lý theo yêu cầu thay vì hàng loạt
Nhiều hệ thống truyền thống được thiết kế để chạy định kỳ và xử lý hàng loạt giao dịch tồn đọng theo thời gian. Ví dụ: một ứng dụng ngân hàng có thể chạy hàng giờ để xử lý các giao dịch ATM vào sổ cái trung tâm.
Đối với kiến trúc định hướng theo sự kiện (EDA), xử lý tùy chỉnh có thể phản hồi với mọi sự kiện. Điều này cho phép dịch vụ tăng quy mô của tính đồng thời khi cần thiết để xử lý các giao dịch trong gần như theo thời gian thực.
Khôi phục gián đoạn
Trong trường hợp bị gián đoạn, một dịch vụ có thể tự động được gọi để thử xử lý lại một sự kiện. Vì dịch vụ có thể nhận cùng một sự kiện nhiều lần, nên hãy thiết kế các hàm cho kết quả giống nhau. Điều này đảm bảo rằng kết quả không thay đổi sau lần đầu tiên dịch vụ nhận được sự kiện.
Ví dụ: nếu một đơn vị bán lẻ cố gắng quẹt thẻ tín dụng rồi thử lại lần nữa, dịch vụ chỉ xử lý thanh toán trong lần thử đầu tiên. Khi thử lại, dịch vụ sẽ xác minh trạng thái thanh toán và loại bỏ sự kiện.
Một số thách thức đối với kiến trúc định hướng theo sự kiện (EDA) là gì?
Khi áp dụng kiến trúc định hướng theo sự kiện (EDA), bạn có thể phải suy nghĩ lại về cách bạn nhìn nhận thiết kế ứng dụng của mình.
Độ trễ thay đổi
Không giống như các ứng dụng đơn khối có thể xử lý mọi thứ trong cùng một không gian bộ nhớ trên một thiết bị, các ứng dụng định hướng theo sự kiện giao tiếp qua các mạng. Thiết kế này mang đến độ trễ thay đổi. Mặc dù các ứng dụng đơn khối có thể có độ trễ thấp hơn hoặc ít thay đổi hơn, nhưng để đạt được điều này, thường phải đánh đổi bằng khả năng điều chỉnh quy mô và tính sẵn sàng.
Các dịch vụ AWS phi máy chủ có tính sẵn sàng cao, có nghĩa là chúng hoạt động ở nhiều Vùng sẵn sàng trong Khu vực AWS. Trong trường hợp bị gián đoạn dịch vụ, các dịch vụ sẽ tự động chuyển sang Vùng sẵn sàng thay thế và thử lại các giao dịch. Do đó, thay vì các giao dịch không thành công, chúng vẫn có thể được hoàn thành nhưng với độ trễ cao hơn.
Các khối lượng công việc yêu cầu hiệu năng ổn định với độ trễ thấp không phải là lựa chọn tốt cho kiến trúc EDA. Có hai ví dụ về vấn đề này, đó là ứng dụng giao dịch tần suất cao tại các ngân hàng và tự động hóa robot với tốc độ chưa đến một mili giây tại các kho hàng.
Độ nhất quán cuối
Một sự kiện đại diện cho một sự thay đổi về trạng thái. Với nhiều sự kiện chạy qua các dịch vụ khác nhau trong một kiến trúc tại bất kỳ thời điểm nhất định nào, các khối lượng công việc như vậy thường mang tính nhất quán cuối. Điều này làm cho việc xử lý các giao dịch, xử lý trùng lặp hoặc xác định trạng thái tổng thể chính xác của một hệ thống trở nên phức tạp hơn.
Một số khối lượng công việc không phù hợp với EDA do nhu cầu về đặc tính ACID. Tuy nhiên, nhiều khối lượng công việc vẫn có sự kết hợp các yêu cầu mang tính nhất quán cuối (ví dụ: tổng số đơn đặt hàng trong giờ hiện tại) hoặc tính nhất quán mạnh (ví dụ: hàng tồn kho hiện tại). Có các mẫu kiến trúc để hỗ trợ những tính năng cần tính nhất quán mạnh về dữ liệu. Ví dụ:
- DynamoDB có thể cung cấp giá trị đọc nhất quán cập nhật, đôi khi ở độ trễ cao hơn và nó cũng có thể hỗ trợ các giao dịch để giúp duy trì tính nhất quán của dữ liệu.
- Bạn có thể sử dụng cơ sở dữ liệu quan hệ cho các tính năng cần đặc tính ACID, mặc dù bất kỳ cơ sở dữ liệu quan hệ nào cũng có quy mô ít linh hoạt hơn một kho dữ liệu NoSQL.
Trả về giá trị cho đối tượng gọi
Trong nhiều trường hợp, các ứng dụng dựa trên sự kiện không mang tính đồng bộ. Điều này có nghĩa là các dịch vụ đối tượng gọi không đợi các yêu cầu từ các dịch vụ khác trước khi tiếp tục công việc khác. Đặc tính cơ bản này của EDA cho phép khả năng điều chỉnh quy mô và tính linh hoạt; tuy nhiên, nó làm cho việc chuyển các giá trị trả về hoặc kết quả quy trình làm việc trở nên phức tạp hơn so với các quy trình đồng bộ.
Trong nhiều trường hợp, việc trả về một giá trị ít quan trọng hơn việc đảm bảo sự thành công hay thất bại của quá trình xử lý sự kiện. Các tính năng đảm bảo việc xử lý các sự kiện có thể có tầm quan trọng hơn việc trả về giá trị cho đối tượng gọi.
Đối với khối lượng công việc tương tác, chẳng hạn như web và ứng dụng di động, người dùng cuối thường mong đợi nhận được giá trị trả về hoặc trạng thái hiện tại của giao dịch. Đối với những khối lượng công việc này, cómột số mẫu thiết kế có thể cung cấp sự kiện phong phú ngược lại cho đối tượng gọi. Tuy nhiên, những triển khai này trong kiến trúc định hướng theo sự kiện phức tạp hơn so với việc sử dụng giá trị trả về không đồng bộ theo cách truyền thống. Nền tảng này có thể giúp giảm thiểu sự phức tạp này.
Gỡ lỗi trên các dịch vụ và hàm
Gỡ lỗi các hệ thống định hướng theo sự kiện khác với gỡ lỗi một ứng dụng đơn khối. Như với tất cả các ứng dụng dựa trên vi dịch vụ và các hệ thống, dịch vụ truyền sự kiện khác nhau, để ghi lại và tái tạo trạng thái chính xác của nhiều dịch vụ khi xảy ra lỗi có thể là một thách thức. Bởi vì mỗi lệnh gọi dịch vụ và lệnh gọi hàm có các tệp bản ghi riêng biệt, nên để xác định điều gì đã xảy ra với một sự kiện cụ thể gây ra lỗi có thể sẽ phức tạp hơn.
Điều phối
Thông thường, các quy trình làm việc đơn giản sẽ trở nên phức tạp hơn theo thời gian. Trong một đơn khối điển hình, điều này có thể khiến các nhóm hàm và dịch vụ được kết hợp chặt chẽ hơn, đồng thời khiến việc định tuyến xử lý mã và các bất thường trở nên phức tạp.
Để theo dõi trạng thái của hệ thống, các quy trình làm việc liên quan đến logic thực hiện theo nhánh, các loại mô hình lỗi khác nhau và logic thử lại thường sử dụng một trình điều phối. Khi tạo một ứng dụng phi máy chủ định hướng theo sự kiện, điều quan trọng là phải xác định khi nào điều này xảy ra để bạn có thể di chuyển logic này sang máy trạng thái nhằm điều phối phù hợp.
Dịch vụ AWS nào sử dụng kiến trúc định hướng theo sự kiện (EDA)?
Các dịch vụ AWS thường tạo ra và tiêu thụ các sự kiện, khiến việc xây dựng giải pháp với kiến trúc định hướng theo sự kiện (EDA) trở nên dễ dàng.
Hơn nữa, các dịch vụ như Amazon EventBridge, Amazon SNS, Amazon SQS, and AWS Step Functions đều bao gồm các tính năng giúp khách hàng viết ít mã mẫu hơn và xây dựng các EDA nhanh hơn.
Amazon EventBridge
Bạn có thể sử dụng Amazon EventBridge để xây dựng bus sự kiện cho các ứng dụng định hướng theo sự kiện trên quy mô lớn sử dụng sự kiện từ các ứng dụng SaaS, các dịch vụ AWS khác hoặc các ứng dụng tùy chỉnh.
EventBridge áp dụng các quy tắc để định tuyến sự kiện từ các nguồn sự kiện đến các đích khác nhau. Các mục tiêu có thể bao gồm các dịch vụ AWS như AWS Lambda, Step Functions và Amazon Kinesis, hoặc bất kì điểm cuối HTTP nào thông qua các đích đến API EventBridge.
Một tích hợp phổ biến cho các trường hợp sử dụng EDA là Step Functions, trong đó các sự kiện kích hoạt quy trình làm việc cụ thể.
AWS Step Functions
AWS Step Functions bao gồmWorkflow Studio, một trình thiết kế quy trình làm việc trực quan mã thấp mà các bộ xây dựng có thể sử dụng để điều phối các dịch vụ AWS khác nhau. Bạn có thể sử dụng Workflow Studio để xây dựng ứng dụng phân tán, tự động hóa CNTT và quy trình kinh doanh, đồng thời sử dụng các dịch vụ AWS để xây dựng đường ống dữ liệu và máy học.
Amazon SNS
Chúng tôi đề xuất sử dụng Dịch vụ thông báo đơn giản của Amazon (Amazon SNS) để xây dựng các ứng dụng phản ứng với các sự kiện có thông lượng cao và độ trễ thấp được công bố bởi các ứng dụng, vi dịch vụ hoặc dịch vụ AWS khác. Bạn cũng có thể sử dụng Amazon SNS cho các ứng dụng cần phát tán rất cao đến hàng nghìn hoặc thậm chí hàng triệu điểm cuối.
Amazon SQS
Dịch vụ hàng đợi đơn giản của Amazon (Amazon SQS) cung cấp dịch vụ hàng đợi lưu trữ bảo mật, bền vững và có sẵn mà bạn có thể sử dụng để tích hợp và tách rời các hệ thống và thành phần của phần mềm phân tán. Amazon SQS cung cấp các ý tưởng phổ biến nhưhàng đợi thông báo không gửi được vàthẻ phân bổ chi phí.
Các bước tiếp theo để sử dụng Kiến trúc định hướng theo sự kiện AWS
