Overview of 4-layer architecture based on C / S

Overview of 4-layer architecture based on C / S

The four layers of the four-layer structure of ESFramework are: client (Client), application server (AS), function server (FS), database server. The connection diagram between them is as follows:


FS (FuncTIonServer), a functional server, processes and only processes all functional requests, does not participate in user management, status maintenance, etc., providing the purest functional services.
AS (ApplicaTIonServer), application server, forwards all functional requests to FS, and handles all non-functional requests, and manages end users, maintains status, and logs records.
The number of function servers FS in the above figure may be 0 to N (N> 0). In a sense, it can be considered that each functional server FS is interchangeable.

Splitting the server into a functional server and an application server has two obvious benefits:
(1) The functional server FS is fully reusable. Because the function server adopts the "framework + plug-in" structure, the entire function server is completely reusable. To switch from a specific application to another specific application, you only need to replace the function plug-in. FS does not need to be recompiled.
(2) Since FS only provides the purest functional services, user management and state maintenance are not required. The statelessness of this functional server at runtime makes it easy for functional servers to implement load balancing clusters (more on this later, How this kind of dynamic load balancing is achieved).

If ESFramework only accomplishes this step, there is no need to take it out and share it with you. ESFramework not only provides full and complete support for this 4-layer architecture, ESFramework goes one step further, it can support a "similar geographical distribution" system structure. Readers may have learned that the above 4-layer architecture is already a distributed architecture, so what does "region-like distribution" mean here?

It can be said that the 4-layer architecture is a "vertical" architecture, and "region-like distribution" focuses on "horizontal". In the "region-like distribution" architecture, each specific "4-layer architecture" is implemented. "It's just one of the elements. Let me give an example. Now one of our applications needs to provide some kind of C / S-based mobile value-added service for mobile phone users in all large cities nationwide. Our experience is that an application server AS is configured for each city. Due to the large amount of calculation on the FS corresponding to the AS, multiple FSs may be required to serve this AS. And each city's AS may need to communicate with each other (such as handling roaming users), which requires the AS to be managed, the server that manages the AS is the IRAS (cross-region server). As a result, I can draw the following picture as an example:

The FunAddin in the picture is a function plug-in, which has been introduced before. In the entire system, the services requested by the terminal are mainly divided into two categories, one is to request functional services from the application server AS, and the other is non-functional communication between the terminal and the terminal. All functional services are processed by the functional add-on (FunAddin), and all non-functional communication is processed or relayed by the application server. If the functional service requested by the terminal is located in an external system, the functional plug-in will automatically locate the address of the external system, and then submit the request to the external system through WebService and other methods.

Well, the reader has already understood what is going on in the 4-layer structure and "similar geographically distributed" structure in ESFramework. Below is a brief overview of how powerful ESFramework provides the 4-layer structure and "similar geographically distributed" structure Features support:

1. Component-based Apart from all the functional plug-ins being components, the entire ESF platform is also assembled from components. The benefits are:
(1) Quickly build the system (2) Promote component reuse, such as AS / IRAS / FS / IRFS can use the same communication component to complete the communication layer work.
(3) Realize the "hot swap" of function plug-ins, which can dynamically add / remove function services at runtime

2. Highly scalable As the ESF service platform system needs to cope with sudden changes anytime, anywhere, it must have a high degree of scalability:
(1) "Hot plugging" of function plug-ins
(2) Dynamic access to external services (usually through WebService)
(3) Dynamic addition / removal of application server AS, for example, the newly opened service for Dalian city.
(4) Dynamic addition / removal of functional server FS to realize dynamic load balancing cluster of functional servers.

3. Highly scalable As the services we provide become more and more popular, the number of our users will increase dramatically, so the ESF service platform system must be highly scalable to increase the maximum load and throughput of the system.
(1) Since the functional server needs to perform a large number of functional calculations, the bottleneck of the platform is usually located in the functional server, which can be solved by the dynamic clustering of the functional server. The load balancing among the functional servers in the cluster is scheduled by the corresponding application server AS.
(2) When the number of always online users in a single area exceeds 5000 to 10000, we need to add AS to perform load balancing at the regional level. This can be solved by dividing the hardware with the port mapping function.

