My architecture experiences (I)-common architecture models

Document directory

• 1.3/N layer architecture
• 2. "framework + plug-in" Architecture
• 3. Regional distributed architecture

Over the past few years, we have accumulated some experience in the system architecture. It is necessary to summarize these experiences. In my architecture thinking, there are three types of architecture models: 3/N layer architecture, "framework + plug-in" architecture, and regional distributed architecture.

I. Three architecture models: 1.3/N layer architecture

This is a classic multi-layer architecture model. It is hard to imagine that a system that is a little more complex or especially complex does not use a layered architecture. Is a classic layer-3 architecture:

Nowadays, all programmers can talk about Layer 3/N architecture. This is indeed a mainstream mode to solve system complexity. However, will the complexity of the system be solved by adopting a 3/N layer architecture? Not necessarily, the key lies in how you implement your 3/N layer structure in your system.
After adopting the 3/N layer architecture, we still need to solve the following important problems: scalability of the system (able to cope with changes with ease), maintainability of the system (because the system is not discarded once), convenient deployment (convenient deployment of new business functions when requirements change), and other system quality attributes. However, the scalability and maintainability of the system are the top priorities of most software systems, which are determined by the complicated and changing software environment of the current demand.Just as functional requirements are the most basic, adopting a 3/N layer architecture is only the first step in the long journey..
I used the "framework + plug-in" architecture to solve problems related to system scalability, maintainability, and deployment.

2. "framework + plug-in" Architecture

The classic 3/N layer architecture is used toVertical"Hierarchical, and the" framework + plug-in "architecture for the system"Horizontal. 3/N layered architectures and "framework + plug-in" architectures are in an equal position, and they have no dependency.
 

However, I often use them together. Our system can be seen as a"Grid"Structure, some of which can be viewed as"Extension point", We can mount" plug-ins "at these extension points ". In other words, we can mount appropriate plug-ins on each layer of the 3/N layer architecture to complete some features of this layer. For example:
 

The main feature of the plug-in is that the"Hot swapping", That is, the plug-in can be Dynamically Loaded/removed/updated without stopping the service. Therefore, the plug-in technology can implement the following functions:
(1) At the UI Layer, we can replace some user interfaces or load user interfaces related to new businesses at runtime. At the business logic layer, we can load, replace, or delete a service at runtime. In the data access layer, We can dynamically add support for new database types (such as MySQL) by using plug-in technology.
The plug-in's "hot swapping" feature makes our system highly scalable.
(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-in when the service is running.
(3) to construct the system into a "framework + plug-in" structure, we need to perform a "loose coupling" design at all layers of the system, only loosely coupled components can be used as plug-ins ".

Integrating the "framework + plug-in" architecture in the 3/N layer architecture, the most difficult thing is loose coupling of the business logic layer. This requires us to carefully analyze the associations between business needs, tightly coupled businesses are encapsulated in a single component, so that independent business components can have the opportunity to become plug-ins. This process may require constant reconstruction and design reconstruction.
We know that the loosely coupled components are clearer, clearer, and easier to maintain than those tightly coupled components. In addition, this architecture model introduces the AOP framework for centralized Aspect focus programming (such as processing log records and permission management ), so that the Aspect code will not be mixed into the normal business logic code, so that the Code's clarity and maintainability are further enhanced.
From the above introduction, we can see that the combination of a 3/N architecture and a "framework + plug-in" architecture can enhance the scalability, maintainability, and simple deployment and upgrade capabilities of the system.

3. Regional distributed architecture

I accidentally invented the term "regional distributed architecture. The regional distributed architecture is mainly applicable to applications that require regional distribution similar to LBS (location-based services. The regional distributed architecture is based on the above 3/N layered architecture and "framework + plug-in" architecture. Their relationships are as follows:

Now I will give a brief introduction to the regional distributed architecture. Assume that we need to provide our business function services for major cities across the country, and assume that each city has a large number of customers, in addition, the data accessed by each city may be different (for example, map data of each city) and different access functions (for example, some cities provide weather query services, other cities do not ). In addition to requesting services from our system, the customer may also want to use our system to communicate with his friends in real time, and their friends may be in the same city as him, it may also be located in another city.
Well, let's look at how the regional distributed architecture solves the above-mentioned requirements.
First, the regional distributed architecture separates user management from business function services, which are respectively undertaken by the Application Server (AS) and feature server (FS), and then deployed on different nodes.Both AS and FS adopt a 3/N architecture and a "framework + plug-in" architecture.For example, FS provides functional services through function plug-ins.
For example, for the region in Wuhan, we have deployed an AS and a FS, and the client connects to the AS for service requests. Suppose one day, our customers in Wuhan increased dramatically, which is the most stressful of which is FS, because all business computing is completed on FS.
In this case, the regional distributed architecture allows us to dynamically add FS servers without stopping any services. Newly Added FS servers are automatically registered to the.
 
AS can monitor the load of each FS (such as cpu consumption and memory consumption). When a client request arrives, AS will send the request to the FS with the lowest load for processing, this achieves FS load balancing.
If Client A needs instant communication with Client B, these communication messages will be transferred through.
The above shows the deployment of our system in Wuhan, and the deployment in other cities is the same.

In this case, AS and AS are independent from each other, but often communication is required between AS. For example, Client A needs instant communication with Client E, or Client A needs to request services exclusive to the Shanghai region.
The regional distributed architecture uses cross-region application servers (IRAS) to solve the communication problem between. All AS will be automatically registered with IRAS at startup.
If we want to provide our services in Changsha, we only need to deploy our AS and FS in Changsha so that we can integrate them into the distributed architecture of the entire region.
For more information about the regional distributed architecture, you can analyze and mine it on your own.

2. Support for architecture models

If you do not have a set of tools to support the above architecture model, you may think that I am here to talk about it. In the past few years of development, I have accumulated several frameworks and class libraries to support the above architecture model.
(1) DataRabbit provides relational and ORM-based (lightweight) Data Access and supports new database types through plug-ins.

(2) ESFramework solves the underlying communication (directly based on TCP and UDP) between distributed systems (such as the preceding regional distributed architecture ).

(3) AddinsFramework provides support for the "framework + plug-in" architecture model.

(4) ESAspect provides support for aspect programming by implementing the AOP framework through Proxy.

(5) EsfDRArchitecture provides support for regional distributed architecture models. For example, it supports dynamic addition/removal of FS, load balancing of FS, communication between AS and FS, AS and IRAS, and cross-region service requests. For more information, see http://zhuweisky.cnblogs.com/archive/2006/03/15/350408.html.

Many of the content mentioned above have been mentioned in my previous blog articles. Readers can learn more about this content based on my earlier blog.