Abstract: Layered architecture is simple and efficient, and there are many mature applications in the industry. It is very suitable for systems where the project is just starting and architects have not decided which architectural pattern to adopt.
preface
When software first appeared, in the days of mainframe computers, a software system typically ran on only one machine. As software and hardware technologies improved and computers became smaller in size and cost, engineers found bottlenecks when a software system ran on a single machine. If the system is divided into front-end and back-end according to functions and deployed on two servers respectively, the problem is alleviated, so there is the emergence of Client/Server**** architecture.
Later, the rise of the PERSONAL computer led to the emergence of many rich desktop applications, which are developed based on the user interface on the operating system, and their data is stored on a separately deployed Database server. Data communication through standard network protocols. The Desktop + Database Server architecture is a two-tier architecture like the C/S architecture.
With the rapid rise of the Internet in the 1990s, the combination of Browser + Web Server + Database Server became increasingly popular. Browser is the presentation layer, providing user interaction interface; Web Server is the business layer, handling the specific business logic; The Database Server is the data layer that stores system data. Each of the three layers has its own role, which is also known as three-tier architecture.
The above-mentioned architectural modes all belong to layered architecture. Layered architecture is not limited to the number of layers, and the number of layers can be flexibly controlled according to application scenarios. Therefore, it is also known as N-Tier Architecture. It is very popular in the industry because of its simple structure and low cost of system development based on this architecture (many companies are organized into front-end engineers, back-end engineers, and DBAs according to Conway’s law, which naturally has good conditions for hierarchical architecture development). If your team is not sure what architecture to choose, or just starts coding as stated in the Agile manifesto, layered architecture can be a good choice.
Architectural view
In a layered architecture, components are divided into different levels of functionality. Although there is no limit to the number or type of levels, most layered architectures consist of the following four levels: Presentation layer, Business layer, Persistence layer, and Database layer, as shown below. In some simple systems, the logic of the persistence layer (such as SQL) is embedded in the business layer, forming a classic three-tier architecture; In some complex systems, there may be five or more layers, depending on the specific business.
The standard logical layering of a layered architecture
The four layers mentioned above, including the presentation layer, are logical division methods. In actual deployment, there are generally several deployment modes as shown in the following figure. In Mode 1, the presentation layer, service layer, and persistence layer are deployed as one unit, while the data layer is deployed as an independent database or file system. In Mode 2, the presentation layer is deployed separately, the business layer and the persistence layer form a deployment unit, and the data layer remains a database or file system deployed separately. In Pattern 3, the four layers, including the data layer, are all in the same deployment unit and are common in simple systems that use embedded or in-memory databases.
Deployment mode of the layered architecture
Each layer in the layered architecture plays its own role, such as the presentation layer handling all user requests and browser interactions, while the business layer is responsible for executing the specific business logic under each request. The presentation layer doesn’t have to worry about where to get the user data, it just needs to display the data in a specific format on the browser. Similarly, the business layer doesn’t need to care where the user data comes from or how it is presented, it simply pulls the data out of the persistence layer, performs specific business logic (such as aggregate data), and returns the results to the presentation layer.
Each layer is an abstraction of a specific behavior, and this division of responsibilities allows organizations to quickly and efficiently create responsibility models and build development teams around each layer.
Isolation between the layers
Each layer in a layered architecture can be closed or open, and closed means that when a request is passed from top to bottom between layers, it cannot skip any layer. For example, when the presentation layer receives a request, it must pass through the business layer and then the persistence layer to reach the data layer, as shown in the figure below.
Closed layered architecture
For simple data acquisition class requests, it is undoubtedly the simplest and most efficient if the presentation layer can directly access the data layer to obtain data. This is to leave the business layer and persistence layer open, allowing requests to skip this layer as they pass between layers. So,
Is it better to be closed or open
? To answer this question, go back to the starting point of layer isolation.
Layer isolation is designed to reduce the impact of changes at one layer on components at the other layers, which in simple terms means that each layer knows as little about the functionality of the other layers as possible. To achieve isolation between layers, each layer needs to be placed in a closed state. Assuming that the presentation layer has direct access to the persistence layer, changes in the persistence layer will directly affect both the business layer and the presentation layer, increasing the coupling between the layers and making system changes costly.
Layer isolation can reduce the impact of layer changes on the system. Nothing is absolute, and in some scenarios, leaving certain layers **** open is a good thing. Consider the following example where there are shared components in the business layer that host functionality common to the business layer (such as logging classes, auditing classes, date and string utility classes, and so on). There is an architectural decision that the presentation layer cannot directly access these shared components, but paradoxically, the presentation layer can directly access the business layer in principle, and such a decision would be difficult to implement.
Shared components in the business layer
One solution is to add a new service layer that contains these shared components of the business layer. Because the business layer is closed, the presentation layer cannot access these shared components. However, the new service layer must be left open, otherwise the business layer will not be able to directly access the persistence layer. A new service layer is juxtaposed to an open state, which allows architecture decisions to be made without compromising existing functionality, killing two birds with one stone.
Add a new layer to the hierarchical architecture
Some considerations
When using a layered architecture, note the following:
1* * * *Do a good job of module division
Module partitioning for layered architecture is mainly to prepare for subsequent architecture evolution. For example, when a business is complex enough to evolve into a microservice architecture, each module can naturally evolve into a microservice architecture. To do this, you should avoid classes that have too deep a hierarchy of inheritance, which can lead to too much coupling in the code and hinder subsequent architectural evolution.
2* * * *Avoid the sinkhole anti-pattern trap
The Sinkhole **** anti-pattern refers to a request that simply passes through the layers without doing any business processing.
For example, the presentation layer receives a request for basic user data (name, address, etc.) and passes it to the business layer. However, the business layer does no business processing and passes requests directly to the persistence layer; The persistence layer only constructs a simple SQL statement to query user data from the data layer. Finally, the data is returned to the presentation layer in the original way, without any data aggregation, transformation and other operations.
The Sinkhole **** anti-pattern causes a lot of unnecessary object instantiation overhead, which increases the memory consumption of the system and affects performance.
However, every system will have some kind of Sinkhole anti-pattern scenario, and it is the percentage of such business requests that determines whether a system has fallen completely into the sinkhole anti-pattern. According to the 20-80 rule, when more than 80% of the business requests in the system are Sinkhole type requests, the system has fallen into the trap of Sinkhole anti-pattern, which also indicates that the system is no longer suitable for hierarchical architecture, and it is time to consider architecture evolution.
Composite scores
Composite score for layered architecture
In terms of Overall scores, the Overall cost and Simplicity of layered architectures score highly, which is largely due to the fact that layered architectures are single architectures and reduce the complexity of distributed systems. But this results in a low Deployability score, as a change in three lines of code can cause an entire system to be redeployed. This is also why Testability doesn’t score well, as bringing the entire system back online often requires the entire test case to be executed, adding a lot of extra work.
Elasticity, Fault tolerance, and Scalability are all natural weaknesses of individual architectures; naturally, hierarchical architectures score poorly in all of these areas. In addition, the existence of the Sinkhole anti-pattern also drags down the Performance score of layered architectures.
conclusion
Layered architecture is simple and efficient, and there are many mature applications in the industry, which is suitable for systems where the project is just getting started and architects have not yet decided which architectural pattern to adopt. When implementing a layered architecture, we need to properly set up the closed or open state of each layer to isolate the layers and avoid falling into the Sinkhole anti-pattern trap. With the continuous expansion of business, the shortcomings of layered architecture in maintainability, testability, scalability and other aspects will be gradually amplified. At this time, it is necessary to consider the evolution of other architecture modes.
Click to follow, the first time to learn about Huawei cloud fresh technology ~