4. The highly reusable ESF service platform system is not just applicable to our LBS services. In fact, the ESF service platform system is a highly reusable system, which means that the ESF service platform can be used as the basic platform for any and any service, as long as The service it provides is connection-based communication between the terminal and the server via Tcp.

5. Distributed Except for the access of external systems through distributed services, distributed communication is adopted between application servers, between function servers and application servers, and between application servers and application servers across regions. Cross-region application servers are scheduled between application servers in a manner similar to remoTIng.

6. Simple deployment and automatic upgrade As the ESF service platform system may serve many areas, for example, major cities may need to deploy application servers and function servers, so if manual deployment and upgrade is very inefficient, the ESF service platform provides Automatic upgrade, load, and run functions.
(1) After the service platform is installed, only a few parameters in the configuration file need to be modified to run normally.
(2) When the function plug-in has a new version, it can be automatically upgraded to the new version without stopping the service.
(3) When each server system (AS / IRAS / FS / IRFS) has a new version, it will automatically upgrade to the new version when the system restarts. In order not to terminate the service during the upgrade, the server system can use a gradual upgrade method.

7. Communication assurance mechanism When the network is suddenly disconnected or a server is restarted, after the network recovery or server restart is completed, an automatic and immediate communication recovery is required (such as the communication between AS and FS, the communication between each AS and IRAS Communication), the ESF service platform provides this guarantee, and the strategy adopted is mainly based on:
(1) Regular inquiry (2) Automatic reconnection of Tcp connection pool (3) Dynamic reversal of connection

8. Roaming support, cross-region function request support In the ESF service platform system, roaming refers to a user in a certain region logging into an application server AS in another region. For this AS, the user is a roaming user. If a user logs in to an AS but requests functional services in other regions, it is a cross-region functional request. The ESF service platform has given full support to both cases.

9. Terminal-to-terminal communication support Sometimes, the terminal needs to communicate with the terminal (may be in the same area or other areas), and this communication can be based on connection and based on non-connection. Connection-based communication like real-time video chat, real-time monitoring, based on non-connection-like image to send a picture to users who are not online All of these are supported by the ESF service platform.

10. Support for secondary development Based on the highly reusable and extensible ESF service platform, the ESF platform can easily support secondary development. As long as the same interface and communication protocol are followed, secondary development can be performed on the ESF platform.

11. Client framework If the application client can also use .NET development, ESFramework also provides complete support. With the support of ESFramework, the development client only needs to develop business plug-ins. The entire network communication, multi-threading, Upgrade and deployment are all done by the framework. In the following article, I will introduce how to develop custom business plug-ins in AgileIM.

All the above features will be introduced in subsections in the "C / S-based 4-layer architecture" section, thanks for your attention!

If your application does not need such a complex structure, such as just a simple 3-layer architecture, then ESFramework can still help you build quickly. ESFramework is a lightweight application framework, you will not provide for those ESFramework and you do not The required functions / features pay any price.
(Note that ESFramework is not very suitable for processing legacy systems (just like it is difficult for you to use MFC to process UI applications built on VCL). Although ESFramework has nothing to do with applications, in order to abstract more tasks from applications to frameworks In the future, you must make some assumptions about the application. Fortunately, ESFramework only makes the minimum assumptions about the communication protocol of the application. This assumption is included in NetMessage. If you are not dealing with the legacy system, but building a brand new C / S application , Then ESFramework can save you a lot of architecture design time, software development time, debugging and maintenance time.)

Copper Flat Wire Rolling Machine

Copper Flat Wire Rolling Machine,Special Shaped Copper Strip Machine,Ultra Thin Copper Strip Machine,Copper Strip Annealing Equipment

Jiangsu Lanhui Intelligent Equipment Technology Co., Ltd , https://www.lanhuisolar.com