Several software architecture patterns that programmers must know

prologue

Architecture pattern is a general reusable solution to common problems in software architecture in a given context.

A pattern is a solution to a problem in a specific context.

However, many developers are still confused about the differences between various software architecture models, or even know very little about them.

In general, there are mainly the following architecture modes:

  • Layered architecture

  • Pipeline-filter architecture

  • Client-server architecture

  • Model-View-Controller Architecture

  • Event-driven architecture

  • Microservice architecture

Several software architecture patterns that programmers must know

Layered architecture model

The most common architecture pattern is the layered architecture or n-tier architecture.

Most software architects, designers and developers are very familiar with this architectural pattern. Although there are no specific restrictions on the number and types of layers, most layered architectures are mainly composed of four layers: presentation layer, business layer, persistence layer, and database layer, as shown in the following figure.

A very popular example of n-tier architecture

A very popular example of n-tier architecture

Context
All complex systems experience the need to develop and evolve each part of the system independently. For this reason, system developers need to have a clear and coherent separation of concerns so that the various modules of the system can be independently developed and maintained.

Problem The
software needs to be divided in such a way: each module can be developed and derived independently, the interaction between the respective parts is very small, and it supports portability, modifiability and reusability.

Solution
In order to achieve separation of concerns, the layered model divides the software into individual units (called "layers"). Each layer is a set of modules, providing a set of highly cohesive services. Its use must be one-way. The layer treats a group of software as a complete partition, and each partition exposes a public interface.

  • The first concept is that each layer has specific roles and responsibilities. For example, the presentation layer is responsible for handling all user interfaces. This separation of concerns of the layered architecture makes it very simple to build efficient roles and responsibilities.
  • The second concept is that the layered architecture model is a technical partition architecture, rather than a domain-based partition architecture. They are composed of components, not domains.
  • The last concept is that each layer in the layered architecture is marked as closed or open. A closed layer means that a request moves from one layer to another, and it must pass through the layer directly below it to reach the next layer below it. The request cannot skip any layers.

Insert picture description here

Closed layer and request access

Weakness
Layering can cause performance degradation. This model is not suitable for high-performance applications, because the efficiency of implementing a business request through multiple layers in the architecture is not high.

Layering will also increase the upfront cost and complexity of the system.

Usage
We should apply this method to small and simple applications or websites. This is a good choice for scenarios where budget and time are very tight.

Multi-layer mode

Program
Insert picture description here

An example of a multi-layer pattern: consumer website J2EE

The execution structure of many systems is organized into a series of logical groupings. Each group is called a layer.

Context
In a distributed deployment, it is usually necessary to divide the system infrastructure into different subsets.

Question
How do we partition the system into multiple computationally independent execution structures: software and hardware groups connected by some communication media?

Weaknesses A
lot of upfront cost and complexity.

Purpose
Used in distributed systems.

Pipeline-filter architecture

A recurring pattern in software architecture is the pipe-filter pattern.
Insert picture description here

Pipe filter mode

Context

Many systems need to convert discrete data streams from input to output. Many type conversions are repeated in practice, so it is ideal to create them as independent reusable parts.

problem

These systems need to be divided into reusable loosely coupled components, with simple and common interaction mechanisms between components. In this way they can be flexibly combined with each other. These general loosely coupled components are easy to reuse. Those independent components can be executed in parallel.

Program

The pipes in this architecture constitute the communication channel between the filters. The first concept is that for performance reasons, each pipeline is non-directional and point-to-point, accepting input from one source and often directly outputting to another source.

In this mode, there are the following four filters.

producer(source):一个过程的起点。
transformer (map):对一些或所有数据进行转换。
tester (reduce):测试一个或多个条件。
consumer (sink):终点。

weakness

Not suitable for interactive systems because of their conversion characteristics.

Excessive parsing and de-analysis will lead to performance loss and increase the complexity of writing the filter itself.

use

