This is the 12th day of my participation in the August More Text Challenge. For details, see: August More Text Challenge

Event-driven architecture

Event Driven Architecture is a popular distributed, asynchronous Architecture pattern that can be used to design very large applications. Based on this architectural pattern, applications can be large or small. It consists of highly decouple, single-purpose event processing components that receive and process events asynchronously.

An event-driven system typically consists of event consumers, who subscribe to event managers, and event producers, who publish events to event managers. When the event manager receives an event from the event producer, the event manager forwards the event to the corresponding event consumer. If the event consumer is not available, the event manager keeps the event and forwards it to the event consumer again after a certain interval.

Key concept explanation

Event: Notification from the system layer when the state of a system or component changes.

Decoupling: Each object communicates with the outside world through Mediator or Broker, rather than relying on each other (Demeter’s Law).

Communication mode: message is used as the carrier and communication is transmitted through middleware.

Topological classification

It consists of two main topologies: Mediator and broker.

  • Mediator topology

  • Broker topology

The characteristics and implementations of the two topologies are quite different, so you need to know which one is right for you.

Mediator topology

The Mediator topology is suitable for multi-step events that require a hierarchy of processing.

In the architecture using Mediator mode, events are generally complex (including the collection of multiple execution units), and the responsibility of Mediator is to disassemble the composite event into independent sub-events, and then send them to different types of sub-event processing systems, where the subsystem completes the distribution and processing of independent sub-events.

Structurally, Mediator’s EDA architecture includes four components:

  • event queues

It is used to store the original Event (classification) and send it to Event Mediator, which generally exists in the form of MQ.

  • event mediator

For the disassembly of the original event (into separate sub-events) and forwarding to the related Channel;

  • event channels

Channels (thought of as subdivided Event queues) are divided according to the type of events. It can be a message queue that feeds specific Processor queries, or a message Topic that sends specific broadcasts.

  • event processors

Event handlers that listen to specific channels and process events after they are captured

The process of Mediator is shown in the figure below:

  • A client sends an event to event Queues, which are used to transmit events to Event Mediators.

  • After receiving the initial Event, Event Mediator sends additional asynchronous events to Event Channels to perform each step of the process.

  • Event Channels can be either a message queue or a message topic, most of which are message topics, so that multiple Event processors can process the same message.

  • Event Processors listens to Event Channels, receives events, and processes some business logic.

It is worth noting that:

1. It is normal in event-driven architectures to have dozens or even hundreds of event queues.

The pattern itself does not define how an event queue is implemented. It could be a message queue, a Web service, or something else.

The message handler contains the actual business logic. Each message processor is self-contained, independent, and highly decoupled, performing a single task.

Broker topology

Brokers are a more concise event-driven architecture, and unlike the above structure, there is no central Mediator.

Structurally, the EDA architecture of the Broker consists of three components:

  • Event

  • Event Channel

  • Event Processor

As shown, it contains two components, the Broker and the Event Processor.

  • An Event channel in a broker can be a message queue, a message topic, or a combination of them.

  • Each Event processor is responsible for processing events and publishing new events.

Architectural considerations

The event-driven architecture pattern is relatively complex to implement, mainly due to its asynchronous and distributed nature. This can lead to distributed issues such as availability of remote processing, lack of responsiveness, broker reconnection, etc.

1. Distributed asynchronous architecture

The event handlers are highly decouple, the software scales well, the event handlers can be loaded and unloaded independently, it is easy to deploy, and the software performs well because of the asynchronous nature of events and the software is less prone to congestion.

2. Lack of atomic transactions for single logic

This pattern requires atomic transactions to be executed by an event handler, and atomic transactions across event handlers are difficult to roll back. It is also difficult to create, maintain and manage event handlers, and events usually have special conventions (data values and formats).

Pattern analysis

Combined with the above analysis, the overall analysis of event-driven architecture design pattern is as follows:

  • Overall flexibility: high

  • Release ease of use: High

  • Testability: low

  • High performance:

  • Scale expansion: high

  • Ease of development: low

– END –

Author: Architecture improvement road, ten years of research and development wind and rain road, dacang architect, CSDN blog expert, focus on architecture technology precipitation learning and sharing, career and cognitive upgrading, adhere to the sharing of grounding gas dry articles, look forward to growing with you. Follow and private message I reply “01”, send you a programmer growth advance gift package, welcome to hook up.

This article was published on the public account of the same name, “The Road to Architecture Improvement”, and the original link is “Event-driven Architecture of Software Architecture Patterns”

Thanks for reading!