TWI644571B - Method and loading balance distributor for multiple-dispatch strategy - Google Patents

Abstract

The case is divided into a service-optimized computer system and its methods, including: a shunt, providing multiple shunt mechanisms to provide more suitable for request distribution and better load balancing, including: latest The version is divided, the specified version, the service category is divided, the total number of requests is the minimum, the total number of requests is the least, and the memory of the service platform is the largest.

Description

Load balancing splitter and method thereof for multiple shunting strategy

The present invention is a segmentation of a service-optimized computer system and its method. Currently, the method is implemented in Java 2 Platform (Enterprises Edition, J2EE) (but not limited to any programming language), and is applied to the cloud. Technology, Platform as a Service (PaaS) Platform as a Service.

Decentralized systems have many different definitions. Generally speaking, "a decentralized system is a collection of independent computers, but for users of this system, the system is like a computer." This definition has two meanings: First, from a hardware perspective, each computer is autonomous; second, from a software perspective, the user sees the entire system as a computer. Both of these are required and indispensable. The essence of cloud computing Cloud Computing is actually distributed computing. In the conventional architecture, a cyclic shunt is used as a load balancer to dispatch requests to the application server (AP Sever). In other words, the load balancing algorithm includes: Least Connection Judging by the number of connections, the fewer the number of connections, the lower the load on the host; the Weighted Least Connection is the same as the Least Connection, but will be adjusted according to the weight. Round Robin performs load balancing in a rotating manner. For example, there are three real hosts. The first connection leads to the first real host, the second connection leads to the second real host, and the third connection leads. To the third real host, the fourth connection leads to the first real host, and so on; Weighted Round Robin is the same as Round Robin, but will be adjusted according to the weight; Source Hash is based on the source IP address. Judging the load status, when the client host connects to the Virtual Server, it uses the source address of the client host via the Hash function to calculate that the real host should accept the service and direct the connection to the real host. The program architecture generally running on the application server is based on the MVC architecture, which divides a program into a view layer (View) and a control layer (Controller), a business logic layer (BusinessLogic), and a data storage layer (DAO). Decentralized systems provide optimized transportation services with the following issues.

1. Hot Deployment (Hot Swap): When the module is updated, the system does not need to be shut down to provide the same service. The general system program development is based on the MVC architecture, and the view layer (View) can be automatically recompiled and updated without re-booting according to the specification. If the control layer is designed as a single entry for the module, write the Modules are shared and rarely changed. The control layer does not need to be deployed for modification. The most frequently required programs are BusinessLogic, Data Access Layer (DAO) and other related files. The problem of hot deployment is the program for this part.

