Author | Ken Meng
Nowadays, more successful companies have realized that in order to maximize operational efficiency and customer experience, they must closely integrate business and technical measures. Operational events or changes in the business situation are the focus of many companies nowadays. These changes can bring practical and useful information to business leaders. The main purpose of the architecture design is to obtain information from customer contacts, transactions, operations, etc. Insights, the two complement each other. Traditional technologies have always limited the speed at which companies can obtain insights from events, such as batch ETL (extract, transform, load) used to record, collect, and process such events.
Event-driven architecture (EDA) is in the ascendant. As a serverless application concept, it has a profound impact on cloud native architecture. When we discuss a specific structure, the first thing to bear is whether its development is technologically advanced. Let's start with the familiar MVC architecture and SOA architecture, and let's talk about the history and development trend of the field of news events.
Trends in the field of news events
As early as 2018, the Gartner evaluation report listed Event-Driven Model as one of the top 10 strategic technology trends. Event-Driven Architecture (EDA) will become the mainstream of microservices in the future, and made the following assertions:
- By 2022, the software model of event notification will become more than 60% of new digital business solutions;
- By 2022, more than 50% of business organizations will participate in the ecosystem of event-driven digital business services;
George Santayana mentioned in The Life of Reason, Those who fail to learn History are doomed to repeat it. Let's learn from history to see why the architecture will evolve to event-driven.
There is no difference between the advantages and disadvantages of the architecture itself. It is a set of technical decisions that determine all the functional development of subsequent projects (framework, coding specifications, documents, processes...). Let’s talk about why certain frameworks are introduced. This framework solves the problem. What is the problem in software development.
- Monolithic architecture: In a single-node service, all modules of a monolithic application are encapsulated to run in a single process, and communication is completed through the same stack call. Under this mode, it is very easy to cause the structure and relationship to be unclear, and it is difficult to change and reconstruct the system. It's like an opaque, sticky, fragile, and stiff Big Ball of Mud!
- Layered architecture: In the classic layered architecture, layers are used in a very careful manner. That is, a layer can only know the data of the layer below it. In subsequent practical applications, more ways are that a layer can access any layer below it. The layered architecture solves the logical separation problem of the monolithic architecture. Each layer can be replaced by equivalent, and the layer distinction is more standardized. At the same time, a layer can be used by several different/higher-level layers. Of course, the layer also has obvious shortcomings. The layer cannot encapsulate everything. For example, a field added to the UI may also need to be added to the DB, and the extra layer will seriously damage the system performance.
- MVC architecture: The reason for the MVC architecture is actually very simple. As the complexity of the business system increases, the so-called "full stack engineer" is no longer suitable for most scenarios. In order to reduce the complexity of front-end and back-end integration, the MVC architecture has been promoted. Among them, Model represents business logic, View represents a view layer such as a small component of the front-end UI, and Controller provides coordination between View and Model, such as converting a user's operation into business logic. There are also many extended architectures, such as Model-View-Presenter, Model-View-Presenter-ViewModel, Resource-Method-Representation, Action-Domain-Responder.
- EBI architecture: Entity, Boundary (interface), Interactor (control). The EBI architecture treats system boundaries as complete connections, not just views, controllers or interfaces. The entity of EBI represents the actual entity that holds data and ends related behaviors, which is very similar to Alibaba Cloud's POP API. EBI is mainly a back-end concept, which is complementary to MVC.
- Onion architecture: Onion architecture is an architecture model with low coupling and high cohesion. All applications are built around an independent object model. The inner layer defines the interface and the outer layer implements the interface. The coupling direction is cohesive to the center. All codes can be compiled and run independently of the infrastructure.
- SOA architecture: SOA is the abbreviation of Service Orientated Architure, that is, service-oriented architecture. It means that each function is provided through an independent service, the service defines a clear callable interface, and the orchestration call between services completes a complete business. In fact, this architecture is also the most mature in the current architecture and the most commonly used architecture model.
What is EDA architecture
After we talked about all the previous architecture trends, we will look back at what EDA architecture is.
EDA Event-Driven Architecture is a system architecture model. Its core ability lies in the ability to discover system "events" or important business moments (such as transaction nodes, site visits, etc.) and respond in real-time or near real-time. Necessary actions for the incident. This model replaces the traditional "request/response" model. In this traditional architecture, the service must wait for a reply before it can enter the next task. The process of event-driven architecture is run by events.
The above figure actually explains the EDA architecture model very well, but it is not clear enough. So, here we compare with the monolithic architecture to see the differences between them.
In the above comparison chart, we can actually see the difference between it and the traditional architecture more clearly. In the general traditional architecture, after the order creation operation occurs, a series of operations are actually completed through a system. The event-driven concept is to convert all operations into an "event" concept, and the downstream determines what system to call to complete what kind of operation by capturing an "event".
In summary, event-driven actually encapsulates more important business moments into "events" and routes the events to downstream systems through an EventBus.
We understand the entire processing process of the EDA architecture, but have not yet resolved what this so-called "EventBUS" is.
The above figure is the core logic architecture of event-driven. Is it very similar to a traditional MQ? Don't worry, I will talk about the complex parts of this architecture below. After talking about EventBus, let's look back at "events". The more important part of the introduction just now is actually converting operations into certain types of events for distribution. How do we define this event?
To put it simply, an event is a significant change in the state, which is triggered when the user takes a specific action. Take a 4S store selling cars as an example:
- It is an event when a customer purchases a car and its status changes from For Sale to Sold.
- After a successful transaction, deduction of the amount from the account is an event.
- After you click to book a test drive, adding the appointment information to the specified user is an event.
Each event may trigger one or more options in response.
Regarding events, the Cloud Native CNCF Foundation hosted the open source CloudEvents project in 2018. The project aims to describe events in a unified and standardized format to enhance the interoperability between different services, platforms, and systems. Under the project definition, the general event specification is as follows:
The event is mainly composed of Json body, and the event that occurs is described through different fields.
Practical thinking on the implementation of EDA architecture
When we begin to introduce the landing practice, let's first look at a classic EDA architecture model:
This is a very classic EDA order architecture, which mainly uses EventBridge and FC function calculations (if you are not familiar with FaaS, you can use FC nodes as ECS or K8s POD nodes), and drive various businesses to collaborate through events .
Therefore, the central node (EventBridge) of this block actually has three more important capabilities:
- For Event Capturing (event collection): with the ability to capture events
- For Routing (event routing): the ability to distribute event routing to downstream through event content
- For Event Processing (event filtering/replacement): the ability to desensitize or preliminarily filter & screen events
Under normal circumstances, it is more difficult to implement these three capabilities. For example, Event Capturing may need to be familiar with Dell Boomi, Snaplogic, MuleSoft, Dataflow, Apache Apex, etc. The routing part may pass RocketMQ, RabbitMQ, ActiveMQ, Apache Kafka, Event Processing Need to know Apache Storm, Apache Flink. Therefore, the logical architecture mentioned before is actually very ideal, and these core capabilities need to be included in order to achieve the completed EDA event-driven.
In fact, we can also snoop some information from the architecture just now. The EDA architecture does not seem to be that simple, so what are the advantages and disadvantages of it? Below I will briefly list the advantages of the EDA architecture in practice:
- Loosely coupled: The event-driven architecture is a highly loosely coupled and highly distributed architecture model. The creator (source) of the event only knows the event that occurs, not how the event is handled, and also cares about how many related parties subscribe to the event.
- Asynchronous execution: The EDA architecture is the most suitable execution tool in asynchronous scenarios. We can keep the required events in the queue until the state is normal and execute them.
- Scalability: Event-driven architecture can quickly divide services through routing & filtering capabilities, providing more convenient expansion and routing distribution.
- Agility: Event-driven architecture can provide a more agile and efficient deployment plan by distributing events to any place.
Of course, the disadvantages are also obvious:
- Complex architecture: The event-driven architecture is complex, there are many routing nodes, the system is complex, and there are many functional requirements.
- Difficult routing and distribution: Event routing and distribution are difficult. Flexible event routing needs to rely on powerful real-time computing capabilities, which requires higher requirements for the overall distribution system.
- Untraceable: Event tracking is the guarantee of the entire EDA architecture. It is often difficult to track the event processing status in the EDA architecture and requires a lot of customized development.
- Poor reliability: Event-driven due to the need for multi-system integration, reliability is usually poor, and delivery cannot be guaranteed.
How does Alibaba Cloud EventBridge solve the dilemma in the EDA scenario
In response to these problems in the EDA scenario, Alibaba Cloud has launched EventBridge, a serverless event bus service. Its mission is to serve as the hub of cloud events, connecting cloud products and applications, applications and applications, and providing a center with the standardized CloudEvents 1.0 protocol. Event governance and driving capabilities help users easily build loosely coupled and distributed event-driven architecture; in addition, there are a large number of SaaS services in the vertical field in the cloud market outside of Alibaba Cloud, and EventBridge will provide excellent cross-product and cross-product Organizational and cross-cloud integration and integration capabilities help customers create a complete, event-driven, efficient and controllable cloud experience. It also provides targeted solutions to the EDA dilemma.
Complex architecture: Provides the industry's common Source, Buses, Rules, and Targets module management capabilities, and supports EventBus and EventStream two modes at the same time. Significantly reduce the difficulty of event-driven architecture.
Routing and distribution: EventBridge is driven by event rules, supports 8 event modes, and four-fold converters to meet all requirements for routing and distribution.
Unable to track: Exclusively provide event tracking capabilities, event analysis/query capabilities. Improve the overall event link for users.
Poor reliability: Support DLQ/retry mechanism, which greatly guarantees event failure and delay caused by the user's downstream system.
At the same time, EventBridge supports 82 Alibaba Cloud products and 847 event types on this basis.
More scenarios of Alibaba Cloud EventBridge
- Classic EDA event-driven: The most important capability of EventBridge is to build EDA (Event-driven Architectures) event-driven architectures by connecting applications, cloud services, and serverless services to drive applications and applications, and applications and cloud connections.
- Streaming ETL scenario: Another core capability of EventBridge is to provide basic filtering and conversion capabilities for streaming data pipelines, between different data warehouses, data processing programs, and data analysis and processing systems. Perform scenarios such as data synchronization/cross-regional backup, connecting different systems and different services.
- Unified event notification service: EventBridge provides a wealth of cloud product event sources and full lifecycle management tools for events. You can directly monitor the data generated by cloud products through the bus and report it to downstream services such as monitoring and notification.
Currently, the event bus is free of public beta, click the link below to experience it now!
https://www.aliyun.com/product/aliware/eventbridge?spm=5176.19720258.J_8058803260.46.70c22c4aFzf3Pq
Join the nail group (group number: 31481771) to keep abreast of the latest product developments!
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。