Introduction to software architecture - layered architecture, event-driven, microservice architecture and cloud-native architecture

Software architecture (software architecture) is the basic structure of software.

Proper architecture is one of the most important factors for software success. Large software companies usually have a dedicated architect position (architect), which only senior programmers can hold.

O'Reilly has published a free booklet "Software Architecture Patterns" (PDF), which introduces the five most common software architectures and is a very good primer.

Software architecture is the basic structure of software. The essence of architecture is to manage complexity . If you don't think architecture is important, maybe what you're doing isn't complex enough, or maybe you haven't managed complexity well. Although there are many architectural patterns, after abstract precipitation, there are only a few:

1. Layered architecture

The most common software architecture, and the de facto standard architecture. If you don't know what architecture to use, use it.
This architecture divides the software into several horizontal layers, each layer has a clear role and division of labor, and does not need to know the details of other layers. Layers communicate with each other through interfaces.

Although there is no clear agreement on how many layers the software must be divided into, the four-layer structure is the most common.

• Presentation: user interface, responsible for visual and user interaction
• Business layer (business): implement business logic
• Persistence layer (persistence): Provide data, and SQL statements are placed in this layer
• Database (database): save data
  Some software adds a service layer (service) between the logic layer (business) and the persistence layer (persistence), providing some common interfaces required by different business logic.

The user's request willThrough the processing of these four layers in turn, any layer cannot be skipped。

advantage

• Simple structure, easy to understand and develop
• Programmers with different skills can divide the work and be responsible for different layers, which is naturally suitable for the organizational structure of most software companies
• Each layer can be tested independently, and the interfaces of other layers are solved by simulation

shortcoming

• Once the environment changes, it is usually cumbersome and time-consuming to adjust the code or add functions
• Deployment is more troublesome. Even if only a small place is modified, the entire software often needs to be redeployed, and it is not easy to do continuous release (because it is a single architecture)
• When software is upgraded, the entire service may be suspended
• Poor scalability. When a large number of user requests increase, each layer must be expanded in turn. Since each layer is internally coupled, expansion will be difficult (single architecture, demand adjustment will run through each layer)

2. Event-driven architecture

Generally applicable to local application scenarios, not suitable for top-level architecture, used to achieve asynchronous decoupling, almost all over the corners of communication software.
An event is a notification sent by software when the state changes.

Event-driven architecture has four core components:

• Event queue (event queue): the entry to receive events
• Distributor (event mediator): Distribute different events to different business logic units
• Event channel (event channel): the communication channel between the dispatcher and the processor
• Event processor (event processor): implements business logic, and will send an event after the processing is completed to trigger the next operation;

For simple projects, event queues, distributors, and event channels can be integrated into one, and the entire software can be divided intoevent proxyandevent handlertwo parts.

advantage

• Distributed asynchronous architecture, highly decoupled event processors, good software scalability
• Wide applicability, all types of projects can be used
• Better performance, because of the asynchronous nature of events, the software is not prone to blockage
• Event handlers can be loaded and unloaded independently, easy to deploy

shortcoming

• Asynchronous programming is involved (remote communication, loss of response, etc. must be considered), and the development is relatively complicated
• It is difficult to support atomic operations, because multiple processors are involved in the passage of events, and it is difficult to roll back
• The distributed and asynchronous nature makes this architecture difficult to test

3. Microkernel architecture

Also known as "plug-in architecture", it means that the core of the software is relatively small, and the main functions and business logic are realized through plug-ins. The currently popular service-oriented architecture solves the problems faced by a single architecture and is suitable for agile development and rapid iteration. It is generally used for tool software development, such as Eclipse, and is not suitable for distributed business scenarios.
The kernel (core) usually contains only the minimum functions required for the system to run. Plug-ins are independent of each other, and the communication between plug-ins should be reduced to a minimum to avoid interdependence problems.

advantage

• Good functional extensibility (extensibility), what functions are needed, just develop a plug-in
• Functions are isolated, and plugins can be loaded and unloaded independently, making it easier to deploy,
• Highly customizable to suit different development needs
• Can be developed incrementally, gradually adding functionality

shortcoming

• Scalability is poor, the kernel is usually an independent unit, and it is not easy to make it distributed
• The development difficulty is relatively high, because it involves the communication between the plug-in and the kernel, as well as the internal plug-in registration mechanism

The design and development of the microkernel architecture is relatively difficult, which means that it is not used much in enterprise products, although it has many advantages.

