ESPlatform cluster platform (00)-concepts and models

Document directory

• 1. Ensure smooth network between AS and ACMS
• 2. Try to connect clients that need to communicate with each other to the same
• 3. You may need to deploy a dedicated forwarding server TS.
• 4. Heat Engine backup ACMS

When we deploy the server of an application developed based on ESPlus/ESFramework on one server, we can call this server AS an application server (). When the number of online users increases, we may need to deploy several or more AS servers to share the load. However, without the unified ESPlatform management, none of these AS instances are independent islands and cannot collaborate with other AS instances. For some special applications, it may be possible. However, for most applications that require clustering, you must manage a large number of AS and coordinate their work.

Especially for applications that need to communicate with each other between any two clients (these two clients may connect to different AS), ESFramework's P2P technology can solve some problems, however, not all P2P channels can be created successfully. After ESPlatform is used, all online users are connected to the same AS the server instance. The server instance is transparent to the client.

I. Basic cluster model

In a single AS application, we focus on servers and clients. In multi-AS cluster applications, we need to add a core concern, that is, the platform layer. The ESPlatform cluster model can be divided into three layers: the platform layer, the application layer (that is, the AS layer), and the client. Shows the simplest cluster model supported by ESPlatform:

The core of the platform layer is ACMS, which is used to manage all application servers in the ESPlatform cluster. ACMS has the following responsibilities:

(1) manage all online AS services.

(2) manage all online users and their P2P addresses.

(3) forward messages between.

(4) Provide service interfaces for calls from other systems outside the cluster.

ESPlatform provides ACMS servers that can be directly deployed and run. We will introduce it in detail in subsequent articles.

Now, we assume that two clients, Client01 and Client02, are connected to different application servers AS01 and AS02 respectively. We assume that due to the reasons of the router (for example, the NAT types of the two routers are always hierarchical ), the P2P channel between Client01 and Client02 is not successfully established. In this case, if the client 01 and client 02 need to communicate with each other, the information will pass through ACMS. For example, if Client01 sends a message to Client02, the route of the message will be: Client01 => AS01 => ACMS => AS02 => Client02.

In the ESPlatform cluster model, there are three possible paths from Client01 to Client02:

(1) When a P2P channel exists between Client01 and Client02, it is directly obtained through the P2P channel. Otherwise, enter (2 ).

(2) when the connection between Client01 and Client02 is the same AS, it is directly forwarded by this. Otherwise, enter (3 ).

(3) forward data through ACMS.

For Client01, it does not need to be concerned about which of the three paths reaches Client02. ESPlatform ensures this and is transparent to the client.

2. Global friend management and Group Management

For applications that require friend or group relationships, IFriendsManager implementation classes and IGroupManager implementation classes can be instantiated directly in the server process in a single AS application. However, in the ESPlatform cluster, IFriendsManager and IGroupManager are used for each AS, so it is best to have a global friend management and group management.

We can do this by deploying the IFriendsManager implementation class on one server separately, called the friend server FriendServer; deploying the IGroupManager implementation class on one server separately, called the Group server GroupServer. Both FriendServer and GroupServer expose the corresponding services through Remoting. Therefore, each AS accesses IFriendsManager and IGroupManager through Remoting. Obviously, global FriendServer and GroupServer should be at the platform layer.

After the FriendServer and GroupServer are deployed, you only need to inject the Remoting reference of IFriendsManager and IGroupManager to the engine attributes when initializing the AS server engine, then, AS will automatically access the services exposed by FriendServer and GroupServer.

Of course, this is only the simplest case. In fact, in real application, we still need to consider a very important aspect: performance. AS may frequently access services exposed by FriendServer and GroupServer. Therefore, it is necessary to consider the following carefully:

(1) Whether to cache friend/group relationship information in the memory of FriendServer and GroupServer to avoid loading from the outside every time.

(2) Whether to cache friend/group relationship information in the AS memory to prevent Remoting from accessing FriendServer and GroupServer every time.

