Commonly used software architecture models can be classified into three architecture models: 3/N-tier architecture, "framework + plug-in" architecture, and geographically distributed architecture.
one. Three architectural models
1.3/N layer architecture
This is the classic multi-tier architecture model, and for systems that are slightly more complex or especially complex, it is hard to imagine not using a layered architecture. The following figure is a classic 3-tier architecture:
Nowadays, any programmer can talk about 3/N layer architecture, which is indeed a mainstream mode to solve the system complexity, but, as long as the 3/N layer architecture is adopted, will it be able to solve the system complexity? already? Not necessarily, the key is how you implement your 3/N layer structure in your system.
After adopting the 3/N layer architecture, we still have to solve the following very important issues: the scalability of the system (can cope with changes calmly), the maintainability of the system (because the system is not used once and discarded), Ease of deployment (easy to deploy new business functions when requirements change), and other system quality attributes. However, the scalability and maintainability of the system are the top priorities for most software systems, which are determined by the complex and changeable software environment at present. Just as the realization of functional requirements is the most basic, the adoption of a 3/N layer architecture is only the first step in a long march.
I adopt a "framework + plug-in" architecture to address the challenges associated with system scalability, maintainability, and deployment.
2. "Framework + Plugin" Architecture
The classic 3/N layer architecture is to “vertically” layer the system, while the “frame + plug-in” architecture decomposes the system “horizontally”. The 3/N-tier architecture and the "framework + plug-in" architecture are on an equal footing, they do not have any dependencies.
But I often use them together. Our system can be regarded as a "grid" structure after the vertical layering of the 3/N layer architecture and the horizontal layering of the "frame + plug-in" architecture. Certain meshes can be thought of as "extension points" where we can hook up "plugins". That is to say, we can hook appropriate plug-ins at each layer of the 3/N layer architecture to complete some functions of this layer. Such as:
The main feature of plugins is that they can be "hot-swappable", which means that plugins can be dynamically loaded/removed/updated without stopping the service. Therefore, using plug-in technology can achieve the following functions:
(1) At the UI layer, we can replace some user interfaces or load new business-related user interfaces at runtime. In the business logic layer, we can load, replace or delete a business service at runtime. In the data access layer, we can dynamically add support for new database types (eg MySQL) by using plug-in technology.
If you have friends who want to learn architecture technology, you can add my QQ group 725219329, which shares my ten years of programming experience, including some classic source code analysis, to see how Daniel's code is designed and why it is designed this way. There are also the most mainstream distributed architecture technologies, micro-service architecture technologies, etc. These technologies are recorded as videos and shared in the group, and everyone can download them for free.
The "hot-plug" function of the plug-in makes our system very expandable.
(2) If we need to upgrade the system, in many cases, we only need to upgrade our plug-ins (such as business plug-ins). We can automatically upgrade the plug-ins when the service is running.
(3) In order to make the system into a "frame + plug-in" structure, we need to carry out "loose coupling" design at each layer of the system, and only loosely coupled components can be made into "plug-ins".
To integrate the "framework + plug-in" architecture in the 3/N layer architecture, the most difficult thing is to deal with the loose coupling of the business logic layer, which requires us to analyze the relationship between business requirements in detail and encapsulate the tightly coupled business in a component In this way, the independent business components obtained in this way can have the opportunity to become plug-ins. This process may require constant refactoring, refactoring of the design.
We know that loosely coupled components are clearer and easier to maintain than tightly coupled components. In addition, the AOP framework is introduced into the architecture model for centralized programming of the Aspect focus (such as processing logging, permission management, etc.), so that the Aspect code will not be mixed with the normal business logic code, making the code clearer , The maintainability is further enhanced.
It can be seen from the above introduction that by combining the 3/N-layer architecture and the "framework + plug-in" architecture, we can enhance the scalability, maintainability, and simple deployment and upgrade capabilities of the system.
3. Geographically distributed architecture
I accidentally invented the term "geographically distributed architecture", huh, I don't know if the meaning is accurate. The geographically distributed architecture is mainly for applications that need to be geographically distributed similar to LBS (Location-Based Services). The geographically distributed architecture is based on the above-mentioned 3/N-tier architecture and "framework + plug-in" architecture, and their relationship is as follows:
Now I will give a brief introduction to the geographically distributed architecture. Suppose we need to provide our business function services for various major cities in the country, assuming that each city has a large number of customers, and the data accessed by each city may be different (such as the map data of each city), access The functions are also different (for example, some cities provide a weather query service, while others do not). In addition to requesting services from our system, a customer may also want to communicate instantly through our system with his good friends, who may be in the same city or in another city.
Well, let's see how the geographically distributed architecture solves the needs similar to the above.
First, the geographically distributed architecture separates user management and business function services, and is responsible for the application server (AS) and the function server (FS) respectively, and then deploys them to different nodes. Both AS and FS use a combination of 3/N-layer architecture and "framework + plug-in" architecture. For example, FS provides functional services through functional plug-ins.
For example, for the Wuhan region, we have deployed one AS and one FS, and the client makes service requests by connecting to the AS. Suppose that one day, our customers in Wuhan increase sharply, which is the most stressed is FS, because all business calculations are done on FS.
At this time, the geographically distributed architecture will allow us to dynamically add FS servers without stopping any services, and the newly added FS servers will be automatically registered with the AS.
The AS can monitor the load of each FS (such as CPU consumption and memory consumption), and when a client request comes, the AS will hand over the request to the FS with the lowest load for processing, which realizes the load balancing of the FS.
If Client A needs to communicate instantly with Client B, these communication messages will be relayed through the AS.
Seen above is the deployment of our system in Wuhan, and the same is true for deployments in other cities.
In this case, the AS and the AS are independent of each other, but it often happens that the ASs need to communicate with each other. For example, Client A needs to communicate with Client E in real time, or Client A needs to request the uniqueness of the Shanghai area. services, etc.
The geographically distributed architecture uses inter-regional application servers (IRAS) to solve the communication problem between ASs. All ASs will automatically register with IRAS when they are started.
If we want to also provide our services in Changsha, then we only need to deploy our AS and FS in Changsha, so that we can integrate into the entire geographically distributed architecture shown in the figure above.
Regarding the geographically distributed architecture, so much is briefly introduced. For more content, readers can analyze and mine by themselves.
two. Support for architectural models
If you don't have your own set of tools to support the above architectural model, you might think I'm talking nonsense here. In the development of these years, I have accumulated several frameworks and class libraries to provide support for the above architecture model.
(1) DataRabbit provides relation-based and ORM-based (lightweight) data access, and supports new database types through plug-ins.
If you have friends who want to learn architecture technology, you can add my QQ group 725219329, which shares my ten years of programming experience, including some classic source code analysis, to see how Daniel's code is designed and why it is designed this way. There are also the most mainstream distributed architecture technologies, micro-service architecture technologies, etc. These technologies are recorded as videos and shared in the group, and everyone can download them for free.
(2) ESFramework solves the underlying communication (directly based on TCP and UDP) between distributed systems (such as the above-mentioned geographically distributed architecture).
(3) AddinsFramework provides support for the "framework + plug-in" architecture model.
(4) ESAspect The AOP framework implemented by Proxy provides support for aspect programming.
(5) EsfDRArchitecture provides support for the geographically distributed architecture model. For example, support, dynamic addition/removal of FS; load balancing of FS; communication between AS and FS, AS and IRAS; cross-regional service requests, etc.
I feel that the above architecture design is mainly biased towards the system design of J2EE. If it is the design of other systems such as communication, it may be another matter.