4. Microservices Architecture

The microservices architecture (microservices architecture) is an upgrade of the service-oriented architecture (SOA).

Each service is an independent deployment unit (separately deployed unit). These units are distributed, decoupled from each other, and communicated through remote communication protocols (such as REST, SOAP).

The microservice architecture is divided into three implementation modes.

• RESTful API mode: services are provided through APIs, and cloud services fall into this category;
• RESTful application mode: services are provided through traditional network protocols or application protocols, behind which is usually a multifunctional application, which is common in enterprises;
• Centralized message mode: message broker is used to implement message queue, load balancing, unified log and exception handling. The disadvantage is that there will be a single point of failure, and the message broker may be clustered;

Now there are many open source microservice frameworks, such as Spring Cloud, Dubbo, ServiceComb and so on.

advantage

• Good scalability and low coupling between services
• Easy to deploy, the software is split from a single deployable unit into multiple services, and each service is a deployable unit
• Easy to develop, each component can be developed with continuous integration, can be deployed in real time, and can be upgraded without interruption
• Easy to test, each service can be tested individually

shortcoming

• Due to the emphasis on mutual independence and low coupling, services may be split very finely. This leads to a system that relies on a large number of microservices, becomes messy and cumbersome, and performs poorly.
• Once services need to communicate (that is, one service needs to use another service), the entire architecture will become complicated. A typical example is some common Utility classes. One solution is to copy them to each service, exchanging redundancy for simplicity of the architecture.
• The distributed nature makes it difficult for this architecture to achieve atomic operations, and transaction rollback will be difficult.

5. Cloud Architecture (Cloud Native-Cloud Native)

The current saying is cloud-native architecture-Cloud Native, based on Docker, Kubernetes, and Service Mesh cloud-native architecture, which mainly solves the problems of scalability and concurrency, and is the easiest to expand architecture.

The main reason for its high scalability is that it can be elastically scaled based on computing resources on the cloud. Then, business processing capabilities are encapsulated into processing units. When the number of visits increases, a new processing unit (Docker container) is created; when the number of visits decreases, the processing unit (Docker container) is closed. Since there is no central database, the biggest bottleneck of scalability disappears. Since the data of each processing unit is independently divided into databases.

This pattern is mainly divided into two parts: processing unit (processing unit) and virtualized middleware (virtualized middleware).

• Processing unit: implement business logic (similar to microservices in microservice architecture)
• Virtual middleware: Responsible for communication, maintaining sessions, data replication, distributed processing, and deployment of processing units.

Virtual middleware consists of four components :

• Messaging Grid: manage user requests and sessions, and decide which processing unit to assign to when a request comes in;
• Data middleware (Data Grid): copy data to each processing unit, that is, data synchronization. Ensure that a processing unit gets the same data;
• Processing middleware (Processing Grid): optional, if a request involves different types of processing units, the middleware is responsible for coordinating the processing units;
• Deployment Manager: Responsible for starting and shutting down the processing unit, monitoring the load and response time, when the load increases, the processing unit is restarted, and when the load decreases, the processing unit is shut down.

With the rapid development of containerization technologies such as Docker and Kubernetes, the above description of cloud architecture is a bit outdated. The latest cloud-native architecture is currently centered on Docker+Kubernetes, especially container orchestration Kubernetes has become the de facto industry standard.

Key features of a cloud-native architecture diagram :

• Microservice application running support environment;
• Use containerized application mirroring as the delivery standard;
• Quickly apply for and release resources through resource scheduling services;
• Rapidly expand applications through elastic scaling;
• status monitoring;

main target:

1. Let developers focus on the implementation of business logic, and leave the rest to the container cloud platform to complete;

2. Support the rapid iteration of the business system, and support the rapid change and development of the business;

3. Build a business middle platform with a shared service system as the core;

The following is a cloud-native architecture diagram designed for a new retail enterprise. Cloud-native applications are built on the basis of cloud and micro-service architecture. The cloud here can be public cloud, private cloud, hybrid cloud, etc.

The above is a classification of the architecture from different perspectives. In practical applications, various architectures are not isolated, and various architectures can be synthesized and grafted according to the business environment and business demands. Each architecture has its advantages and disadvantages. Needless to say the advantages, the disadvantages are almost all avoided through the ability of tool engineering (such as automated release tools, automated testing, etc.), tool engineering is very important to software architecture.