Shulou(Shulou.com)06/03 Report--

If you see my article for the second time, please scan the code at the end of the article and subscribe to my personal official account (cross-border architect).

The length of this article is 3633 words. It is recommended to read for 10 minutes.

Insist on originality, each article is written by heart ~

If only our development work were really like building blocks, with clear contours and separate pieces, it would be nice to replace which building block was broken.

However, in fact, what we are faced with in our work may be only one building block, and it is still a large piece, which should be replaced together and repaired together.

Brother Z mentioned the hierarchical architecture mentioned in the previous "distributed system concern (13) -" High cohesion and low Coupling "detailed explanation". It allows us to consciously do some segmentation, but the difficulty of exchange and repair is determined by the granularity of the segmentation.

Is there a better way? This is obvious.

Event-driven architecture

Let's look at the problem in a different way.

Whether it is a normal system upgrade, bug repair, or capacity expansion, it is actually an "operation". Through this "operation" to solve some of the current problems.

Then the hierarchical structure is like dividing a person's hands, feet, mouth and nose clearly, but the whole is still closely coupled.

How is it coupled? We are connected by the flow of blood. This is like connecting different nodes through the rpc framework in a distributed system.

But software is different from people, there are two different ways to connect, in addition to the "synchronous" way, there is also an "asynchronous" way. Because sometimes you don't need to know the execution results of other systems, just make sure you pass the data you need to it.

There happens to be an architecture that is typical of this pattern-event-driven architecture (EDA,Event Driven Architecture for short).

The common MQ, local message table and so on are used in the transit link of data transmission, which is the embodiment of the idea of event-driven architecture.

Event-driven architecture is subdivided into two typical implementation methods, which are similar to the two implementation methods of Saga pattern mentioned by Brother Z in "distributed system concern (3)-sibling transaction" of "consensus". One is centralized and the other is decentralized.

Here's an example of Brother Z to make you look a little easier to understand. (the example is only to illustrate how it works, and how to ensure data consistency needs to be considered in the real implementation. You can refer to the previously published series of articles with a portal at the end.)

In traditional e-commerce scenarios, users need to do at least a few things after clicking the submit button from the shopping cart: generate an order, generate a payment record, and match the order to the delivery company.

In this scenario, what's the difference between centralization and decentralization?

The model of centralization has a "God".

But "God" does not process or know any business logic, it only arranges events.

Apart from centralization, what are its characteristics? Brother Z defines it as a "three-dimensional 2 structure".

There are three types of subjects in this model: event producer, "God" (mediator), and event handler. Then there are two layers of queues in the middle, so that the structure can be decoupled.

Like this: event producer-- > queue-- > "God" (mediator)-- > queue-- > event handler.

So back to the above example, the event producer CartService issues an "order creation" event, which is passed to the mediator through the queue. Then the mediator converts the event according to the pre-established scheduling rules, and also makes a secondary distribution through the queue and passes it to the event handler.

You may ask, these are easy to understand. However, I have often seen what kind of choreography before, in the end how to do it?

In fact, choreography mainly does two things: "event transformation" and "event sending" (corresponding to the "invocation" of the "service orchestration" class framework).

The essence of "event conversion" is to assign values to the parameters of the event object to be sent. Where does the assigned data come from?

In addition to the parameters brought by the source of the event, there is a continuous accumulation of "context", such as a shared storage space in the figure below.

You may also ask, how can I combine multiple event handlers into a single context?

Through a globally unique identity, you can bring this globally unique identity to God every time you throw an event at God.

Digression: generally speaking, there will be an internal unique "sub-serial number" under a global unique identity, in order to cooperate with the "event sending" that we will talk about next.

First, for subsequent troubleshooting, it is clear which upstream system the exception generated by this call comes from.

The second is to observe whether the logic of the whole call is in line with the expectation of the orchestration.

How do I do that? Through a serial number in x.x.x.x format. For example, serial is 1pr 2pm 3. Branching and parallelism is 2.1 Magi 2.2. The combination of branch and serial is 1, 2, 2, 2, 1, 2, 2, 2, 3.

"event sending" is essentially responsible for the logical control of event flow, and then sent to the "event handler" to deal with. It determines whether to proceed sequentially or in branches? Is it serial or parallel?

At this point, we will no longer expand, or we will digress, and we will talk about this part in detail next time.

Again, "event conversion" and "event sending" are the two most basic functions you need to meet when implementing the "God" (mediator) function.

The biggest advantage of centralization is to make the process more "visible", but also easier to do some monitoring things, the larger the scale of the system, the more obvious the effect of this advantage.

However, the implementation of a basic "God" (mediator) still needs to consider the problem of data consistency, so it will greatly increase the complexity of its implementation.

Therefore, if you are facing a scenario where the business is not particularly large and stable, it may be a good choice to use a decentralized approach.

Decentralization

Since there is no "God" in this pattern, each event handler needs to know what his or her next event handler is? What parameters are required? And which queue is that sort of thing.

But the overall structure will become much simpler, from a "3percent 2 structure" to a "2percent 1 structure".

The complexity behind structural simplification goes to the business code written by the event handler developer. Because he needs to be responsible for "event conversion" and "event sending".

Well, after being transformed into an event-driven architecture, the system does run more smoothly through queue decoupling and asynchronous event flow.

