Learn Architecture from Scratch - Extensible Architecture Patterns

Basic ideas and patterns of scalable architecture patterns

The biggest difference between a software system and a hardware and building system is that software is scalable. A piece of hardware will not be changed after it is produced, and its overall structure will not be changed after a building is completed. For example, a CPU will be installed after it is produced
. To a PC, there is no going back to the factory for machining to add new features; the pyramid has stood for thousands of years and weathered, but its structure is the same now as it was when it was built.
In contrast, software systems are the complete opposite. A truly viable software system is constantly iterating and developing. A typical operating system such as Windows, from Windows 3.0 to Windows 95 to Windows XP, until now Windows 10, has been constantly developing with the development of technology. If a software system is developed without any updates and adjustments, it means that the software system has no development and no vitality.
This natural and inherent extensibility of software systems is both a charm and a difficulty.

• The charm is reflected in the fact that we can continuously make the software system have more functions and features through modification and expansion, to meet new needs or follow the trend of technological development.
• The difficulty lies in how to expand the system with the least cost, because in many cases, the whole body is involved, and when expanding, it may be necessary to change everywhere, and to overthrow everything and start over. The risk of doing so is self-evident: the more changes are made, the greater the investment, and the greater the possibility of errors.

Therefore, how to avoid too large a range of changes during expansion is the main consideration in the scalability design of software architecture.

The basic idea of ​​extensibility

There are many ways to design scalable architectures, but they remain the same. The basic idea behind all scalable architecture designs can be summed up in one word: demolition!
Demolition is to split the original unified system into multiple small-scale parts, and only modify a part of it when expanding, without changing the entire system everywhere. In this way, the scope of changes and the risk of changes can be reduced.
In the face of software systems, dismantling is not that simple, because we do not want to destroy a software system, but to make the software system more beautiful (with better scalability) through dismantling. To put it figuratively, "demolition" in a software system is constructive, so the difficulty is much higher.
Splitting the software system according to different ideas will result in different architectures. There are three common split ideas as follows:

• Process-oriented splitting: Split the entire business process into several stages, each stage as a part
• Service-oriented split: split the services provided by the system, each service as a part
• Function-oriented splitting: splitting the functions provided by the system, each function as a part

The key to understanding these three ideas lies in how to understand the connection and difference between "process", "service" and "function".
From the perspective of scope, the order from large to small is: process > service > function. It may be difficult to understand simply from the conceptual explanation, but in fact it is very clear after looking at a few cases. Take the
TCP/IP protocol stack as an example:

• Process
  Corresponds to the TCP/IP four-layer model, because the TCP/IP network communication process is: application layer → transport layer → network layer → physical + data link layer, no matter what the top application layer is, this process will not change.
• Services
  Corresponding to HTTP, FTP, SMTP and other services in the application layer, HTTP provides web services, FTP provides file services, SMTP provides mail services, and so on
• Functionality
  Each service provides a corresponding function. For example, HTTP service provides GET and POST functions, FTP provides upload and download functions, and SMTP provides mail sending and receiving functions.
  Taking a simple student information management system as an example, the split method is:

1. Process-oriented split
   presentation layer → business layer → data layer → storage layer, the meaning of each layer is:
   presentation layer : responsible for user page design, different businesses have different pages.
   For example, business layers such as login page, registration page, information management page, and security setting page : responsible for the processing of specific business logic.
   For example, business data layers such as login, registration, information management, and password modification : responsible for completing data access. For example, adding, deleting, modifying and querying data in the database, recording events to log files, etc.
   Storage layer : responsible for data storage. For example, the final architecture of relational database MySQL and caching system Memcache
   is as follows,
   

2. Service-oriented splitting
   Split the system into services such as registration, login, information management, security settings, etc. The final architecture diagram is as follows:
   

3. Function-oriented split
   Each service can be split into more registration services: provide multiple ways to register, including three functions: mobile phone number registration, ID card registration, and student mailbox registration.
   Login service : including mobile phone number login, ID card login, and email login.
   Information management service : including basic information management, course information management, achievement information management and other functions.
   Security setting service : including fine-grained functions such as changing passwords, securing mobile phones, retrieving passwords, etc., for example:
   