There may be other methods, but this must be carefully considered based on your business needs.

Iii. policies and principles

Generally, a cluster system is a rather complex system. In order to handle complexity, the principles must be followed unless you have sufficient reasons and can better solve the problem. When using the ESPlatform cluster platform, we should pay full attention to the following points.

1. Ensure smooth network between AS and ACMS

AS may access ACMS at any time. For example, when a user goes online or offline, AS needs to report to ACMS; information between some clients must be transferred through ACMS. If the network between the AS and ACMS is interrupted, even if it is only for a moment, the status data between the AS and ACMS may be inconsistent.

We usually deploy AS and ACMS in the same LAN of the same data center to ensure the quality and speed of communication.

2. Try to connect clients that need to communicate with each other to the same

Which AS server should a newly started client be connected to is determined by our AS allocation policy. Therefore, in order to minimize the number of messages forwarded by ACMS, that is, to minimize the load of ACMS, when designing the AS allocation policy, special attention should be paid to connecting clients that need to communicate with each other to the same AS server. In this way, even if the P2P channels between the two clients are not interconnected, the interaction information between the two clients only needs to be transferred through the AS, so there is no need to bother ACMS.

3. You may need to deploy a dedicated forwarding server TS.

Even if the above is done well, there will still be situations where information needs to be forwarded by ACMS. If low-frequency information (such as text chat information in the IM system) is forwarded, the relationship is not great. However, if you need to forward high-frequency information (such as video and audio data), it is not suitable for ACMS transfer. Because of the high-frequency information forwarding, the load of ACMS is greatly increased, thus affecting the performance of the entire cluster system. What should I do at this time? Our experience is: dynamically connect to the forwarding server TS.

If you cannot successfully create a P2P channel and two clients on the same AS, Client01 and Client02 need to communicate frequently, select a suitable forwarding server TS based on a certain policy, both Client01 and Client02 are connected to the TS, and the subsequent high-frequency information (even all the information to be forwarded) passes through the TS. Obviously, TS is also located at the application layer in the ESPlatform hierarchy model.

(1) we can regard ts as a special type of AS. It does not participate in any specific business logic processing, but simply forwards information.

(2) We can deploy many ts as needed, and TS does not need to be deployed in the same data center of ACMS/. On the contrary, TS may be deployed throughout the country. The simplest strategy for selecting TS between Client01 and Client02 that require high-frequency communication is to check the shortest sum of the routes from the two clients to the TS.

4. Heat Engine backup ACMS

In the cluster model, it is easy to see that ACMS is the "single point" of the entire cluster system. As long as ACMS fails, the entire cluster system will not work normally. Therefore, when deploying ACMS, it is best to use dual-engine backup or multi-engine backup. In this way, after the active ACMS unexpectedly becomes a machine, another backup machine can immediately take over the work.

Iv. Summary

ESPlatform provides the most basic cluster model (the first model diagram in this article), and subsequent evolutionary models are based on the conventional changes that may be required. Moreover, these changes can be further deepened based on more demand assumptions. For example, we can introduce TCMS (forwarding Cluster Management Server) to manage all the forwarding server TS. For example, in a system that requires high-frequency broadcast information, we can also introduce the TS-like Broadcast Server BS to forward all broadcast information and introduce BCMS (broadcast Cluster Management Server) to manage all BS.

However, no matter how it changes, its foundation is still the basic model shown in our first model diagram. It is the core model of ESPlatform. For some simple business systems, the simplest model may be enough. For those complex systems, there is no fixed direction for how to change and deepen the core model. Ultimately, it depends on the needs of our systems. As a saying goes: an imaginary model is useless. It must be combined with actual needs and be refined in practice.

 

In the next article, we will detail how to migrate from a single AS system to the ESPlatform platform. Thank you for your attention.

 

Read more ESFramework development manual articles.

Certificate -----------------------------------------------------------------------------------------------------------------------------------------------

For any questions about ESFramework, please contact us:

Tel: 027-87638960

Q: 372841921

Mail: esframework@oraycn.com