Shulou(Shulou.com)05/31 Report--

This article mainly introduces "what are the server software architecture patterns". In the daily operation, I believe many people have doubts about the server software architecture patterns. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts about "what are the server software architecture patterns?" Next, please follow the editor to study!

Singleton (singleton mode), warehousing mode (repository), factory mode (factory), builder mode (builder), decoration mode (decorator). Probably every programmer who listens in class is no stranger-the design pattern of the software provides us with reliable solutions to existing and recurring problems.

There is also a similar mechanism in software architecture, common and reusable solutions that often arise in software architecture in a given context. Different software architecture models have their own advantages. Here are five mainstream software architecture models.

Hierarchical mode (Layered Pattern)

The hierarchical pattern is probably one of the best-known software architecture patterns, which is used by a large number of developers but does not know its name. The hierarchical mode divides the code into "layers", each of which has some responsibility and serves the higher "layers".

The tiering model does not specify the number of layers, but it usually has the following structure:

Presentation layer / UI layer

Application layer

Business / domain (domain) layer

Persistence / data access layer

Database layer

The idea of hierarchical mode is that the user starts a piece of code at the presentation layer by performing certain actions (such as clicking a button). Then, the presentation layer invokes the application layer, enters the business layer, and finally the persistence layer stores all the content in the database. To put it simply, the high level in the hierarchical pattern invokes and relies on the lower layer.

Depending on the complexity of the application, we will see many corresponding variants. For example, some applications will omit the application layer, while some applications will add a cache layer, or even the integration of the two layers.

Layer responsibility

As mentioned above, each layer has its own responsibility. The presentation layer contains the graphic design of the application and the code that handles the interaction. Theoretically, we should not add any logic that has nothing to do with user interface at this level.

The business tier is where specific business problem models and logic are placed.

The application layer lies between the business layer and the presentation layer. On the one hand, it provides business layer abstraction for the presentation layer, and on the other hand, it provides some coordination logic for the application layer that is not suitable to be placed in the business layer or presentation layer.

The persistence layer contains the code that accesses the database layer, which is the underlying database technology, such as SQL Server, MongoDB. The persistence layer is the set of code used to manipulate the database: SQL statements, connection details, and so on.

advantage

Most developers are familiar with it.

A simple method for writing well-organized and testable applications

Inferior position

Hierarchical models often lead to "integration" of applications and make it difficult to split.

Developers often find themselves writing a lot of code to pass different layers without adding any values to those layers. If all we do is write a simple CRUD application, the hierarchical model may go a little too far.

Applicable to

Standard line of business (line-of-business) applications that are not only used to complete CRUD operations

Microkernel mode (Microkernel)

Microkernel mode (or plug-in mode) is useful when an application has a set of core responsibilities and a set of interchangeable parts. The microkernel will provide the entry point and general flow of the application without really understanding what the different plug-ins are doing.

For example, task scheduling, the microkernel can contain all the scheduling and trigger logic, while the plug-in is responsible for specific tasks. As long as plug-ins follow a specific API, the microkernel can start with them without knowing the details of the implementation.

Another example is workflow. The implementation of workflow includes concepts such as the order of different steps, evaluating the results of steps, and determining the content of the next step. The specific implementation of the steps is not important to the core code of the workflow.

advantage

Flexibility & scalability

Some implementations allow us to add plug-ins when the application is running

Microkernels and plug-ins can be developed by different teams

Inferior position

It is difficult to determine what belongs to the microkernel

Predefined API may not be suitable for future plug-ins

Applicable to

Applications that obtain data from different sources, convert data, and write it to different places

Workflow application

Task and job scheduling application

Command responsibility query Separation Mode (CQRS)

CQRS is the abbreviation of Command and Query Responsibility Segregation. The core concept of this pattern is that the application has completely separate read and write operations, which also means that the model used for write operations (commands) is different from read (query). In addition, the data will be stored in different locations. In a relational database, it means that there will be tables for command models and tables for reading models. Some implementations even store different models in completely different databases, such as SQL Server for command models and MongoDB for reading models.