Through the case of the student information management system, it can be found that the structure diagrams are very different in different splitting methods. But it seems like either way, it's achievable in the end. That being the case, why should we bother to choose, just pick one at random?

Of course, you can't pick it randomly, otherwise the architecture design will be meaningless, and the architect will lose his job. The reason is that different splitting methods essentially determine how the system expands.

Scalable way

When we talk about scalability, many students will have a doubt: Even if the system is not split, as long as the design and code are done well, there will be no problem of changing everywhere? For example, in the case of service-oriented splitting, adding "student number registration" can control the scope of modification even if it is not split into services, so why do we have to spend a lot of time to split the system?
In an ideal environment, your team is full of experts, every programmer is very good and familiar with the business, and new colleagues will quickly know all the details... Then there is no problem if there is no split. But the reality is: there are rookie programmers in the team, whether to change A to realize the function or change B to realize the function depends entirely on what he thinks is easy to change; some programmers are careless; Great; new colleagues don't know why a certain line of code in history is so "disgusting", so they easily change it to be more beautiful... All these problems may appear, and you will find out at this time that a reasonable split , it can be enforced to ensure that even if the programmer makes mistakes, the scope of mistakes will not be too wide, and the impact will not be too great.
The following are the advantages of different splitting methods when dealing with expansion.

1. Process-oriented split
   In most cases, only one layer needs to be modified when expanding, and in a few cases, the associated two layers may be modified. It will not appear that all layers need to be modified at the same time
   - for example, the student information management system, if we expand the storage layer from MySQL In order to support MySQL and Oracle at the same time, only the storage layer and data layer need to be expanded, and the presentation layer and business layer do not need to be changed
2. Service-oriented splitting
   To expand a certain service, or to add a new service, you only need to expand related services without modifying all services.
   Also take the student management system as an example, if we need to add a " "Student Number Registration" function, you only need to modify the "Registration Service" and "Login Service", and the "Information Management Service" and "Security Settings" services do not need to be modified
3. Function-oriented splitting
   To expand a certain function, or to add new functions, you only need to expand the relevant functions without modifying all services.
   Also take the student management system as an example. If we add the "student number registration" function, then You only need to add a new functional module to the system and modify the "login function" module at the same time, and other functions will not be affected. Different
   split methods will result in different system architectures. Typical scalable system architectures include:

• Process-oriented splitting: layered architecture
• Service-oriented split: SOA, microservices
• Function-Oriented Splitting: Microkernel Architecture

Of course, these system architectures are not either-or, but can be used in combination in system architecture design. Taking the student management system as an example, we can finally design the architecture like this:
the overall system adopts the "micro-service" architecture in service-oriented splitting, and splits it into "registration service", "login service", "information management service" and "security service". Each service is a subsystem that runs independently.
The "registration service" subsystem itself adopts a layered architecture for process splitting.
The "login service" subsystem adopts the "microkernel" architecture oriented to function splitting.

Traditional Scalable Architecture Patterns: Layered Architecture and SOA

Compared with the rapid development of high-performance and high-availability architecture patterns in recent decades, the development of scalable architecture patterns can be said to be faltering. In recent years, the fiery microservice
model is one of the few in the history of the development of scalable models. This has also led to the fact
that when we talk about scalability, we must talk about microservices, and even the microservice architecture has become a silver bullet for architecture design. High performance also uses microservices, and high availability also uses microservices
. It looks tall, but it actually violates the "proper principle" and "simple principle" of architecture design.
In practice, it is better to design scalable architecture. Next, we will introduce several scalable architecture patterns and point out the advantages of each architecture pattern. Key points and pros and cons.

layered architecture

Layered architecture is a very common architectural pattern, it is also called N-tier architecture, usually, N is at least 2 layers. For example, C/S architecture, B/S architecture. The common ones are 3-layer architecture (for example, MVC, MVP architecture), 4-layer architecture, and 5-layer architecture are relatively rare. Generally, more complex systems can reach or exceed 5 layers, such as the operating system kernel architecture.
When designing according to the layered architecture, a variety of different layered architectures can be obtained according to different division dimensions and objects

