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

This article focuses on "what are the software architecture patterns that programmers must know". Interested friends might as well take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn what software architecture patterns programmers must know.

I. hierarchical architecture model

The most common architectural pattern is a hierarchical architecture, or n-tier architecture.

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

Picture an example of a popular n-tier architecture

1 context

All complex systems experience the need to develop and evolve parts of the system independently. For this reason, system developers need to separate their concerns clearly and clearly, so that each module of the system can be developed and maintained independently.

2 problem

The software needs to be segmented in such a way that each module can be developed and evolved independently, with very little interaction between its parts, supporting portability, modification and reusability.

3 schemes

In order to achieve separation of concerns, the hierarchical model divides the software into units (called "layers"). Each layer is a set of modules that provide a set of highly cohesive services. Its use must be one-way. The layer treats a set of software as a complete partition, with each partition exposing 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 in a hierarchical architecture makes it easy to build efficient roles and responsibilities.

The second concept is that the hierarchical architecture model is a technical partition architecture, not a territorial partition architecture. They are made up of components, not domains.

The final concept is that each layer in a hierarchical architecture is marked as closed or open. A closed layer means that a request is moved from one layer to another, and it must pass through the layer directly below it to reach the next layer below. The request cannot skip any layer.

Picture closure layer and request access

4 weaknesses

Layering can lead to performance degradation. This pattern is not suitable for high-performance applications because it is not efficient to implement a business request through multiple layers in the architecture.

Layering also increases the upfront cost and complexity of the system.

5 uses

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

Second, multi-tier model

1 plan

Picture an example of a multi-tier model: consumer website J2EE

The executive structures of many systems are organized into a series of logical components grouped. Each packet is called a layer.

1 context

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

2 problem

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

3 weaknesses

A lot of upfront costs and complexity.

4 uses

Used in distributed systems.

III. Pipeline-filter architecture

A recurring pattern in software architecture is the pipe-filter (pipe-filter) pattern.

Picture pipe filter mode

1 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 separate reusable parts.

2 problem

These systems need to be divided into reusable loosely coupled components, which have a simple and general interaction mechanism. So that they can be flexibly combined with each other. These general loosely coupled components can be easily reused. Those independent components can be executed in parallel.

3 schemes

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

In this mode, there are four kinds of filters.

Producer (source): the starting point of a process.

Transformer (map): converts some or all of the data.

Tester (reduce): tests one or more conditions.

Consumer (sink): end point.

4 weaknesses

It is not suitable for interactive systems because of their conversion characteristics.

Too much parsing and anti-parsing can lead to performance losses and increase the complexity of writing the filter itself.

5 uses

The pipeline-filter architecture is used in a variety of applications, especially tasks that simplify individual processing, such as EDI, ETL tools.

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

IV. Client-filter architecture

1 context

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

2 problem

By managing a set of shared resources and services, we can improve modifiability and reusability by decomposing public services and making modifications in a single location or a few locations. We want to improve scalability and availability by centrally controlling resources and services while distributing resources themselves across multiple physical servers.

3 schemes

In client-server mode, components and connectors have specific behavior.

A component called a client sends a request to a component called a server and waits for a reply.

The server component receives the request from the client and sends a reply to it.

4 weaknesses

The server can become a performance bottleneck and a single point of failure.

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

5 uses

For systems with many components (clients) sending requests to other components (servers) that provide services, 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)

1 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.

2 problem

How can user interface functionality be independent of application functionality while also responding to changes in user input or underlying application data?

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

3 schemes

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

Model, which contains the data for the application.

View that displays part of the underlying data and interacts with the user.

The controller mediates between the model and the view and manages notification of state changes.

4 weaknesses

The complexity of a simple user interface is not worth it.

Model, view, and controller abstractions may not apply to some user interface toolkits.

5 uses

MVC is a common architectural model for the development of user interfaces for websites or mobile applications.

VI. Event-driven architecture

1 context

Computing and information resources need to be provided to handle independent asynchronous events generated by incoming applications, which can be extended as requirements increase.

2 problem

Build a distributed system that can serve event-related information that arrives asynchronously and can scale from simple small to complex large.

3 schemes

Deploy a separate event process or handler for event handling. Arriving events enter the queue. The scheduler pulls events from the queue according to the scheduling policy and assigns them to the appropriate event handler.

4 weaknesses

Performance and error recovery can be problems.

5 uses

E-commerce applications that use this solution will work as follows:

Order Service creates an Order, the order is pending, and then issues an OrderCreated event.

Customer Service receives the event and attempts to deduct credit for the Order. Then issue a Credit Reserved event or a CreditLimitExceeded (credit limit exceeded) event.

Order Service receives the event sent by Customer Service and changes the order status to approved or cancelled.

7. Micro-service architecture

1 context

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

2 problem

Integrated applications can become too large and complex to be effectively supported and deployed to achieve optimal distributed resource utilization, such as in a cloud environment.

3 schemes

Build the application into a service suite. Each service is independently deployed and extensible, with its own API boundaries. Different services can be written in different programming languages, manage their own databases, and be developed by different teams.

4 weaknesses

System design must be able to tolerate service failures and require more system monitoring. Service choreography and event collaboration are expensive.

Of course, we need more money.

5 uses

Microservices architecture can be applied in many usage scenarios, especially those that involve a large number of data pipelines. For example, a micro-service system would be ideal for reporting a company's retail sales. Each step of the data presentation process is processed by a microservice: data collection, cleaning, normalization, concentration, aggregation, reporting, etc.

At this point, I believe you have a deeper understanding of the software architecture patterns that programmers must know. You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.