Esframework 4.0 (10)-vertical segmentation cluster model and multi-channel Engine

In the article esframework 4.0 advanced (09) -- three cluster models supported by esplatform, we introduced three cluster models supported by esplatform-vertical segmentation model, horizontal segmentation model, and cross model. We can see that in the vertical segmentation model and cross model, each client must communicate with multiple application servers, this requires the client to establish a communication channel with each of the multiple as, so that the client can obtain the complete service provided by the server.

Esplatform has a series of infrastructure and components to support such a structure, and the multi-channel engine is a key component. First, you must note that the multi-channel engine is meaningful to the client, because the server engine is multi-channel-the server and each client have a channel. Therefore, when we mention a multi-channel engine, it must be a multi-channel Client Engine. In esframework 4.0 (03)-driving force: communication engine, the basic Client Engine we introduce is a single channel, that is, a client engine instance only communicates with one. The single-channel Client Engine is a primitive component provided by esframework. we can assemble multiple single-channel engine instances to form a multi-channel engine. Actually, esplatform has done this for us, that is, esplatform. paasive.Multichannelengine.

 

I. Multi-Channel engine structure

Multichannelengine is integrated with multiple single-channel engines (esframework. Passive. ipassiveengine). Each engine instance communicates with a corresponding. As follows:

(1) first, multichannelengine implements esframework. Passive. ipassiveengine (composite mode). In any use of ipassiveengine, you can use multichannelengine to replace the corresponding single-channel engine.

(2) multichannelengine is integrated with ipassiveengine instances. Therefore, multichannelengine can support both TCP Engine Integration on the client side and UDP Engine Integration on the client side, or even cross-matching. For example, if as01 provides services through TCP and AS02 provides services through UDP, The engine1 instance uses the tcp client engine, and engine2 uses the UDP client engine.

(3) All engine instances share the sameMessage Processing skeleton ProcessInstance, that is, the same imessagedispatcher object is used to distribute and process messages. This design can make the configuration very simple.

Ii. Discuss messagetype again

Next, we need to consider the question: Which engine instance or channel should we choose to send a message to the server through multichannelengine?

In esframework, use messagetype to markMessageThe messageheader of each message has a messagetype attribute to indicate the type of the current message. In versions earlier than esframework 1.0, messagetype is called servicekey or servicetype, that is, the service type. Its hidden meaning is that each message type corresponds to a service provided by the server. Therefore, when we mention "services" in the article esframework 4.0 advanced (09) -- esplatform supports three cluster models, we often add notes that are "messagetype ". In this case, messagetype in esframework is the service type.

In the Vertical Split model, the service is actually split to messagetype so that different as processes different message types. For example, when as01 processes A-type businesses, the corresponding messagetype value is 101 ~ 200 of messages, while AS02 processes B-type services, the corresponding messagetype is 201 ~ 300 messages. Based on this understanding, the problem we just raised is solved, that is, if the type of message to be sent by the client is between 101 and ~ Between 200, engine1 is used for sending; if the type of message to be sent is between 201 and ~ Between 300, engine2 is used for sending.

As for the types of messages that can be processed by each engine instance, esframework uses the self-described passiveengineunit class for encapsulation:

The messagetypesallowed attribute is a set that contains all types of messages that can be sent by the current engine instance. Therefore, the multichannelengine integrates multiple passiveengineunits to know which engine instance to send the message.

 

Iii. Default Engine

Let's take another question into consideration. In the Vertical Split cluster model, what should we do when one of the multiple as instances fails or the client suddenly disconnects from the same as instances? This situation is very serious because the client cannot obtain the complete service provided by the server. How is esplatform solved?

The multi-channel engine multichannelengine provided by esframework supports the default mode. We will then slightly modify the above structure:

Compared with the original structure diagram, this diagram adds a default as application server, and a default engine is added inside the multi-channel engine. The default mode in the esplatform vertical cluster model is described as follows:

(1) The default as must be able to process all types of messages, that is, the default as can provide complete server services.

(2) When as01, AS02,... after the message type to be processed is specified, all the other unspecified message types are processed by default as (because default as can process all types of messages, this is certainly no problem ). The same is true for multichannelengine. All types of messages that are not allowed to be sent by other engine instances are sent by default engine.

(3) when the connection between an engine instance and the corresponding as is disconnected or the AS is suspended, all messages of the type originally sent by the engine instance are sent by the default engine, these messages will be processed by default. After the suspended as is restored and the corresponding engine instance is re-connected successfully, the specified type of message is still sent by the original engine instance. In this case, default as and default engine act as redundant backups to enhance the robustness of the entire system.

(4) Our suggestion is that, in addition to default as, all the message types of other as instances are allocated. In this way, under normal circumstances, the default as and default engine have no tasks. The default as and default engine are used as backups only when exceptions occur.

(5) Further, esplatform also supports multiple default as and multiple default engines, because a single default as may also be faulty. The actual number of default as to be deployed depends on the specific requirements of your project.

(6) Special emphasis should be placed on,There is a premise that default as can be used as a reserve to successfully take over from the original.-- The best case is that allStateless(Stateless), that is, as does not need to save any user status, or the two messages sent by the same user are not logically associated.

If our application must save some of the user's status data and must rely on the status data to process the user's subsequent messages, the default as cannot be replaced by the original. There are also some solutions, such:

A. migrate status data from as and place it in a location that can be accessed by default as. In this way, normal as is stateless. If necessary, the service can continue to run normally.

B. During the design, all message types related to user status management are handed over to the default as for processing, so that normal as is stateless.

C. During the design, all the message types that involve user status management are handed over to several fixed common as processes, but the client's business logic related to these message typesCodeWhen ipassiveengine is referenced, the corresponding common engine object is used instead of the multichannelengine object.

These solutions are supported in esplatform, but in our experience, it is the simplest and easiest to implement to ensure that normal as is stateless. Solution C is used only when the force is reached. Of course, there may be other solutions for specific projects. Designers can make full use of the infrastructure provided by esplatform.

4. multichannelengine class

We have made so many preparations before, and it is very easy to understand the main character of this article, multichannelengine.

(1) multichannelengine consists of multiple default engines and multiple common engines.
(2) The client status is subject to the default engine.
(3) The initialize/start/stop/initializeandstart method and all Attribute Set Methods call all internal engines one by one.
(4) When sending a message to the server, first check whether there is a common engine that allows the message to pass. If there is such a common engine, it is used to send the message; otherwise, it is sent by the first available default engine in the default engine list.
(5) If you want to send a heartbeat message, it will be sent again using each engine to ensure that no timeout or disconnection occurs for each engine instance.

For specific use in the project, we only need to assemble the multichannelengine object, and then, in all previous use of ipassiveengine, change to reference this multichannelengine object. If you use an IOC container similar to spring.net, you can quickly modify the configuration file.

 

This article describes the multi-channel structure between the client and the server. In fact, when the P2P channel is enabled on the client, the multi-channel model between the client and the client is also used, however, this multi-channel model determines which channel should be used for sending the current message based on the message receiver rather than the message type. P2P channels and their management are beyond the scope of this article.

In addition, although the esplatform horizontal segmentation cluster model only needs a single channel in relatively simple applications, some extensions are also required in some cases, for example, "lease" more channels to reduce server-side P2P message forwarding across servers-this is the most effective mode we think when we practice esplatform horizontal segmentation cluster model. The article below will detail this extended mode of the esplatform horizontal split cluster model, as well as the infrastructure and components that esplatform provides to support this mode. Thank you for your attention.

 

Esframework 4.0 Overview

What are the advantages of esframework 4.0?

Esframework 4.0 upgrade description (continuous update)

Esframework 4.0 Quick StartArticle

All articles in esframework 4.0 advanced edition Series