Three architectural models understood by Ali Java Development Engineers

Common software architecture models can be categorized into three architectural models: the 3/n layer architecture, the framework + plug-in architecture, and the geographically distributed architecture.

A Three architectural models

1. 3/n Layer Architecture

This is a classic multi-layered architecture model, which is hard to imagine for a slightly more complex or complex system, without using a layered architecture. is a classic 3-tier architecture:

Today, any programmer can be talked about 3/n layer architecture, which is really a major solution to the system complexity of the mainstream model, but as long as the adoption of 3/n layer architecture is not sure to solve the complexity of the system? 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 most important problems: the scalability of the system (which can handle the change calmly), the maintainability of the system (because the system is not discarded once), the ease of deployment (when the requirements change, to facilitate the deployment of new business functions), and other system quality attributes. However, the scalability and maintainability of the system is the most important problem that most software systems must solve, which is decided by the complex software environment of current requirement. Just as it is essential to implement functional requirements, adopting the 3/n layer architecture is only the first step in Long March.

I use the framework + plug-in architecture to address the challenges associated with system scalability, maintainability, and deployment.

2. "Framework + plugins" architecture

The classic 3/n layer architecture is a "portrait" layering of the system, while the framework + plug-in architecture "horizontally" decomposes the system. The 3/n layer architecture and the framework + plug-in architecture are in an equal position, and they have no dependencies.

But I often use them together, and after the vertical layering of the 3/n layer architecture and the horizontal layering of the "frame + plug-in" architecture, our system can be seen as a "grid" structure in which some of the meshes can be thought of as "extension points" where we can hook up the "plug-ins" at these extension points. This means that we can hook up the appropriate plug-ins at each level of the 3/n layer architecture to accomplish some of that layer's functionality. Such as:

The main feature of the plug-in is that it can be "hot-swappable", which means that the plugin can be dynamically loaded/removed/updated without stopping the service. Therefore, the use of plug-in technology can achieve the following functions:

(1) At the UI level, we can replace certain user interfaces at run time, or load the user interface associated with the new business. At the business logic level, we can load, replace, or delete a business service at run time. At 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-swappable" functionality makes our systems very scalable.

(2) If we need to upgrade the system, in many cases, just upgrade our plug-ins (such as the business plug-in), we can do when the service runs the plug-in automatic upgrade.

(3) In order to make the system "frame + plug-in" structure, we need to "loose coupling" design at each layer of the system, only loosely coupled components can be made "plug-in".

In the 3/n layer architecture, the most difficult thing to do with the "framework + plug-in" architecture is the loosely coupled processing of the business logic layer, which requires us to carefully analyze the correlation between business requirements and encapsulate tightly coupled services in a single component, so that the mutually independent business components can have the opportunity to become plug-ins. This process may require constant refactoring and design refactoring.

We know that loosely coupled components are clearer and easier to maintain than those tightly coupled components. In addition, in the framework model, the AOP framework is introduced into the centralized programming of aspect focus (such as processing logging, permission management, etc.), so that the aspect code is not doped in the normal business logic code, so that the clarity and maintainability of the code are further enhanced.

As you can see from the above introduction, with the 3/n layer architecture and the framework + plug-in architecture, we can enhance the scalability, maintainability, and ease of deployment of the system.

3. Geo-distributed architecture

I inadvertently invented the word "geographical distributed architecture", hehe, do not know whether the meaning of the expression is accurate. Geo-distributed architecture is mainly aimed at the application of geographic distribution for similar lbs (location-based service) needs. The geo-distributed architecture is based on the above 3/n layer architecture and the framework + plug-in architecture, and their relationships are as follows:

Now I'm going to make a brief introduction to the geo-distributed architecture. Suppose we need to provide our business function services to major cities across the country, assuming that the number of customers in each city is large, and that the data accessed by each city may be different (such as map data for each city), the functionality of the visit is not the same (if some cities offer weather-enquiry services while others do not). In addition to requesting services from our system, the client may want to communicate with his good friends through our system in real time, while their good friends may be in the same city as they are in another city.

Well, let's see how the geo-distributed architecture solves the above requirements.

First, the geo-distributed architecture separates user management from the Business function service, which is the responsibility of the application Server (as) and the feature server (FS), and then deploys them to different nodes. Both as and FS use a combination of the 3/n layer architecture and the framework + plug-in architecture, for example, FS provides functional services through feature plug-ins.

For example, for the Wuhan region, we have deployed an AS and a FS, and the client is making a service request by connecting to as. Let's say that one day our customers in Wuhan have increased dramatically, which is the most stressful is FS, because all of the business calculations are done on FS.

At this point, the geo-distributed architecture will allow us to dynamically add the FS server without stopping any services, and the newly added FS server will automatically register to as.

As can monitor the load per FS (such as CPU consumption, memory consumption), and when a client request arrives, as will send the request to the least-loaded FS processing, which enables FS to load balance.

If client a needs instant communication with Client B, then these communication messages will be brokered through as.

What we see above is the deployment of our system in Wuhan, and the deployment in other cities as well.

In this case, as and as are independent of each other, but often there is a need to communicate with each other, such as: Client a needs to communicate with client E in real-time, or client a needs to request the unique service in Shanghai, and so on.

Geo-distributed architectures use cross-region application servers (IRAS) to address communication issues between as. All as will be automatically registered to IRAs when it is started.

If we want to provide our services at Changsha, we only need to deploy our as and FS in Changsha, so that we can integrate into the representation of the entire geo-distributed architecture.

On the geographical distributed architecture, simply introduce so many, more content, the reader can analyze the mining on their own.

Two Support for the schema model

If you don't have your own set of tools to support the above architectural model, then you might think I'm here to talk nonsense and rant. In the development of these years, I have accumulated several sets of frameworks and libraries to support these architectural models.

(1) Datarabbit provides relationship-based and ORM-based (lightweight) data access to support new database types through plug-ins.

(2) Esframework addresses the underlying communication (directly based on TCP and UDP) between distributed systems, such as the geographically distributed architecture described above.

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

(4) Esaspect provides support for aspect programming by means of the AOP framework implemented by proxy.

(5) Esfdrarchitecture provides support for geo-distributed architecture models. such as support, dynamic addition/removal of FS, load Balancing of FS, communication between AS and FS, as and IRAs, cross-region service requests, and so on.

It is felt that the above architecture design mainly favors the system design of the Java EE aspect, if it is other, such as the design of communication system, it may be different.

If you want to learn architecture technology friends can add my QQ group 705194503, which shared my ten years of experience in the practice of programming, including some classic source analysis, see how Daniel's code design, why this design. There are currently the most mainstream distributed architecture technology, micro-service architecture technology and so on. These technologies are recorded as video sharing in the group and can be downloaded for free.

Three architectural models understood by Ali Java Development Engineers