[Go] EDA event-driven architecture

Events represent events that occurred in the past, and events are both technical architecture concepts and business concepts. An event-driven programming model is called an event-driven architecture, EDA.

EDA is an event-based medium that implements the maximum loosely coupled approach between components or services. The traditional interface-oriented programming is to realize the decoupling between the interface and the interface, but this decoupling is not very high, if the interface changes, both the code needs to change, and the event-driven is the caller and the callee do not know each other, the two only and the intermediate message queue coupling.

Event drivers have the following characteristics:

1. Real-time events occur in producer producer
2. Push Notifications
3. Producer launches Complete Fire-and-orget
4. Consumer consumer Immediate response
5. There's a difference between an event and a command.

With the characteristics of the asynchronous model of the message system, the event-driven also has the asynchronous feature, the traditional method invocation such as Call B.xxmethod () is a synchronous model, you must wait for the method of B to finish before executing other code, RPC remote method call is also a synchronous model, and for the asynchronous model, After the event producer issues an event, you do not have to wait for a response to proceed with the following code.

But it does not mean that the architecture that uses the messaging system is a EDA,SOA service-driven architecture that also uses a messaging system as an ESB, using different methods and three different ways of interacting:

1. Time-driven: such as cron timing schedule execution
2. Request-driven: Common SOA between client and server
3. . Event-Driven: event-based feature. Realtime.

The request driver + message system and the event-driven + message system have the essential difference, the former is by the requestor as the message producer, the main purpose is to get the response, and therefore is a request response model, while the latter focus on the message consumers, not in the message producer, business logic station in the consumer perspective, The completion of the business logic is performed by event-driven, while the business logic is done in the message producer, and when the business logic requires dependencies or resources, it relies on sending messages to pull through. These two differences are essentially the difference between pull poll and push push.

Because of the essential difference between EDA and traditional SOA, it is now the birth of an area of EDA, which includes cqrseventsourcing domain events and so on. At the same time, traditional SOA divides the business domain into different systems and behaves as a service, which leads to the business logic spanning multiple systems, causing the business logic to be scattered everywhere, to find maintenance inconvenient, and to cause the pollution and expansion of business logic.

Using EDA to transform a traditional SOA, for example, if a reporting system wants to know the state of a trading system, it does not send a message to the trading system, pulls its current state, but subscribes to the event bus so that when the trading system has a status report, an event notification report system is issued.

The scalability and throughput of EDA is stronger than the traditional Soa,eda-like assembly line, for a sequential linear processing process, 6 steps are to accept confirmation save produce PDF send email output show, spend 365ms:

and the assembly line of EDA, always ask whether 6 steps can let others cooperate to help complete? The 4th and 5th steps are possible, so the entire processing time is increased to 115ms, increasing the response time by 70%:

The detailed assembly line is as follows, which is actually also a seda,staged EDA:

Finally, we can complete a new D-eda+soa architecture based on domain events as follows:

[Go] EDA event-driven architecture