Pipeline-filter architecture is used in various applications, especially to simplify single processing tasks, such as EDI, ETL tools.

Compiler: Continuous filters perform lexical analysis, syntax analysis, semantic analysis, and code generation.

Client-server architecture

Insert picture description hereContext

There are many shared resources and services that a large number of distributed clients want to access, and we want to control access or service quality.

problem

By managing a set of shared resources and services, we can improve modifiability and reusability by decomposing common services and modifying them in a single location or a few locations. We want to increase scalability and availability by centrally controlling these resources and services while distributing the resources themselves on multiple physical servers.

Program

In the client-server model, components and connectors have specific behaviors.

The component called "client" sends the request to the component called "server" and then waits for a reply.
The server component receives the client's request and sends a reply to it.

weakness

The server becomes a performance bottleneck and a single point of failure location.

After the system is built, the decision about the functional location (on the client side or on the server) is usually complex and costly to change.

use

For a system that has many components (clients) sending requests to other service-providing components (servers), we can use the client-server model to model part of the system: online applications, such as e-mail, shared documents, or Banking services.

Model-View-Controller Architecture (MVC)

Insert picture description here
Context

The user interface is usually the most frequently modified part of an interactive application. Users usually want to view data from different perspectives, such as bar charts or pie charts. These representations should reflect the current state of the data.

problem

How can user interface functions be independent of application functions, while still responding to user input or changes to underlying application data?

How to create, maintain, and coordinate multiple views of the user interface when the underlying application data changes?

Program

The model-view-controller (MVC) pattern divides application functions into the following three types of components:

模型,包含应用程序的数据。
视图,显示部分底层数据并与用户交互。
控制器,在模型和视图之间进行中介并管理状态更改的通知。

weakness

For simple user interfaces, the complexity is not worth it.

The model, view, and controller abstractions may not be applicable to some user interface toolkits.

use

MVC is an architecture pattern commonly used in the development of user interfaces for websites or mobile applications.

Event-driven architecture

Context

It is necessary to provide computing and information resources to process independent asynchronous events generated by incoming applications. This approach can be expanded as demand increases.

problem

Build a distributed system that can serve information about events that arrive asynchronously, and can scale from simple and small to complex and large.

Solution
Insert picture description here
Deploy an independent event process or handler for event processing. The arriving event enters the queue. The scheduler pulls events from the queue according to the scheduling strategy and assigns them to the appropriate event handlers.

weakness

Performance and error recovery may be the problem.

use

The e-commerce application using this solution will work as follows:

The Order Service creates an Order, which is in a pending state, and then publishes an OrderCreated event.

  • Customer Service receives this event and tries to deduct credit for this Order. Then issue a Credit Reserved event or CreditLimitExceeded (credit limit exceeded) event.
  • The Order Service receives the event sent by the Customer Service and changes the order status to approved or cancelled.

Microservice architecture

Context

Deploy server-based enterprise applications to support various browsers and native mobile clients. The application processes client requests by executing business logic, accessing databases, exchanging information with other systems, and returning responses. This application may expose a third-party API.

problem

Integrated applications will become too large and complex to be effectively supported and deployed to achieve optimal use of distributed resources, such as in a cloud environment.

Program
Insert picture description herewill build into the application suite of services. Each service is independently deployed and extensible, with its own API boundary. Different services can be written in different programming languages, manage their own databases, and developed by different teams.

weakness

The system design must be able to tolerate service failures and requires more system monitoring. Service orchestration and event collaboration are expensive.

Of course, we still need more money.

use

Microservice architecture can be applied to many usage scenarios, especially those involving large data pipelines. For example, a microservice system would be ideal for a reporting system about a company’s retail store sales. Each step of the data presentation process will be processed by a microservice: data collection, cleaning, standardization, enrichment, aggregation, reporting, etc.

Guess you like

Origin blog.csdn.net/silentwolfyh/article/details/109309498