1.1 At present, although J2EE has a so-called hot deployment mechanism, it can be used to reduce the downtime when the version is updated, but the user still has to re-login; and because of the general design and development, the independent modules (subsystems) are combined. As a module, so that when the system is hot deployed, the entire system needs to be restarted. The memory shortage due to too many redeployed programs has become inoperable (downtime). (Note: Modules are sometimes called subsystems. , for the collection of functions; the Taiwan module is multiple The vertical modules (subsystems) are accessed by the same session (Session).

1.2 Known similar inventions There are still methods and systems for realizing thermal deployment of software systems as in Chinese Application No. CN201010114369, and the proposed method of the invention includes: (1) setting a first service processing engine for processing core services in a software system. And the second service processing engine, the first service processing engine is connected to the corresponding first service rule storage unit, the second service processing engine is connected to the corresponding second service rule storage unit, and (2) the first service processing engine and the second are set. One of the business processing engines is in the running state, and the other is in the waiting state; (3) when the processing setting of the software system changes, the processing setting corresponding to the service processing engine in the waiting state is updated; and (4) is waiting The stateful business processing engine is set to the running state, and the business processing engine that was originally in the running state is set to the waiting state.

In short, the implementation of hot deployment is solved by switching, but it is different from the method of this case.

1.4 In the Chinese patent application number is 200610123883.0, a method for implementing hot deployment is mentioned, that is, the server before the upgrade is backed up, and the external service is provided, and after the upgrade is completed, the network server is switched to the upgraded web server. External performance is hot deployment. But this approach to hot deployment requires two servers for hot deployment. There are two points in the discomfort.

1.4.1 The method of backing up the entire server to another server for hot deployment requires a new server, which increases the cost.

1.4.2 Introducing an open service gateway architecture to achieve hot deployment requires the mode layer to be placed in each sub-module of the open service gateway architecture. When the schema layer changes, although the web application's class loader can The hot deployment is implemented, but the sub-modules of the open service gateway architecture also need to be restarted, and the hot deployment cannot be realized in a complete sense. Moreover, a large number of changes to the existing system are required, and there is a problem of low stability and poor security, which is only suitable for application on a business system that is not running, and is not suitable for applications on a system that is currently running (refer to the application number CN201010114369) ).

2. In addition to hot deployment, there are two issues after deployment, whether the new and old versions should coexist at the same time, or only the latest version.

3. Fault-tolerant applications, failure or deployment of a unit or resource (software or hardware) does not affect the normal functioning of other resources. Therefore, quantitative deployment should be provided at the time of deployment (that is, the module can be divided and quantized into separate modules, that is, deployed as a class loader-module).

4. In order to protect the operating environment of the system from deployment, or due to other factors such as the rapid increase of requests and the improper execution of a request, the system memory is insufficient to operate the system, so a monitoring mechanism should be provided to prevent this. A problem occurs and the module is plug and play, automatically expanded to keep the system running.

5. A better way to decentralize business logic (BusinessLogic) and data access layer (DAO) to other computers, and to complete the decentralized computing with the mainstream mainstream development architecture.

6. The conventional system architecture is designed with a Round-Robin shunt to dispatch requests to the application server in a rotating manner. Because there is not enough information, it is impossible to achieve load balancing more accurately. Connection is an example. If a connection has a lot of data processing, the load balance of Least Connection is not accurate. For example, if Round Robin is used, if there are two hosts, the number of requests for processing is 100. , 10 pens, 100 pens, 10 pens, will result in uneven distribution.

7. Should be able to provide a specific community-specific execution environment (such as the core of the dedicated CPU or CPU, memory space).

8. Should be able to provide system developer classification management module and upgrade the module library function.

The purpose of this case is to provide a computer system and method for optimizing services, which can provide multiple shunts for general users to achieve better load balancing, and also provide hot deployment for system developers (including the addition of modules, Remove and modify), as well as hot backup systems for sustainable services, as well as good module classification management capabilities.

The case mainly provides a computer system with optimized service by a combination of a shunt and a service platform. The structure of the shunt is a selector, a platform registration center, and a network server; the structure of the service platform is a quantitative deployment. A module overload protection mechanism, a zero request monitoring mechanism, a hot deployment monitoring mechanism, an information recorder, a service platform directory, a request overload protection mechanism, and a network server.

The shunt provides a better load balancing by providing service platform information and module information provided by the platform registry. The service platform provides a security mechanism to prevent deployment and requests from being insufficient due to insufficient memory on the service platform. Operation, and deploying modules with a quantified (hot) deployer to reduce deployment time, and adding a message notifier to synchronize service platform information and module information to the platform registry, enabling the shunt to use the hot deployment module name to connect The modules and versions of the same function are used to achieve the perpetual service in the latest version of the diversion policy. A platform monitoring mechanism is added to the shunt to provide a hot backup mechanism and a module library priority mechanism in the service platform. A modular classification management mechanism to achieve a computer system optimized for service. Next, the implementation mechanism introduces the shunt structure and its operation mode, the related mechanisms and functions provided, the service platform structure and its operation mode, the related mechanisms and functions provided, and explains the shunt and service through the request process. How the platform can achieve sustainable service and service optimization.

The first picture is a schematic diagram of the decentralized system architecture and operation.

The second picture is a schematic diagram of the shunt structure and its operation.

The third picture is a schematic diagram of the structure and operation of the service platform.

The fourth picture: is the service platform directory structure diagram.

Figure 5: Schematic diagram of the request process and the operation of the request security mechanism.

Please refer to the first figure: Decentralized system architecture and operational diagram, which is improved by conventional components and development architecture. The conventional components include: a network application (client), a Round-Robin (servo), a network server (servo), and the component shunt invented in the present invention. And the service platform is installed on a separate network server, and the non-view layer and control layer programs and related files of the conventional development architecture are moved to the service platform for execution, thereby becoming a decentralized system architecture and providing service optimization. Computer system. There are seven reasons why it can provide service optimization.

First, provide a service platform memory inventory management mechanism to protect the system operation.

Second, provide a variety of shunt strategies to achieve more accurate load balancing.

Third, provide a specific community-specific execution environment (such as the core of the dedicated CPU or CPU, memory space).

Fourth, provide automatic real-time (hot) backup mechanism, enhance the system's services to ensure system operation.

5. Provide module classification management functions and upgrade the function of the module library.

Sixth, the provision of services is not interrupted (the system can be fully operated during hot deployment and request, but there is a momentary suspension of service).

VII. Providing sustainable services (all systems can be maintained and serviced on demand during hot deployment and request). The above functions can be realized, mainly for the components invented in the present case: a shunt and a service platform.

Please refer to the second figure: the structure of the shunt and its operation diagram. The shunt includes: a selector, a platform registration center, a platform monitoring mechanism and a network server (known components).

1. Selector: used to dispatch requests according to the split strategy.

2. Platform Registration Center: used to provide a record of login or synchronization service platform and module information.

3. Platform monitoring mechanism: used to monitor the status of the service platform and automatically start the backup service platform according to the settings.

4. Network server: used to install and start the shunt so that the shunt can receive the request as a conventional component.

5. Operation mode: By starting the network server, read the parameter values of the shunt configuration file (please refer to the shunt configuration file description), and start the shunt, create the selector and platform registration center to wait for the service platform and Module registration, after the registration is completed, start the platform monitoring mechanism and wait for the request.

Note: The web server is a superordinate concept, which is a server or container that can receive requests, and can be an application server, an EJB container, and the like.

Please refer to the third figure: service platform structure and its operation diagram, service platform, including: a module administrator, including: 1. Quantitative deployment mechanism, 2. Module library priority mechanism, 3. Module overload Security mechanism, 4. Zero request monitoring mechanism, 5. Hot deployment monitoring mechanism, 6. Information recorder, 7. Message notifier, 8. Module appointment mechanism, 9. Request overload protection mechanism (Request timeout over-preservation mechanism) And the request volume is fast and secure), and a network server (known component).

