Kiến trúc hướng sự kiện ( EDA – Event Driven Architecture ) là một mẫu thiết kế phần mềm cho phép tổ chức phát hiện “sự kiện” hoặc các khoảnh khắc kinh doanh quan trọng (chẳng hạn như giao dịch, lượt truy cập trang web, bỏ qua giỏ hàng, v.v.) và hành động theo thời gian thực hoặc gần thực thời gian.
Mẫu này thay thế kiến trúc “yêu cầu / phản hồi” truyền thống, nơi các dịch vụ sẽ phải đợi phản hồi trước khi chúng có thể chuyển sang tác vụ tiếp theo. Luồng của kiến trúc hướng sự kiện được điều hành bởi các sự kiện và nó được thiết kế để phản hồi chúng hoặc thực hiện một số hành động để phản hồi lại một sự kiện.
Kiến trúc hướng sự kiện thường được gọi là giao tiếp “không đồng bộ”. Điều này có nghĩa là người gửi và người nhận không phải đợi nhau chuyển sang nhiệm vụ tiếp theo của họ. Hệ thống không phụ thuộc vào một thông điệp đó.
Ví dụ: một cuộc gọi điện thoại được coi là đồng bộ hoặc nhiều hơn theo đường của kiến trúc “yêu cầu / phản hồi” truyền thống. Ai đó gọi cho bạn và yêu cầu bạn làm điều gì đó, người yêu cầu đợi trong khi người trả lời hoàn thành nhiệm vụ và sau đó cả hai bên đều cúp máy. Một ví dụ về giao tiếp không đồng bộ sẽ là tin nhắn văn bản. Bạn gửi một tin nhắn và trong một số trường hợp, bạn thậm chí không biết mình đang gửi nó cho ai hoặc có ai đang nghe hay không, nhưng bạn không đợi phản hồi.
Sự phát triển của kiến trúc hướng sự kiện
Trong vài năm qua, đã có một phong trào từ tập trung vào dữ liệu ở trạng thái nghỉ (kiến trúc hướng dịch vụ) sang tập trung vào các sự kiện (kiến trúc hướng sự kiện). Chúng tôi đang chuyển từ việc tích lũy dữ liệu và hồ dữ liệu sang tập trung vào dữ liệu trong chuyến bay và theo dõi nó trong khi nó đang di chuyển từ nơi này sang nơi khác.
Theo truyền thống, hầu hết các hệ thống hoạt động theo mô hình mà bạn có thể nghĩ là mô hình trung tâm dữ liệu, nơi dữ liệu là nguồn chân lý. Việc chuyển sang kiến trúc hướng sự kiện có nghĩa là chuyển từ mô hình trung tâm dữ liệu sang mô hình trung tâm sự kiện. Trong mô hình hướng sự kiện, dữ liệu vẫn quan trọng, nhưng các sự kiện trở thành thành phần quan trọng nhất. Trong khi trong mô hình mô hình hướng dịch vụ, ưu tiên cao nhất là đảm bảo bạn không mất bất kỳ dữ liệu nào.
Với kiến trúc hướng sự kiện, ưu tiên là đảm bảo bạn phản hồi các sự kiện khi chúng diễn ra. Bởi vì có một quy luật lợi nhuận giảm dần khi nói đến các sự kiện, chúng càng già đi, chúng càng ít giá trị hơn. Tuy nhiên, ngày nay, kiến trúc hướng dịch vụ và kiến trúc hướng sự kiện thường được sử dụng cùng nhau.
Kiến trúc hướng sự kiện thường sử dụng sự tương tự nhật ký để theo dõi mọi thứ. Các nhà phân tích nói về các sự kiện như những điều bất biến đã xảy ra. Và nếu bạn muốn tìm hiểu những gì đã xảy ra trong quá khứ, bạn có thể quay lại và phát lại nhật ký.
Trong khi ở mô hình trung tâm dữ liệu, bạn chủ yếu tập trung vào trạng thái của dữ liệu như hiện tại. Và sau đó, phép loại suy cuối cùng mà các nhà phân tích sử dụng khi mô tả sự khác biệt giữa kiến trúc lấy dữ liệu làm trung tâm và sự kiện là họ thường so sánh chúng giữa một kho thông tin và một hệ thống thần kinh mang thông điệp xung quanh doanh nghiệp.
Khi sử dụng kiến trúc hướng sự kiện, bạn có các nhà sản xuất sự kiện tạo và gửi thông báo sự kiện và bạn có thể có một hoặc nhiều bên nhận thông tin sự kiện, nơi việc nhận sự kiện sẽ kích hoạt logic xử lý. Ví dụ: giả sử Netflix vừa tải lên một bộ phim mới. Có thể có một số ứng dụng đang lắng nghe hoặc chờ đợi thông báo đó, sau đó kích hoạt hệ thống nội bộ của chính chúng để công bố thông tin của riêng chúng về sự kiện đó cho người dùng của chúng. Điều này khác với nhắn tin trả lời yêu cầu truyền thống ở chỗ các ứng dụng vẫn đang chạy và mặc dù chúng có thể đang lắng nghe sự kiện này nhưng chúng không bị tê liệt trong khi chờ đợi. Và, họ có thể trả lời khi tin nhắn được xuất bản. Do đó, nhiều dịch vụ có thể chạy song song.
Sự kiện là gì?
Một sự kiện được định nghĩa là sự thay đổi trạng thái của một số hệ thống kinh doanh chính. Ví dụ: ai đó mua một sản phẩm, ai đó đăng ký chuyến bay hoặc xe buýt đến nơi nào đó trễ. Và nếu người ta nghĩ về nó, các sự kiện tồn tại ở khắp mọi nơi và liên tục xảy ra, bất kể ngành nào. Chúng có sức lan tỏa trên mọi lĩnh vực kinh doanh. Điều này bao gồm bất kỳ điều gì tạo ra một thông điệp bằng cách được sản xuất, xuất bản, phát hiện hoặc tiêu thụ đều được coi là một sự kiện.
Sự kiện tách biệt với thông báo, bởi vì trong khi sự kiện xảy ra, thông báo là thông báo di chuyển chuyển tiếp sự kiện. Trong kiến trúc hướng sự kiện, một sự kiện có thể sẽ kích hoạt một hoặc nhiều hành động hoặc quy trình để đáp ứng với sự xuất hiện của nó. Ví dụ về một sự kiện có thể bao gồm:
- Yêu cầu đặt lại mật khẩu
- Một gói hàng đến nơi đã được chuyển đến nơi
- Kho hàng tạp hóa cập nhật hàng tồn kho của mình
- Một nỗ lực truy cập trái phép đã bị từ chối
Mỗi sự kiện này có khả năng kích hoạt một hoặc nhiều hành động hoặc quy trình để đáp ứng. Một phản hồi có thể đơn giản là ghi lại sự kiện cho các mục đích giám sát. Những người khác có thể là:
- Một email để đặt lại mật khẩu được gửi đến khách hàng
- Vé bán đã đóng
- Đặt hàng thêm rau diếp (hoặc bất kỳ nguyên liệu nào sắp hết)
- Tài khoản bị khóa và nhân viên an ninh được thông báo
Với kiến trúc hướng sự kiện, khi một thông báo sự kiện được gửi đi, hệ thống sẽ nắm bắt được rằng điều gì đó đã xảy ra như thay đổi trạng thái đã xảy ra và chờ gửi câu trả lời cho bất kỳ ai yêu cầu, bất cứ khi nào họ yêu cầu. Ứng dụng đã nhận được thông báo đó có thể phản hồi hoặc chờ phản hồi cho đến khi xảy ra thay đổi về trạng thái mà nó đang chờ đợi.
Các ứng dụng được xây dựng dựa trên kiến trúc hướng sự kiện cho phép các ứng dụng kinh doanh kỹ thuật số nhanh nhẹn, có thể mở rộng, theo ngữ cảnh và đáp ứng nhanh hơn.
Kiến trúc hướng sự kiện hoạt động như thế nào?
Các thành phần của kiến trúc hướng sự kiện có thể bao gồm ba phần: nhà sản xuất, bên nhận thông tin , nhà môi giới. Người môi giới có thể là tùy chọn, đặc biệt khi bạn có một nhà sản xuất và một bên nhận thông tin duy nhất đang giao tiếp trực tiếp với nhau và nhà sản xuất chỉ gửi các sự kiện cho bên nhận thông tin .
Một ví dụ sẽ là một nhà sản xuất chỉ gửi đến cơ sở dữ liệu hoặc kho dữ liệu để các sự kiện được thu thập và lưu trữ để phân tích. Thông thường nhất trong các doanh nghiệp, bạn có nhiều nguồn gửi tất cả các loại sự kiện với một hoặc nhiều bên nhận thông tin quan tâm đến một số hoặc tất cả các sự kiện đó.
Hãy xem một ví dụ. Nếu bạn là nhà bán lẻ, bạn có thể thu thập tất cả các giao dịch mua đang diễn ra tại tất cả các cửa hàng của bạn trên toàn thế giới. Bạn đang đưa chúng vào cấu trúc theo hướng sự kiện của mình để theo dõi gian lận, gửi chúng đến bộ xử lý thẻ tín dụng hoặc bất kỳ hành động nào cần xảy ra tiếp theo. Đối với một nhà sản xuất, bạn có tất cả các loại dữ liệu từ thiết bị của bạn để cho bạn biết các sự kiện như nhiệt độ và áp suất để bạn có thể theo dõi các sự kiện này trong thời gian thực và thực hiện các hành động như dự đoán lỗi hoặc lên lịch bảo trì, tùy thuộc vào những gì dữ liệu cho bạn biết .
Ưu điểm của việc sử dụng kiến trúc hướng sự kiện
Nhiều ứng dụng hiện đại đang hỗ trợ nhanh chóng các kiến trúc hướng sự kiện. Tại sao thế này? Họ cung cấp những lợi ích gì?
Kiến trúc hướng sự kiện là một cách tiếp cận kiến trúc. Các ứng dụng được viết bằng bất kỳ ngôn ngữ nào trên bất kỳ nền tảng nào đều có thể sử dụng mẫu kiến trúc này. Ở đây, chúng ta sẽ khám phá một số lợi thế của việc áp dụng kiến trúc hướng sự kiện.
Sự tách biệt thực sự giữa Bên Event Publish và bên nhận thông tin
Hệ thống sử dụng kiến trúc hướng sự kiện tách các thành phần trong hệ thống, phân tách quyền sở hữu dữ liệu theo miền. Sự tách rời này cho phép phân tách hợp lý giữa sản xuất và tiêu thụ các sự kiện.
- Bên Event Publish không cần quan tâm đến việc các sản phẩm mà họ sản xuất sẽ được tiêu thụ như thế nào (vì vậy có thể thêm bên nhận thông tin mà không ảnh hưởng đến Bên Event Publish ).
- bên nhận thông tin không cần quan tâm đến việc chúng được sản xuất như thế nào.
Do khớp nối lỏng lẻo này, các microservices có thể được thực hiện bằng các ngôn ngữ khác nhau hoặc sử dụng các công nghệ khác nhau và phù hợp với các công việc cụ thể. Do đó, việc mã hóa dữ liệu sự kiện không quan trọng – nó có thể là JSON, XML, Avro, v.v.
Việc tách các thành phần của một ứng dụng cũng cho phép chúng được chia tỷ lệ dễ dàng và độc lập với nhau trên toàn mạng. Các nhà phát triển có thể sửa đổi hệ thống của họ bằng cách thêm hoặc xóa động các nhà sản xuất sự kiện và bên nhận thông tin mà không cần thay đổi bất kỳ logic nào trong bất kỳ dịch vụ vi mô nào.
Không một dịch vụ sản xuất nào cần biết về các dịch vụ tiêu thụ các sự kiện mà họ sản xuất. Tương tự, khi bất kỳ dịch vụ nào sử dụng thông điệp, họ chỉ cần đăng ký luồng sự kiện.
Trong sơ đồ ví dụ trên, chúng ta có thể dễ dàng thêm Dịch vụ Tài chính Taxi đăng ký các sự kiện Dịch vụ Xe Taxi và thu thập dữ liệu, có thể bao gồm mức tiêu thụ nhiên liệu. Với dịch vụ vi mô được bổ sung này, Dịch vụ xe taxi sau đó có thể đề xuất giá cước tốt nhất hoặc gửi các sự kiện mới về hiệu quả của tài xế, cả hai đều có thể được Dịch vụ đội xe taxi sử dụng như một yếu tố khi phân bổ tài xế cho các đơn đặt hàng.
Khả năng phục hồi
Sự kết hợp lỏng lẻo của các thành phần mà kiến trúc hướng sự kiện cung cấp cũng có nghĩa là các dịch vụ không cần phải lo lắng về trạng thái hoặc sức khỏe của dịch vụ khác. Sự kết hợp lỏng lẻo này cung cấp một mức độ phục hồi trong hệ thống, vì vậy nếu một microservice bị hạ xuống, ứng dụng vẫn có thể tiếp tục chạy khi không có nó. Điều này đạt được nhờ các sự kiện được lưu trữ trong xương sống nhắn tin để dịch vụ tiêu thụ có thể nhận chúng khi nó phục hồi.
Mặc dù khả năng phục hồi không dành riêng cho các kiến trúc hướng sự kiện, nhưng bản chất của cách các sự kiện đến mang lại một lợi thế bổ sung. Sự kiện là không đồng bộ, có nghĩa là các sự kiện được xuất bản khi chúng xảy ra. Các dịch vụ sử dụng các sự kiện dưới dạng một luồng không bị ràng buộc và chúng theo dõi nơi chúng đến. Vì vậy, nếu các dịch vụ bị lỗi, chúng có thể tiếp tục từ nơi chúng đến và nếu cần, phát lại các sự kiện có thể đã bị lỗi.
Dịch vụ sản xuất không bị ảnh hưởng, nó có thể tiếp tục sản xuất các sự kiện. Điều này trái ngược với các kiến trúc REST, là kiến trúc đồng bộ, vì vậy các dịch vụ ngang hàng phải được thiết lập và logic thử lại phải được thực hiện để đối phó với các lỗi mạng.
Ví dụ: kiến trúc hướng sự kiện có thể hữu ích trong các tình huống mà bạn có các Edge Device dễ chuyển sang chế độ ngoại tuyến. Sau khi các Edge Device quay trở lại, các sự kiện vẫn có thể được xử lý bởi ứng dụng khách.
Ví dụ trong vận chuyển, chúng ta hãy xem xét các container vận chuyển thông minh. Container vận chuyển thông minh là Container thu thập và phân tích dữ liệu đo từ xa về tình trạng của Container và gửi dữ liệu tóm tắt trở lại trung tâm trung tâm theo khoảng thời gian đều đặn. Hệ thống mạng thường có thể không đáng tin cậy trên tàu, vì vậy nếu bạn có một số container vận chuyển thông minh trên tàu và chúng hoạt động ngoại tuyến, khi chúng hoạt động trở lại, bên nhận thông tin trên bờ vẫn có thể nhận được tin nhắn. Tương tự, nếu bạn có một số bản cập nhật cần được gửi đến biên từ trên bờ, chúng sẽ vẫn được nhận sau khi các dịch vụ biên hoạt động trở lại
