Summary: EventBridge is an event-driven concrete landing product and EDA best practice.

Author: Ken Meng

As one of the top 10 strategic technology trends defined by Gartner, event-driven Architecture (EDA) is becoming the dominant technology architecture. According to Gartner’s estimates, EDA will be used in 60 percent of new digital business solutions and accounts for half of the technology stack in which business organizations participate.

Today’s more successful companies have learned that to maximize operational efficiency and customer experience, they must integrate business and technology initiatives closely. Operational events or changes in the business situation are the focus of many organizations today, and these changes can bring practical and useful information to the leaders of the enterprise. The purpose of architectural design is to gain insights from customer contacts, transactions, operations, etc. The two complement each other. Traditional technologies, such as batch ETL (extract, transform, load) used to record, collect, and process such events, have historically had limitations on how quickly an enterprise can gain insights from them. Based on the above background, Aliyun EventBridge came into being.

EventBridge is an event-driven concrete landing product and EDA best practice.

What is event driven (EDA)

Back in 2018, Gartner’s evaluation report listed event-driven Model as one of the top 10 strategic technology trends, and event-driven Architecture (EDA) will become the mainstream of microservices in the future. The report also makes the following assertions:

• By 2022, event notification software models will be the solution for over 60% of new digital businesses;
• By 2022, more than 50% of business organizations will participate in an event-driven ecosystem of digital business services.

I like George Santayana’s quote in The Life of Reason that Those who fail to Learn History are Doomed to repeat Those who do not know history are doomed to repeat it Let’s look at history to see why architecture has evolved to be event-driven.

The diagram above shows the timeline of architecture evolution. Architecture itself is not superior or inferior, it is a set of technical decisions that determine all functional development (framework, coding specification, documentation, process… .). “, so I’m not talking about the quality of the selection, just why certain frameworks are introduced and what problems they solve in software development.

• ** Singleton architecture: ** In a single-node service, all modules of a singleton application are encapsulated in a single process and run, communicating through the same stack calls. In this mode, it is very easy to lead to unclear structure and relationship, and it is difficult to change and reconstruct the system. It’s like an opaque, sticky, fragile, stiff Big Ball of Mud!
• ** Layered architecture: ** In classic layered architecture, layers are used in a fairly discreet manner. That is, a layer can only know the data of the layer below it. In subsequent practical applications, it is more likely that one layer can access any layer below it. Layered architecture solves the problem of logical separation of individual architectures. Each layer can be replaced by equivalent, which is more standardized with layers. At the same time, a layer can be used by several different/higher level layers. Of course, there are obvious drawbacks to layers. Layers don’t encapsulate everything. For example, a field added to the UI may need to be added to the DB, and extra layers can seriously hurt system performance.
• **MVC Architecture: ** THE reason for the MVC architecture is very simple. As business systems become more complex, the previous term “full stack engineer” is no longer suitable for most scenarios. In order to reduce the integration complexity of front-end and back-end, MVC architecture was promoted. Model represents business logic. View represents the View layer, such as a widget of the front-end UI; The Controller provides coordination between the View and Model, such as converting a user action to business logic. In addition, there are many extension architectures, such as model-view-presenter, model-view-viewModel, resource-method-representation, I’m not going to go into detail here, but if you’re interested, you can do a wiki search.
• **EBI architecture: ** Entity, interface, Interactor. The EBI architecture treats system boundaries as complete connections, not just views, controllers, or interfaces. EBI’s entity represents the actual entity that holds the data and ends the related behavior, much like ali Cloud’s POP API. EBI is primarily a back-end concept that complements MVC.
• ** Onion architecture: ** Onion architecture is a low coupling, high cohesion architectural model. All applications are built around a separate object model, with interfaces defined in the inner layer and implemented in the outer layer. The coupling direction is centralized, and all code can be compiled and run independently of the infrastructure.
• **SOA architecture: **SOA stands for Service Orientated Architure. Each function is provided by a separate service that defines a clear callable interface and choreographed calls between services to complete a complete business. In fact, this architecture is the most mature and most commonly used architectural pattern in the current architecture.

