The first exploration of "microservice architecture" in the microservice series

essay

Sometimes you have to be in awe of what you want.

Reference books:

1. "Phoenix Architecture"
2. "Microservice Architecture Design Patterns"

Before we understand the microservice architecture, we need to answer the two questions of "what is architecture" and "what is the style of architecture", and at the same time, we need to take the idea of ​​"architecture is not invented, but the result of continuous evolution" Think about software architecture.

What is Software Architecture?

The software architecture of a computer system is the set of structures required to build the system, including software elements, their relationships, and their attributes

• Bass 等注 < Documenting Software Architectures: Views and Beyond>

The above is the definition of software architecture by Les Bass and his colleagues from the Software Engineering Institute of Carnegie Mellon University. The above definition is so abstract that it will be difficult to understand. So how should we understand this sentence? Here are some personal insights into this definition:

The software architecture can be compared to the "blueprint" for a building in "civil engineering" (civil engineer: I didn't expect to cue me here, I really know how to be a crab!), this blueprint will describe the layout of the load-bearing structure in the building Situation, component type, size and construction method, and also describe how to combine and splice different structures of the building (concrete is the medium for their combination and splicing)

Personal statement: I don't know much about the civil engineering industry. The above opinions are summarized by consulting the literature. There are some places where the description is not correct, please forgive me!

According to our description of software architecture above, it is not difficult to conclude that "software architecture is to decompose software into elements and define the relationship between these elements". In a complete architectural "blueprint", according to its professional content or function, it will be divided into different modules to describe the corresponding content (such as structure, pipeline, electrical, etc.). The same is true for its corresponding "software architecture". Phillip Krutchen proposed a 4+1 view of software architecture in his classic paper (Architectural Blueprints——The 4+1View Model of Software Architecture).

What each view describes (quoted from the book "Design Patterns for Microservice Architecture"):

1. Logical View: The software elements created by developers. In object-oriented languages, these elements are classes and packages. The relationship between them is the relationship between classes and packages, including inheritance, association and dependency
2. Implementation View: Build the output of the compilation system. This view is composed of modules representing packaged code and components, which are executable or deployable units composed of one or more modules. In Java, modules are JAR files and components are usually WAR files or executable JAR files. The relationships between them include dependencies between modules and composition relationships between components and modules
3. Process View: Components at runtime. Each element is a process, and the relationship between processes represents interprocess communication
4. Deployment View: How processes are mapped to machines. Elements in this view consist of (physical or virtual) computers and processes. The relationship between machines represents the network. This view also describes the relationship between processes and machines
5. Scene view: It is a supplement to several other views, and is used to connect several other views in series through use case.

Although the earliest 4+1 view was proposed by Philippe Kruchten in 1995, the phrase "classic is always classic" is fully reflected in it. 4 +1 views are an excellent way to describe the architecture of your application. Each view describes an important aspect of the architecture (how to draw these views is a big challenge for every architect, and the difficulty of the challenge is directly proportional to the complexity of the system).

At this time, some small partners may have doubts, "I usually develop a complete system without drawing an architecture diagram", and bloggers think so before, but with the continuous accumulation of software architecture knowledge, there are also some questions about this issue. some different views. We divide a system from the level of requirements, which can include:

1. Functional requirements: These requirements determine what an application does. These are usually included in the use case (use case) or user story (user story) (such as payment, chargeback, etc.
2. Non-functional requirements: We also call this type of requirements quality attribute requirements, or simply "capability".

The architecture of the application has nothing to do with the functional requirements. We can use any architecture to achieve this requirement, and even you can customize the way you like to achieve it. But these non-functional requirements determine the runtime qualities of an application, such as scalability and reliability (design patterns). They also determine the quality of the development phase, including maintainability, testability, scalability, and deployability. The architecture chosen for the application will determine these quality attributes.

Hearing this, I have a deeper understanding of what is architecture and the importance of architecture. Let's take a look at what is the style of architecture.

architectural style

An architectural style determines the vocabulary of components and connectors that can be used in instances of that style, as well as a set of constraints on how they can be combined – Microservice Architecture Design Patterns

Still explaining the concept of "architectural style" through cue's good brother of "civil engineering", in the physical world, the construction of buildings usually follows a specific style, such as victorian, american craftsman or art deco, each style is a series of design decisions that limit the character and construction materials of the building. The concept of architectural style applies to software as well. Applications usually use a combination of multiple architectural styles. The "monolithic architecture" we talked about in the previous blog (building an application into a single executable and deployable group) is actually a software architectural style and "monolithic architectural style" Corresponding to the "microservice architectural style" (constructing the application as a group of services that can be loosely combined and independently deployed), these two architectural styles can be used in any view in the 4+1 view.

The monolithic architecture has been introduced in detail in the previous article, and the microservice architecture will be introduced in the following articles. Next, we will study other view instances in the 4+1 view in the application system: "MVC layered architecture style ", "Hexagonal Architecture Style"

layered architectural style

A layered architecture organizes software elements into "layers." Each layer has clearly defined responsibilities. A layered architecture also limits dependencies between layers. Each layer can only depend on the layer immediately below it (if strictly layered) or any layer below it.

We can apply the layered architecture to any of the four views discussed earlier. A popular three-tier architecture is a layered architecture applied to logical visual causes. It organizes the application's classes into the following layers:

1. Presentation layer: Contains the code that implements the user interface or external API
2. Business logic layer: Contains business logic.
3. Data persistence layer: implements the logic of interacting with the database.

This layered architectural style is the most commonly used architectural style in our daily development. The advantages of this architectural style are:

1. Simplified design: each department is specialized, and you don't have to live yourself as an all-rounder.
2. High reuse: For example, when designing a certain system, if a certain layer is found to be universal, it can be extracted and isolated for use in designing other systems.
3. Horizontal expansion: it can make it easier for us to do horizontal expansion. If the system is not layered, we need to expand the overall system when traffic increases. However, if we layer the system according to the three-tier architecture mentioned above, we can make detailed expansions for specific problems.

But this architectural style also has obvious disadvantages:

1. Single Presentation Layer: It fails to expose the fact that an application may not be invoked by only a single system.
2. Single Data Persistence Layer: It fails to represent the fact that the application may interact with multiple databases.
3. Define the business logic layer as dependent on the data persistence layer: In theory, such a dependency would prevent you from testing your business logic without a database.

Furthermore, layered architectures misrepresent dependencies in well-designed applications. Business logic typically defines an interface or library of interfaces for data access methods. The data persistence layer defines DAO classes that implement the repository interface. In other words, dependencies are the opposite of what a layered architecture describes.

hexagonal architecture

The layered architecture style has many disadvantages, and the hexagonal architecture style is an alternative to the layered architecture style that overcomes these disadvantages

The hexagonal architectural style chooses to organize logical views in a business logic-centric manner. Instead of a presentation layer, an application has one or more inbound adapters, which handle requests from the outside by invoking business logic. Also, instead of a data persistence layer, an application has one or more outbound adapters that are invoked by business logic and invoke external applications. A key feature and advantage of this architecture is that the business logic does not depend on the adapter. Instead, various adapters rely on business logic.

Business logic has one or more ports. A port defines a set of operations on how business logic interacts with the outside world. For example, in Java, a port is usually a Java interface. There are two kinds of ports: inbound and outbound. An inbound port is an API exposed by business logic that makes it callable by external applications. An instance of an inbound port is a service interface, which defines the public methods of the service. The outbound side is again how business logic calls external systems. An instance of an outbound port is the repository interface, which defines a collection of data access operations

Surrounding the business logic are adapters. Like ports, there are two types of adapters: inbound and outbound. Inbound adapters handle requests from the outside world by calling inbound ports. An instance of an inbound adapter is a Spring MvC Controller that implements a set of REST interfaces (endpoints) or a set of web pages. Another example is a message broker client subscribing to messages. Multiple inbound adapters can call the same inbound port.

Outbound adapters implement outbound ports and handle requests from business logic by calling external applications or services. An instance of an outbound adapter is an operational Data Access Object (DAO) class that implements access to a database. Another example is a proxy class that invokes remote services. Outbound adapters can also publish events.

The hexagonal architecture is a good way to describe the architecture of each service in a microservice architecture, its advantages:

1. An important benefit of the Hexagonal architectural style is that it separates the business logic from the logic of the presentation and data access layers contained in the adapters. Business logic does not depend on presentation layer logic or data access layer logic. Because of this separation, it is much easier to test business logic in isolation. Another benefit is that it more accurately
2. Reflects the architecture of modern applications. Business logic can be invoked through multiple adapters, each implementing a specific API or user interface. Business logic can also call multiple adapters, each calling a different external system.

The original intention of the hexagonal architecture is to solve the problem of decoupling technology and business systems, as well as the problem of decoupling between technology and technology. The implementation of standardized port protocols and adapters, and the completeness of self-service for business entities can be regarded as a theoretical basis for microservices.