1. Module administrator:

1.1. Quantitative (fine-grained) deployment mechanism: for deployment in various modes (please refer to deployment mode) Description), allows designers to plan independent modules (single function to multiple functions) according to the function or quantity of the module. The purpose is to make the functional modules of the system independent and completely exhaustive (MECE) thinking. Designed in principle, the modules are made independent for easy porting, installation and shortened startup time.

1.2. Module library priority mechanism: It is used to prioritize different versions of the same library. Compared with the same library in the shared library directory, it is beneficial to allow new modules to be deployed using the new library without affecting the original system. Operation helps to upgrade the system technology.

1.3. Module overload security mechanism: It is used to protect the service platform from being deployed due to insufficient memory of the service platform.

1.4. Zero Request Monitoring Mechanism: Used to prevent requests that are still being executed due to the need for modules to be redeployed or removed.

1.5. Hot deployment monitoring mechanism: It is used to monitor the related file changes of the modules and module catalogs in operation and the addition of modules, and call the quantitative deployment mechanism to complete the hot deployment.

1.6. Information Logger: Used to provide quantitative information on the platform information and module information provided by the quantitative deployment mechanism and the hot deployment monitoring mechanism.

1.6.1 Platform information, including: service platform name, status, service platform memory inventory, service platform address, service platform security quantification, module deployment estimate, platform registration center address, request overload security quantification, request period Quantitative, and module monitoring interval.