• 
  The object of C/S architecture and B/S architecture is the entire business system, and the dimension of division is user interaction, that is, the part that interacts with users is separated into one layer, and the background that supports user interaction is another layer . For example, the following is a C/S architecture structure diagram
  

• The object of MVC architecture and MVP architecture
  is a single business subsystem, and the dimension of division is responsibility. Different responsibilities are divided into independent layers, but the dependencies of each layer are more flexible. For example, the layers in the MVC architecture interact in pairs:
  

• Logical layered architecture
  The object of division can be a single business subsystem or the entire business system, and the dimension of division is also the responsibility. Although they are all based on the division of responsibilities, the difference between the logical layered architecture and the MVC architecture and MVP architecture is that the layers in the logical layered architecture are dependent from top to bottom. Typical operating system kernel architecture and TCP/IP architecture. For example, the following is the Android operating system architecture diagram:
  
  The typical J2EE system architecture is also a logical layered architecture. The architecture diagram is as follows: The architecture
  
  diagram for logical layering of the entire business system is as follows:
  
  The core point is to ensure that the differences between layers are clear enough, and the boundaries are clear enough, so that people can understand the entire architecture after seeing the architecture diagram , which is why the layers cannot be divided into too many layers. Otherwise, if the difference between the two layers is not obvious, the programmer Xiao Ming thinks that a certain function should be placed in the A layer, but the programmer Lao Wang thinks that the same function should be placed in the B layer, which will lead to layering confusion. If such an architecture is put into actual development, then the A layer and the B layer will become a mess, and the meaning of layering will be lost.

The reason why the layered architecture can better support system expansion lies in the isolation of concerns (separation of concerns), that is, the components in each layer will only process the logic of this layer.
For example, the presentation layer only needs to process presentation logic, and the business layer only needs to process business logic, so that when we expand a certain layer, other layers will not be affected. In this way, the system can be rapidly expanded on a certain layer. For example, if you want to add a new file system to the Linux kernel, you only need to modify the file storage layer, and other kernel layers do not need to be changed.

Of course, simple layering is not enough to isolate concerns and support rapid expansion. When layering, it is necessary to ensure that the dependencies between layers are stable in order to truly support rapid expansion. For example, in order to support different file system formats, the Linux kernel abstracts the VFS file system interface. The architecture diagram is as follows. If there is

no VFS, file systems such as ext2, ext3, and reiser are simply divided into "file system layers", then this layer It does not achieve the purpose of supporting scalability. Because after adding a new file system, all file system-based functions must adapt to the new file system interface; with VFS, only VFS needs to adapt to the new file system interface, and other file system-based functions It is VFS and will not be affected.

Another feature of the layered structure is the layer-by-layer transfer, that is to say, once the layering is determined, the entire business process is transferred in sequence according to the layer, and it is not possible to jump between layers.

In the simplest C/S structure, the user must first use the C layer, and then the C layer is passed to the S layer, and the user cannot directly access the S layer. In the traditional J2EE 4-tier architecture, after receiving the request, the request must be delivered in the following way:

The advantage of this constraint of the hierarchical structure is that the hierarchical dependencies are forced to be limited to pairwise dependencies, which reduces the overall system complexity.

For example,
the Persistence Layer is as follows,

public class AvatarDao {
    
    
    public static String getAvatarUrl(int userId){
    
    
        // 具体实现代码 略
        return "http://avatar.csdn.net/xxx.jpg";
    }
}

The Business Layer is as follows,

public class AvatarBizz {
    
    
    public static String getAvatarUrl(int userId){
    
    
        return AvatarDao.getAvatarUrl(userId);
    }
}

Presentation Layer is as follows,

public class AvatarView {
    
    
    public void displayAvatar(int userId) {
    
    
        String url = AvatarBizz.getAvatarUrl(userId);
        // 渲染代码略
        return;
    }
}

For example, the Business Layer is dependent on the Presentation Layer and only depends on the Persistence Layer. But the price of the layered structure is redundancy, that is to say, no matter how simple the business is, each layer must participate in the processing, and even a simple wrapper function may be written for each layer. The advantage of the layered architecture is that pairwise dependencies are enforced and constrained by layering. Once the layering is freely chosen, the architecture will become chaotic over time.