After covering all of the previous architectural trends, let’s go back and look at what EDA architectures are.

EDA event-driven Architecture is a system Architecture model whose core capability lies in the ability to detect system “events” or important business moments (such as transaction nodes, site visits, etc.) and take necessary actions on corresponding events in real time or near real time. This pattern replaces the traditional “request/ Response” model, where a service must wait for a reply before moving on to the next task. Event-driven architecture processes are run by events.

The figure above actually explains the EDA architecture model well, but it is not clear enough, so let’s compare them with individual architectures to see how they differ.

In the diagram above, we can see the difference between it and traditional architecture. In a traditional architecture, after the order creation operation occurs, a series of operations are actually done through a system. The event-driven concept translates all operations into an “event” concept, and the downstream captures an “event” to determine which systems are called to perform what operations.

Going back to “events,” the important part of the comparison that I just introduced is actually converting operations to some kind of event for distribution. So how do we define an event here?

Simply put, an event is a significant change in state that is triggered when the user takes a specific action. Take cars sold in 4S shops as an example:

• When a customer buys a car and its status changes from “For Sale” to “Sold” is an event;
• After a successful transaction, the amount deducted from the account is an event;
• After clicking reservation test drive, it is an event to add reservation information to the specified user.

Each event may trigger one or more options in response.

In 2018, the Cloud Native CNCF Foundation hosted the open source CloudEvents project, which aims to describe events in a unified and standardized format to enhance interoperability between different services, platforms and systems. Under the project definition, the common event specification looks like this:

Events are composed of Json bodies that describe events through different fields.

In summary, event-driven encapsulates significant business moments as “events” and routes the events to downstream systems via an EventBus.

Understanding the whole process of EDA architecture, but still not solving this so-called “EventBus” exactly what?

The core logical architecture of EventBus, which consists of Event Producer and Event Consumer, is very similar to a traditional MQ architecture. Don’t worry, the hard parts of this architecture will be explained in the next hands-on section.

EDA architecture landing practice thinking

To begin with, let’s look at a classic EDA architecture model:

This is a very classic EDA order architecture, which uses EventBridge and FC functions (if you are not familiar with FaaS you can think of FC nodes as ECS or one of Kubernetes’ POD nodes) to drive various businesses to collaborate through events.

So the EventBridge actually has three important capabilities:

1. For Event Capturing: Ability to capture events;
2. For Routing: Ability to distribute event routes downstream by event content;
3. For Event Processing: The ability to desensitize or initially filter events.

In general, these three capabilities are difficult to implement. For example: Experience Capturing may require familiarity with Dell Boomi, Snaplogic, MuleSoft, Dataflow, Apache Apex, etc. Routing may be through RocketMQ, RabbitMQ, ActiveMQ, Apache Kafka. Event Processing requires Apache Storm and Apache Flink. So the logic architecture mentioned above is actually ideal, and to achieve the completion of EDA event-driven also need to include these core capabilities.

In fact, from the framework just we can also pry some information, EDA architecture actually looks not so simple, that it has any advantages and disadvantages?

The following is a simple list of EDA architecture advantages in practice:

** Loosely coupled: ** Event-driven architectures are highly loosely coupled and highly distributed architectural models in which event creators (sources) only know what events happen, not how they are handled, and care how many interested parties subscribe to the event;

** Asynchronous execution: **EDA architecture is the most suitable execution tool for asynchronous scenarios, we can keep the required events in the queue until the state is normal to execute;

** Scalability: ** Event-driven architecture can quickly divide services through routing & filtering capabilities, providing more convenient extension and routing distribution;

** Agility: ** Event-driven architectures provide more agile and efficient deployment solutions by distributing events anywhere.

Of course, the disadvantages are obvious:

** Complex architecture: ** complex event-driven architecture, multiple routing nodes, complex system formation, and multiple functional requirements;

** Routing difficulty: ** Event routing is difficult to distribute. Flexible event routing relies on powerful real-time computing capability and has high requirements on the overall distribution system.