1.6.2 Module information, including: module name (entity name), version, module status, category loader, total number of pending requests, total number of pending requests, hot deployment module name (logical name) ), the actual amount of module deployment required and other information.

1.7. Message Notifier: Used to log in to the platform registration center and synchronize the service platform and module information, triggered by the quantitative deployment mechanism, the hot deployment monitoring mechanism and the request overload protection mechanism.

1.8. Module Appointment Mechanism: Used to request the module to execute the request.

1.9. Request overload protection mechanism: to protect the system from being overloaded due to request overload.

2. Network server (known component): used to install and start the service platform so that the service platform can receive the request.

3. Operation mode: read the parameter values of the service platform configuration file by the start of the network server (please refer to the service platform configuration file description), and complete the initialization of the module to become the running mode according to the initial deployment (process). Group, and synchronize the service platform and module information to the information recorder (platform/module), and then start the hot deployment monitoring mechanism to perform the monitoring deployment (process) and complete the startup of the service platform. After the startup, wait for the client to request or trigger the message notifier to log in to the service platform and module information through the platform registration center address, and make the taper establish a connection with the service platform by using the service platform address to complete the service platform and the module. Registration, waiting for a request to be dispatched by the shunt.

Note: The network server of the service platform can be started or manually started by the shunt; the shunt and the service platform can also be installed on the same network server, and are installed on different network servos for the sake of the distributed system. Device.

Next, the initial deployment (process) of the service platform, the monitoring deployment (process), the request process, and the security mechanism are explained, and the reasons for the service optimization are explained.

Please refer to the third figure: the service platform structure and its operation diagram, and the fourth picture: the service platform directory structure diagram.

1. Initial deployment (process): The quantitative deployment mechanism searches for each module in the platform directory under the system directory according to the deployment mode (ie, MA, MB, MC, MD under the system directory/platform directory in the third figure) The names of the modules are created according to the relationship between the directory hierarchy and the directory name and the name of the service platform. Then, the module file information is established by the module library priority mechanism (the module program collection, the hot deployment version file, and the module in sequence). After the file collection, the module library collection, and the shared library collection, the class loader of each module is created, and the module overload check mechanism is checked to complete the deployment. After the completion, the platform information and all of the information are synchronized. Module information and launch a hot deployment monitoring mechanism.

Operating status description:

1.1 According to the setting of the service platform security quantification and module deployment estimation, the module overload security mechanism determines whether the current system memory inventory is sufficient for deployment.

1.1.1 If it is enough, start and set the module status to start. After the deployment is complete, set the module status to running (ie, the running modules MA, MB, MC, MD in the third figure) and synchronize the module. Group information.

1.1.1.1 If the startup fails, set the module status to be started (restarted by the hot deployment monitoring mechanism) and synchronize the module information.

1.1.2 If it is not enough, it will not start, and set the module status to be started (restarted by the hot deployment monitoring mechanism) and synchronize the module information.

Note : 1. The target of synchronous platform information and module information is the information recorder and platform registration center.

2. Upgrade the functionality of the module library by the module library priority mechanism.

2. Monitoring deployment (process): The hot deployment monitoring mechanism sequentially monitors the module program collection, the module file collection, the module library collection, and the shared library collection of each module in the platform directory for change or has been moved. In addition to monitoring and monitoring the module status of each module in the operation, the redeployment or removal and the new module are completed by the quantitative deployment mechanism, the module library priority mechanism, the module overload protection mechanism and the zero request monitoring mechanism. After the completion of all module checks, the platform information and all its module information are synchronized and monitored according to the module monitoring interval.