For example, the Presentation Layer directly accesses the Persistence Layer, and the Business Layer directly accesses the Database Layer. In doing so, the meaning of the layered architecture is lost, and it also leads to the inability to control the scope of impact during subsequent expansions. It affects the whole body and cannot support rapid expansion.
In addition, although the implementation of the layered architecture seems a bit verbose and redundant in some scenarios, the complexity is very low.
Another typical disadvantage of the layered architecture is performance, because each business request needs to go through all The architecture is layered, some things are redundant, and there will be some performance waste

The so-called performance disadvantage here is only a theoretical analysis. In fact, the performance loss caused by layering may be obvious in the 1980s, but
now, the performance of hardware and networks has made a qualitative leap. In fact, layering The performance loss in mode theory is negligible in most scenarios in practical applications

SOA

The full name of SOA is Service Oriented Architecture, and the Chinese translation is "Service Oriented Architecture". The background of the emergence of SOA is the repeated construction and low efficiency of IT systems within the enterprise, which are mainly reflected in:

• Each department of the enterprise has independent IT systems, such as human resource systems, financial systems, and sales systems. These systems may all involve personnel management, and each IT system needs to repeat the functions of developer management. For example, after an employee leaves the company, it is necessary to delete the employee's permission in the above three systems respectively.
• Each independent IT system may be purchased from different suppliers with different implementation technologies, and the enterprise itself is unlikely to reconstruct based on these systems.
• With the development of the business, the complexity is getting higher and higher, and more processes and businesses require the cooperation of multiple IT systems. Since there is no standard implementation method for each independent IT system (for example, the human resources system is developed in Java and provides RPC to the outside; while the financial system is developed in C# and provides the SOAP protocol to the outside), every time a new process and business are developed, coordination is required A large number of IT systems are customized and developed at the same time, which is very inefficient.

In response to the problems of traditional IT systems, SOA proposes 3 key concepts

Serve

All business functions are a service, and service means providing open capabilities to the outside world. When other systems need to use this function, there is no need for customized development. Services can be large or small, simple or complex.
For example, human resources management can be a service, including basic personnel information management, leave management, organizational structure management and other functions.
The basic personnel information management can also be used as an independent service.
Org Structure Management is also available as a stand-alone service.
Whether it is divided into coarse-grained services or fine-grained services needs to be judged according to the actual situation of the enterprise.

ESB

The full name of ESB is Enterprise Service Bus, and the Chinese translation is "Enterprise Service Bus".
As can be seen from the name, ESB refers to the concept of computer bus.
The bus in the computer connects the various devices together, and the ESB connects the various services in the enterprise.
Because each independent service is heterogeneous, if there is no unified standard, the interfaces provided by each heterogeneous system are various.
SOA uses ESB to shield heterogeneous systems from providing various external interface methods, so as to achieve efficient interconnection and intercommunication between services.

loosely coupled

The purpose of loose coupling is to reduce the dependence and mutual influence between various services.
Because after adopting the SOA architecture, each service runs independently of each other, and it is not even clear how much a certain service depends on other services.
If loose coupling is not achieved, once a certain service is upgraded, all other services that depend on it will fail, which will definitely not meet business needs.
In fact, it is not so easy to achieve loose coupling. It is a complicated task to achieve complete backward compatibility.

SOA architecture is a relatively high-level architecture design concept. Generally, we can say that an enterprise adopts SOA architecture to build IT systems, but we cannot say that an independent system adopts SOA architecture. SOA solves the duplication of traditional IT systems
. The problem of inefficiency in building and scaling, but that itself introduces more complexity. The most widely criticized SOA is the ESB, which needs to implement functions such as protocol conversion, data conversion, and transparent dynamic routing with various systems. The figure below is the flow chart of ESB converting JSON to Java.

In the figure below, ESB converts the REST protocol into two different protocols: RMI and AMQP:

Although ESB is powerful, there are many protocols in reality, such as JMS, WS, HTTP, RPC, etc. There are also many data formats, such as XML, JSON, binary, HTML, etc.
ESB needs to complete the mutual conversion of so many protocols and data formats, the workload and complexity are very large, and this conversion requires a lot of effort. computing performance.
When ESB carries too many messages, ESB itself will become the performance bottleneck of the whole system.