But sometimes you may want to exercise more fine-grained control, because in general, a service will deal with many business links, and there will not be only one external interface and one business logic.

In such cases, most of the time you may need to modify only one of the interfaces. Can you modify only part of the code and make a "hot update"?

The microkernel architecture (plug-in architecture) is suitable to solve this problem.

Microkernel architecture

As the name implies, the key to the microkernel architecture is the kernel. So you need to find and figure out what the kernel is first. Then treat all other parts as "detachable" parts.

For example, if we are alone, the brain is the kernel, and everything else can be changed. After the change, you are still you, but if the brain is changed, it is not you.

The microkernel architecture consists of two parts: the core system and the plug-in module.

The core system also contains microkernels, plug-in modules, and built-in default functions that are also provided in the form of plug-ins.

Among them, the microkernel is mainly responsible for the life cycle management and control of the plug-in module.

The plug-in module is responsible for loading, replacing and unloading the plug-in.

If the external plug-in is to be able to access and run smoothly, there must be an implementation that meets the standard interface specification.

The standard interface of a plug-in will have at least two methods that require a specific plug-in to implement:

Public interface IPlugin {/ initialize the configuration / void InitializeConfig (Dictionary configs); / run / void Run ();.} finally, the plug-ins are independent of each other, but the core system knows where to find them and how to run them.

Best practic

Knowing these two "flexible" architecture models, how can you judge when you need to move out?

Brother Z takes you to analyze the advantages and disadvantages of each architecture, and you can find out the scenarios in which it is applicable.

Event-driven architecture

Its advantages are:

Through the "queue" decoupling, so that in the face of rapidly changing needs can be immediately online, without affecting the upstream system.

Because "event" is an independent "standardized" communication carrier, we can use this feature to link up a variety of cross-platform and multilingual programs. If you do additional persistence, it can also facilitate follow-up troubleshooting. At the same time, the "event" can be replayed repeatedly to conduct a more realistic stress test of the processor's throughput.

More "dynamic" and good fault tolerance. You can easily, cheaply integrate, reintegrate, reconfigure new and existing event handlers, and easily remove event handlers. Easily expand and reduce capacity.

In the "God" mode, if you have a "visible" control of the business, it is easier to find problems that the process is unreasonable or ignored. At the same time, it can standardize some technical details, such as the implementation of "data consistency".

Its disadvantages are:

In the face of unstable network problems and various exceptions, it takes a lot of energy and cost to deal with these to ensure consistency than synchronous calls.

Unlike synchronous calls, when the operation is successful, you can see the latest data, and you need to tolerate delays or do some extra processing on the user experience.

So, the scenarios it applies to are:

Scenes that do not require high real-time performance.

There are a large number of cross-platform and multi-language heterogeneous environments in the system.

A scenario designed to maximize program reuse.

The business is flexible and changeable.

Scenarios that require frequent capacity expansion and reduction.

Microkernel architecture

Its advantages are:

It provides convenience for progressive design and incremental development. You can first implement a solid core system, and then gradually add functions and features.

Like the event-driven architecture, it can also avoid the failure of a single component, resulting in the collapse of the whole system and good fault tolerance. The kernel only needs to restart this component without affecting other functions.

Its disadvantages are:

Because the main microkernel is very small, it is not possible to optimize the whole. Each plug-in is responsible for its own, and may even be maintained by a different team.

In general, the pattern of plug-ins nesting plug-ins is rarely enabled to avoid an explosion of complexity in a single application, so code reuse in plug-ins is less reusable.

So, the scenarios it applies to are:

Can be embedded or as part of other architectural patterns. For example, in the event-driven architecture, the "event transformation" of "God" can be implemented using the microkernel architecture.

The business logic is different, but the running logic is the same. For example, periodic tasks and job scheduling applications.

A scenario with a clear expectation of incremental development.

Summary

All right, let's sum up.

This time, Brother Z introduced to you the two implementation modes and ideas of "event-driven architecture", as well as the implementation of "micro-kernel architecture".

It also presents the advantages and disadvantages of the two architecture models and the best practices for scenario analysis.

I hope it will enlighten you.

Related articles:

The focus of distributed system (1)-- initial recognition of data consistency

Distributed system concerns (2)-- achieving data consistency through "consensus"

Distributed system concern (3)-- Brother "transaction" of "consensus"

Author: Zachary

Source: https://www.cnblogs.com/Zachary-Fan/p/flexiblearchitecture.html

If you like this article, you can click "thumb" in the lower left corner.

This will give me some feedback. :)

Thank you for your help.

▶ about the author: Zhang Fan (Zachary, personal WeChat account: Zachary-ZF). Persist in polishing each article with high quality and originality. Welcome to scan the QR code below.

Publish the original content regularly: architecture design, distributed system, product, operation, some thinking.

If you are a junior programmer, you want to promote but don't know how to do it. Or as a programmer for many years, I fell into some bottlenecks and wanted to broaden my horizons. Welcome to follow my official account "Cross-border architect", reply to "Technology" and send you a mind map that I have collected and sorted out for a long time.

If you are an operator, there is nothing you can do in the face of a changing market. Or you may want to understand the mainstream operation strategy in order to enrich your "warehouse". Welcome to follow my official account "Cross-border architect", reply to "Operation" and send you a mind map that I have collected and sorted out for a long time.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.