The CQRS pattern is usually combined with event traceability (Event Sourcing), which is discussed in the next section.

How does CQRS work? When the user performs an action, the application sends a command to the command server. The command service retrieves any data needed from the command database, performs the necessary operations and stores it back into the database, and then notifies the reading service to update the read model. As follows:

When the application needs to display data to the user, it can retrieve the read model by calling the read service, as shown below:

advantage

The command model focuses on business logic and verification, and the reading model is customized according to the specific situation.

Can avoid complex queries and make reading more efficient

Inferior position

Keeping commands and reading models in sync can complicate things.

Applicable to

Applications that require a lot of reads

Applications with complex domains

Event traceability mode (Event Sourcing)

This mode does not store the current state of the model in the database, but instead stores time in it. So, for example, when customer name changes, the value is not stored in the "name" column, we store a "NameChanged" event.

When we need to retrieve the model, we will retrieve all its stored events and reapply them on the new object, that is, rehydrating an object.

It is easier to understand event sourcing with EXCEL bookkeeping. When we add expenses, we do not need to change the total value, but add a "row", an error occurs, and also add a "row". Finally, we use EXCEL's formula to automatically calculate the total, and here the total can be seen as a read model.

You can see that we made an error while adding Invoice 201805. Instead of changing the line, we added two new lines, first one to cancel the wrong line, and then the new correct line. This is how event sourcing works. You never delete events because they undeniably happened in the past. To correct the situation, we added a new event.

In addition, notice how we get the total value, which is the sum of all the values in the cells above. In Excel, it is automatically updated, so we can say that it is synchronized with other cells. This is a read model.

Event sourcing is usually used in conjunction with CQRS because rehydrating an object can have an impact on performance, especially if there are a large number of events in the instance. Fast reading the model can significantly improve the response time of the application.

advantage

Provides "out-of-the-box" audit log, where each event is a specific action at a specific point in time

Inferior position

Event sourcing has certain restrictions, and we can't fix the wrong data directly through simple editing in the database.

Changing the structure of events is complicated.

Applicable to

Applications that need to publish events to external systems

CQRS application

Applications with complex domains

Applications that require data modification of audit log

Micro-service mode (Microservices)

Writing a set of microservices is actually writing multiple applications that can collaborate. Each microservice has its own unique responsibility, and the team can develop them independently of other microservices. The only dependence between them is communication. When microservices communicate with each other, we must ensure that the messages sent between them remain backwards-compatible (backward compatible). This requires some coordination, especially when different teams are responsible for different microservices.

As shown in the following figure--

In the figure above, the application invokes a central API and forwards the call to the correct microservice. In this example, there are separate services for user profiles, inventory, orders, and payments. We can imagine that this is a user ordering application. Individual microservices can also be called to each other. For example, the payment service can notify the order service when the payment is successful. The order service can then invoke the inventory service to adjust the inventory.

There is no clear definition of how big the microservice is. In the previous example, the user profile service may be responsible for data such as the user's user name and password, home address, avatar, favorites, etc., or optionally divide all these responsibilities into smaller micro-services.

advantage

We can write, maintain and deploy micro services separately.

Micro-service architecture is easy to expand

Rewriting becomes easy because of the loose coupling between microservices

Inferior position

In fact, there is no suitable tool platform, but it is actually easier to write well-structured integrated applications and split them into micro-services at the beginning. Using microservices creates many additional problems: communication, coordination, backward compatibility, logging, and so on. It may be difficult for a team that does not have the necessary skills to write a well-structured overall structure to write a good set of microservices.

Traditional micro-service architecture may have multiple points of failure, and finding problems may be complicated.

Applicable to

Applications where some components are used intensively and need to be extended

Applications that provide functionality for other applications

Very complex applications under the integrated architecture

Can clearly define the application of bounded contexts

At this point, the study of "what are the server software architecture patterns" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.