Operating status description:

2.1 If the module status is to be started, re-deploy the module according to step 1.1.

2.2 If the module directory is new, deploy the module according to step 1.1.

2.3 If the module directory has been removed and there is no request, set the module status to be removed and immediately After the module information is synchronized, the module is removed. After the module is set, the module status is removed and the module information is immediately synchronized.

2.3.1 If there is a request, set the module status to be removed (in the request) and immediately synchronize the module information. After the request of the module has been executed (zero request), the module is removed. After the completion, set the module status to removed and immediately synchronize the module information.

2.4 If the module related file is changed and there is no request, set the module status to be updated and immediately synchronize the module information, then redeploy the module according to step 1.1, and set the module state to be running after the deployment is completed. Synchronize the module information immediately.

2.4.1 If there is a request, set the module status to be updated (in the request) and immediately synchronize the module information so that it can no longer accept the request. After the request of the module has been executed (zero request), Performing the redeployment of the module, and setting the module state to be running and immediately synchronizing the module information to complete the request to receive the request.

Note: The provision of services by monitoring the deployment (process) is not interrupted.

Please refer to the fifth picture: the request process and the flow chart of the request security mechanism.

3. Upon request, the selector sends the module name (logical name) to the platform registry by requesting information (hot deployment module name, version, service category name, request processing number, request content) The same hot deployment module name according to the set diversion policy (according to the latest version, or according to the specified version, or according to the service category, or the minimum number of requests processed according to the request, or the minimum number of requests for the request, or The service platform has the largest memory inventory, or is combined according to the above-mentioned split strategy. The selected state is the running module name and the service platform address.

The module name, the request content, and the number of requests processed are transferred to the service platform of the module through the service platform address, and the module name is used to obtain the module name in the information recorder. The module executes the request, and records the cumulative number of requests and the number of accumulated request processing records in the information recorder. After the request is completed, the number of requests and the number of requests processed are deducted, and the service platform memory inventory is obtained and the result is requested. The total number of requests to be processed, the total number of requests to be requested, and the service platform memory inventory return selector are synchronized with the platform registration center (for the next request reference), and finally the result of the request is returned.

Note: The number of requests processed is the number of requests for business logic to process the requested content.

Total number of pending requests = cumulative request processing number plus or minus the number of requests processed.

Total number of pending requests = cumulative number of requests plus or minus the number of requests (generally, the number of requests = 1).

If the number of requests is 1, the number of requests processed can be 1 or more.

Note: Multiple shunting strategies and more accurate load balancing are achieved by processing the request with the least number of requests, or by the minimum number of requests, or by the shunting method with the most memory of the service platform.

Note: By providing a specific execution environment for specific communities based on the diversion of services, it is a service platform service category. In other words, by setting a service platform in advance for its implementation. The memory volume and the core of the CPU or CPU, if the service information name is attached to the request information and is the same as the service platform name, it is assigned to the service platform; the other service category is the module service category, and the distribution method is the service category name. Compare the module name to find the appropriate set of module names (possibly one or more module names), or dispatch the request according to other distribution strategies.

Note: By the shunting strategy, the latest version of the diversion method is used to achieve sustainable service. In other words, take the MA and MB under the system directory/module directory in the third figure as an example, assuming the service platform name is S1. If the name of the hot deployment module is MX, the two modules S1.MA and S1.MB with the same function are connected (the establishment of the connection mode can use any recordable electronic file such as: file, multi-level directory name, etc. Before the S1.MA is redeployed, the status of the synchronization module is to be updated immediately, so that the request is completed by S1.MB. After the S1.MA is deployed, the status of the synchronization module is running and its version is the latest version. Therefore, the request is completed by S1.MA, and the S1.MB is also deployed and is the same version as S1.MA, and the request is dispatched according to other distribution methods.

4. Description of the security mechanism:

4.1 module overload security mechanism

4.1.1 Initial deployment must meet the following conditions: The memory inventory of the service platform must be greater than the service platform security quantitative + the module deployment estimate, can be deployed.

4.1.2 Monitoring and deployment must meet the following conditions: The memory of the service platform must be greater than the service platform's security and quantity + the actual deployment of the module, and can be deployed.

4.2 Request overload protection mechanism

4.2.1 Request timeout over-preservation, set the service platform for a request period quantitative and request overload preservation quantitative, when the module delegation mechanism of the service platform appoints the module to execute the request, simultaneously initiate a security monitoring mechanism, periodically Check the amount of memory used by the request, and the time spent. If there is a timeout, the execution of the request is interrupted, and the reason for the interruption is reported to save the service platform from being overloaded due to overload of the request.

4.2.2 The request volume is increased and maintained, and the service platform is set to maintain the quantity of the service platform. The memory of the service platform is compared with the memory of the service platform. If the memory of the service platform is lower than the set service platform, the synchronization is synchronized. The service platform status is a pause service. When the service platform memory inventory is higher than the set service platform security quota, the service platform status is re-synchronized to the service.

Note: The service inventory management mechanism of the service platform is achieved by 4.1 and 4.2 to ensure the operation of the system.

4.3 platform monitoring mechanism, according to the monitoring interval of the platform, the monitoring service platform is the quantity in the service. If the status of the service platform is that the quantity in the service is lower than the service platform service quantity, the backup service platform starts the setting file to Achieve automatic expansion of the backup service platform; if greater than or equal to the service platform service quota, start the backup service platform to close the configuration file.

Note: By means of 4.3 automatic automatic (hot) backup mechanism, the system's services are enhanced and the system is guaranteed to operate.

5. Configuration file description:

5.1 shunt configuration file parameter description, including:

5.1.1 Service Platform Profile: Contains records of the startup and shutdown paths of each service platform.

5.1.2 Backup Service Platform Profile: Contains records of the startup and shutdown paths of each backup service platform.

5.1.3 Service Platform Service Quantification: The number of service platforms required to maintain the distributed system.

5.1.4 Platform monitoring interval: Provides the interval between the platform monitoring mechanism and the monitoring platform registration center.

5.2 Service Platform Configuration File Parameter Description, including:

5.2.1 System Name: Used to define the system name.

5.2.2 System Directory: For example, D:\abc\system.

5.2.3 Service Platform Name: The name of the service platform, such as: S1.

5.2.4 Service Platform Address: The address of the service platform, which provides a shunt to connect to the service platform.

5.2.5 Platform Registration Center Address: The address of the platform registration center that provides login and synchronization of the service platform information and module information.

5.2.6 Platform Directory Name: Used to define the directory name where each module is stored.

5.2.7 Deployment Mode: As explained in the deployment mode.

5.2.8 Service Platform Preservation Quantitative: Quantify the memory of the service platform.

5.2.9 Module deployment estimate: The estimated amount of memory required for module deployment.

5.2.10 Request Overload Security Quantitation: The request for this service platform can perform the maximum memory usage.

5.2.11 Request Term Quantification: The maximum time that the service platform's request can be executed.

5.2.12 Module monitoring interval: Provides the interval between the monitoring and re-monitoring of the hot deployment monitoring mechanism.

6. Deployment mode description: Suppose a system directory (such as c:\system) has a platform directory (such as module) containing each module. If there is a module, it is placed in a directory of MA. The deployment mode (Module, Package, Operation), the directory structure hierarchy and its module name (entity name) are presented as follows:

6.1 Module mode: The platform directory contains a layer of directories. All related files of the module are placed in this directory. The directory structure deployed in this way is system directory + platform directory + the module directory. For example, the directory structure is c:\system\module\MA, the module name of the module is: MA, and the name of the service platform (if S1), the module name is: S1.MA.

6.2 Package mode: The platform directory contains a second-level directory. All related files of the module are placed in the second-level directory of the module directory. The directory structure deployed in this way is system directory + platform directory + the module directory. One level directory + the second level directory of the module directory. For example, the directory structure can be c:\system\module\X\MA, and the module name of the module is: X.MA. If the service platform name (if S1), the module name is: S1.X.MA.

6.3 Operation mode: The platform directory contains three levels of directories. All related files of the module are placed in the third level directory of the module directory. The directory structure deployed in this way is system directory + platform directory + the module directory. One level directory + the second level of the module directory + the third of the module directory Layer directory. For example, the directory structure can be c:\system\module\X\Y\MA, the module name of the module is: XYMA, and the service platform name (if S1), the module name is :S1.XYMA.

Note: Module classification management is achieved by naming the module name of the multi-layer directory structure provided by the deployment mode; it is also possible to establish the name of the thermal deployment module associated with the module, such as S1.X.1 and S2.X. 2, can be regarded as different versions of the X module under different platforms.

7. Service platform directory description (please refer to the fourth figure: service platform directory structure diagram):

7.1 System Directory/Platform Directory: Name of the system directory and platform directory set by the service platform configuration file parameters. Each module is in the platform directory.

7.2 Module Catalog: A directory for the related files of a module.

7.2.1 Module program collection: A collection of applications for the module, such as business logic programs, data access objects (DAO), and so on.

7.2.2 Hot Deployment Version File: Provides the name (logical name) and version of the hot deployment module (Note: The name of the hot deployment module is used to associate the same function module, and is regarded as the same module; the version is used to set the Module version).

7.2.3 Module related file directory: that is, the directory where the module configuration file, multi-language file, etc. are stored.

7.2.4 Module file collection: set the file for the module, multi-language file, and so on.

7.2.5 Module Library Directory: A directory that provides only the reference libraries required for the module.

7.2.6 Module library collection: A library that only provides the reference for the module.

7.3 Shared library directory: A directory for providing reference libraries for each module.

7.3.1 Shared library collection: A library of various types of references that are required for each module.

8. The above is only the preferred embodiment of the present invention, and the method (mechanism) and process are nominalized to illustrate the modification of any noun, but the function is similar or the equal change and modification according to the scope of the patent application of the present invention. All should fall within the scope of the present invention.

Claims (3)

A load balancing splitter that provides a multi-split strategy includes: a selector for configuring a splitting policy, dispatching a request, and configuring a splitting policy, mainly according to a service platform service category or a memory inventory of a service platform according to a service platform The maximum number of requests, the minimum number of requests, or the minimum number of requests for processing, or the combination of the above-mentioned shunting strategies, or the auxiliary module service category, or the latest version, or the specified version, or the above a platform registration center that provides information on the login of the service platform or the synchronization of the service platform information to provide information on the selector diversion strategy, or the recording and synchronization of the module information to achieve the module service category and the latest version. , the specified version of the shunt. The method for synchronizing the service platform or the module information according to the multi-split strategy described in Item 1 of the request includes: transmitting the platform information through the web server by means of a regular or irregular method, including: Platform name, status, service platform memory inventory, service platform address, service platform security quantification, module deployment estimate, request overload security quantification, request deadline quantification, and module monitoring interval, or module information, including : module name (entity name), version, module status, total number of pending requests, total number of pending requests, hot deployment module name (logical name), actual deployment required by the module; or upon request , update/synchronize the number of requests, request processing of the number of pens in a platform registration center; or update/synchronize the service platform or module information in a platform registration center in response. For the service platform service category as described in item 1 of the claim, the method for achieving a specific execution environment includes: by setting a service platform in advance to set the amount of memory to be executed and the core of the CPU or CPU, The request information is accompanied by the service category name and is mainly compared with the service platform name, supplemented by the module name comparison, or with other distribution strategies to find out the service platform to dispatch the request.