** Untraceable: ** Event tracking is the guarantee of the entire EDA architecture, which is often difficult to track event processing status and requires a lot of custom development;

** Poor reliability: ** Event-driven due to the need for multi-system integration, reliability is often poor and delivery is not guaranteed.

How to solve the dilemma in EDA scenario

To address these problems faced by EDA scenarios, ali cloud launched EventBridge, a serverless event bus service. Its mission is to serve as the hub of CloudEvents, connecting cloud products and applications with standardized CloudEvents 1.0 protocol, providing centralized event governance and driving capabilities. Help users easily build loosely coupled, distributed event-driven architectures; In addition, there are a large number of SaaS verticals in the cloud market outside AliYun. EventBridge will help customers create a complete, event-driven, efficient and controllable cloud experience with its outstanding integration and being integrated across products, organizations and clouds.

Aliyun defines EventBridge’s core values as:

• Unified event hub: unify event interface, define event standard, break the isolated island of cloud product events;
• Event-driven engine: massive event sources, millisecond level trigger ability, accelerate EDA/Serverless architecture upgrade;
• Openness and Integration: provide rich cross-product and cross-platform connectivity to facilitate the integration of cloud products, applications, and SaaS services.

Here’s an architectural and functional introduction to EventBridge:

Architecture level

For complex architectures, EventBridge provides industry-common Source, Buses, Rules, and Targets module management capabilities and supports both EventBus and EventStream modes, greatly reducing the difficulty of event-driven architectures.

1) Event bus model N: N model of classic EDA (event-driven) scenarios, providing core capabilities such as multi-event routing, event matching, and event transformation to help developers quickly build event-driven architecture.

2) Event flow model Standard Streaming (1:1) Streaming processing scenario, without the concept of bus, used for end-to-end data dump, data synchronization and data processing, etc., to help easily build cloud end-to-end data pipeline services.

Functional level

At the functional level, EventBridge’s core applications include:

1) Event rule driven

For event-based route distribution, EventBridge is driven by event rules, supports eight event modes and a four-fold converter to meet all the requirements of route distribution.

2) Event tracking

In case the event cannot be traced, exclusive event tracking ability, event analysis/query ability is provided. Improves the query and analysis capabilities of all-link events for users.

3) TRIGGER of DLQ/ retry mechanism and whole process of events

In view of poor reliability, DLQ/ retry mechanism is supported to trigger the whole process of events, which greatly ensures the event failure and delay caused by the user’s downstream system.

4) Schema registry

For complex event management, it supports the Schema registry, event information interpretation, preview, and upstream and downstream code generation capabilities, helping users complete the sending and receiving processing of events with low codes. Solve a series of event management problems such as difficulty in cross-department information communication and redundancy of business code.

5) At the same time, Based on the above functions, EventBridge supports more than 85 ali Cloud products and 847 event types.

You can visit EventBridge for more features

www.aliyun.com/product/ali…

Aliyun EventBridge more scenarios

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, driving application to application, and application to cloud.

Streaming ETL scenarios

Another core capability of EventBridge is its responsibility for streaming data pipelines, providing basic filtering and transformation capabilities for data synchronization/cross-geographical backup scenarios between different data warehouses, data processors, and data analysis and processing systems, connecting different systems and services.

Unified Event Notification service

EventBridge provides a wealth of cloud product event sources and event lifecycle management tools. You can directly monitor the data generated by cloud products through the bus and report it to monitoring, notification and other downstream services.

Blockbuster recommended

This article introduces the EventBridge bus and EDA architecture. If you want to learn more about the application scenarios, you can pay attention to the “Aliyun EventBridge Series Open Courses”. The full course is now available! This series of live lectures includes 5 topics, which will bring you an in-depth understanding of the core functions and applications of Aliyun EventBridge Event Bus.

The detailed arrangement of the later series is as follows. If you are interested, don’t miss it

The original link

This article is the original content of Aliyun and shall not be reproduced without permission.