Event-driven Architecture

Trong bài viết này mình sẽ giải thích về Event-driven Architecture theo cách đơn giản nhất. Trước khi mình học về phần này, mình cũng có đọc qua khá nhiều bài nhưng cách mô tả của họ hơi phức tạp với một người chưa có nhiều kinh nghiệm về Microservice và các kiến trúc trong lập trình như mình. Hy vọng bài viết này(cũng như series này) sẽ giúp cho những bạn cảm thấy trầm cảm về việc phải học những kiến thức mới sẽ dễ dàng tiếp cận chúng hơn ạ.

1. Vấn đề mà phương thức giao tiếp truyền thống gặp phải

Khi 2 ứng dụng cần giao tiếp với nhau, thường chúng sẽ giao tiếp bằng cách gửi đi request và nhận về response. Ví dụ như hình dưới đây, microservice A sẽ gửi một request đến Microservice B, sau khi xử lý xong Microservice B sẽ trả về một response cho Microservice A.

Cách giao tiếp này sẽ khá phổ biến đối với những người mới học từ Monolithic sang Microservice như mình, chỉ đơn giản là gửi và nhận. Bây giờ, có một vấn đề là Microservice C và Microservice D cũng muốn nhận request này từ Microservice A.

Thực ra với 3 Microservice thì chúng ta vẫn có thể xử lý được bằng cách gửi request/message đến cả 3 Microservice cùng một lúc. Tuy nhiên sẽ ra sao nếu chúng ta có khoảng 50 microservice muốn nhận được request/message từ Microservice A? Chẳng lẽ chúng ta sẽ hard code ở trong Microservice A gửi đi 50 cái request à?(Ừ thì vẫn được nếu bạn là một người thích khổ dâm :v). Khi này phương thức giao tiếp truyền thống sẽ không còn hiệu quả nữa. Chúng ta cần tìm một phương thức để có thể xử lý vấn đề này. Một trong những phương thức đó là sử dụng Event-Driven Architecture.

2. Event-Driven Architecture là gì?

Về khái niệm chi tiết thì mọi người có thể tham khảo ở đây https://en.wikipedia.org/wiki/Event-driven_architecture hoặc các nguồn khác trên google. Ở đây mình nhấn mạnh lại rằng mình sẽ viết nó theo cách đơn giản nhất, có lẽ sẽ không đúng được 100% theo như định nghĩa.

Quay trở lại với vấn đề mà chúng ta gặp phải ở trên, thay vì gửi trực tiếp cho từng Microservice, chúng ta sẽ gửi message đến một thành phần trung gian là message broker. Các Microservice muốn nhận message này sẽ consume message từ message broker ngay khi nó xuất hiện ở đó. Mô hình này được gọi là "producer và consumer" trong đó Microservice A sẽ là producer, các Microservice muốn nhận message sẽ là consumer. Lưu ý rằng message có thể có nhiều loại khác nhau như command(gửi request để update/create một sản phẩm), event hoặc query(gửi request để yêu cầu get thông tin một sản phẩm).

Ví dụ, Microservice A nhận một command để thực hiện một công việc nào đó. Sau khi thực hiện xong, nó sẽ gửi đi một message mới, có thể là một event đến message broker. Tất cả các Microservice đã đăng ký với message broker sẽ nhận được message này và xử lý nó.

Trong kiến trúc này, các microservice giao tiếp với nhau bằng cách publish và consume các message hoặc event, chính vì vậy nên chúng ta gọi kiến trúc này là Message-driven Architecture hoặc Event-driven Architecture.

Event-driven Architecture là bất đồng bộ. Khi Microservice A gửi đi một event đến message broker, message broker có thể trả về một phản hồi cho Microservice A ngay lập tức mà không cần chờ các Microservice khác xử lý event đó. Ngoài ra Microservice A cũng không cần phải biết event đó đã được nhận và xử lý bởi các Microservice khác hay chưa.

Với việc gửi request và nhận response trực tiếp theo cách truyền thống, nếu service không hoạt động khi message được gửi đến thì nó có thể sẽ không nhận được message đó. Tuy nhiên với Event-driven Architecture thì lại khác, nếu một trong các Microservice đăng ký nhận message mà không hoạt động, khi nó hoạt động trở lại, nó vẫn có thể consume message đã được gửi đi từ microservice A và xử lý event đó. Đây chính là một lợi ích của Event-driven Architecture.

Cám ơn mọi người đã đọc bài viết này, trong bài viết tiếp theo mình sẽ giới thiệu về transaction và SAGA trong microservice.