TWI584654B - Method and system for optimization service - Google Patents

Description

Computer system for optimizing service and method thereof

The present invention is a service optimization computer system and method thereof. Currently, the method is implemented in Java 2 Platform (Enterprises Edition, J2EE) (but not limited to any programming language), and is applied to cloud technology and platform. 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. Cloud computing The essence of 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 lower 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 based on 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. , is a collection of functions; the platform module is accessed by the same session for multiple independent modules (subsystems). 1.2 Known similar inventions, as disclosed in the patent publication No. 091024413, the Java technology used is an EJB in J2EE, including so-called Session Beans and Entity Beans, and the program flow is pre-defined in the database. Direct access to the data in the database to execute the service program unit corresponding to each transaction process. Although the invention solves the problem of hot deployment, it is based on the EBJ-based development method, which is generally known. Performance is a worry, so there are very few development methods using EJB and SSH, Struts2, Spring, Hibernate development architecture, which is also the mainstream of the current development system. Therefore, the practicality of the invention has been poor. 1.3 A similarly known invention is disclosed in the publication No. 201142708, the proposed method of the invention comprising: (1) setting a first service processing engine and a second service processing engine for processing core services in a software system, the first service The processing engine is connected to the corresponding first service rule storage unit, and the second service processing engine is connected to the corresponding second service rule storage unit; (2) setting one of the first service processing engine and the second service processing engine to be in an operating state, The other is in a waiting state; (3) when the processing setting of the software system changes, updating the processing setting corresponding to the service processing engine in the waiting state; and (4) setting the service processing engine in the waiting state to the running state, and Set the original business processing engine to the wait 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 No. 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, thereby externally 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 discussion of the public number 201142708). ).

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 roulating manner. Because there is not enough information, the load balancing cannot be achieved more accurately. Least Connection For example, if a connection has a large amount of data processing, the load balance of Least Connection is not accurate; then, for example, Round Robin, if there are two hosts, and the number of requests for processing is 100, 10 strokes, 100 strokes, and 10 strokes 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 uses the service platform information and module information provided by the platform registry to provide a shunting strategy for better load balancing. 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 latest version of the module and the shunting strategy of the same function achieves a perpetual service; and a platform monitoring mechanism is added to the shunt to provide a hot backup mechanism and a module library priority mechanism and a module in the service platform. A 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.

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 diversion 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 invention: 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 deployment mechanism: used to deploy various modes (please refer to the deployment mode description), so that designers can plan independent modules according to the function or quantity of modules (single function at most The function is to make the function modules of the system independent of each other and completely exhausted (MECE) thinking principle, so that each module is independent, in order to facilitate transplantation, installation and shorten the 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 respectively installed on different network servers for the sake of the distributed system.

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. Operation status description: 1.1 According to the service platform security quantification and module deployment estimation, the module overload protection 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. Operation 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 synchronize the module information to perform the removal of the module. After completion, set the module status to removed immediately. The module information. 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 transactions required by the business logic for 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 a specific group by means of diversion of services, in other words, by setting a service platform in advance for the amount of memory and CPU or CPU core to be executed, if the request information is included If there is a service category name and the same name as the service platform, it is assigned to the service platform; the other service category is to compare the service category name with the module name to find a suitable set of module names (may be one or more Module name), or dispatch requests based on other offload policies.

Note: The sustainable service is achieved by the shunting strategy according to the latest version of the diversion method. 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 storage capacity 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 start one The security monitoring mechanism periodically checks 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 by the request. run. 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 configuration file: contains the record of each service platform startup and shutdown file path. 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.10 Request Period Quantification: The maximum time that the service platform's request can be executed. 5.2.11 Module monitoring interval: Provides the interval between the monitoring and monitoring mechanism of the hot deployment.

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 level and its module name (entity name) are as follows: 6.1 Module mode: The platform directory contains a layer of directories, all related files of the module 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, and 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 level directory of the module directory. For example, the directory structure can be c:\system\module\X\Y\MA, and the module name of the module is: X.Y.MA, with the service platform name (if S1), the module The group name is: S1.X.Y.MA. 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 picture: service platform directory structure diagram): 7.1 system directory / platform directory: the system directory name and platform directory name set by the service platform configuration file parameters, each module to the platform directory in. 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.

no

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.

Claims (10)

A computer system with uninterrupted service includes: a deployer for deploying each independent module; and a module overload protection mechanism for ensuring that the service platform is free from deployment due to insufficient memory of the service platform; A zero-request monitoring mechanism to prevent interrupts from being executed while the module needs to be redeployed or removed; a hot deployment monitoring mechanism to monitor related file changes in the running module and module catalog or The module is added, and the hot deployment or module removal is performed; a module appointor is used to appoint the module to execute the request according to the module name. A method for uninterrupted service of a computer system includes: reading a parameter value of a service platform configuration file by starting a network server, and completing the initialization of the module to become a running module according to an initial deployment process; And synchronize the service platform and module information to the information recorder, and then start the hot deployment monitoring mechanism to execute the monitoring deployment process, complete the service platform startup, wait for the client request, and request, through a module appointor, The module is obtained from the module name to perform related functions. The method of claim 2, wherein the module overload protection mechanism is used to protect the service platform from being incapable of running due to insufficient memory of the service platform during deployment, and the method comprises the steps of: during initializing the deployment process, The service platform memory inventory must be greater than the service platform security quota plus the module deployment estimate, and can be deployed; when monitoring the deployment process, the service platform memory inventory must be greater than the service platform security quota plus the model The actual amount of deployment required by the group can be deployed. The method of claim 2, wherein the request overload protection mechanism is used to protect the system from being overloaded due to request overload, and further includes: a request timeout over-preservation mechanism, and a request quantity fast-increasing mechanism The method includes the steps of: after requesting the appointment, simultaneously starting a request monitoring program, monitoring the execution time of the request and the memory usage of the request, and interrupting the execution of the request if the request deadline is quantified or the overload protection is requested. And according to the setting of the security platform of the service platform, the memory of the service platform is periodically compared with the memory of the service platform. If the memory of the service platform is lower than the set security of the service platform, the service platform state is set to be suspended. The method of claim 2, wherein the zero-request monitoring mechanism is used to prevent the request that is still being executed due to the module being required to be redeployed or removed, and the method includes the step of: when requesting, Requesting the total number of pending requests in the module information recorder, after the module completes the request, before the response, the total number of pending requests in the module information recorder is deducted from the request, and removed. Or when redeploying, the total number of pending requests for this module must be zero and can be redeployed or removed. A computer system for optimizing services includes: a computer system as claimed in claim 1 and a message notifier for logging in or synchronizing platform information and module information in a platform registration center, a module library priority a processor for preferentially obtaining different versions of the same library, and a module classification manager for classifying modules; a shunt for offloading requests, adding an automatic instant (hot) backup mechanism, To automatically start the backup service desk. The system of claim 6, wherein the module classification manager provides at least a two-level directory structure to classify the module name and classify the module. The system of claim 6, wherein the module library priority processor is in the module directory structure, providing the module library directory and the shared library directory, and placing the relevant library to create a library in the deployment process. When you first create a library in the module library directory, and then create a library in the shared library directory. A method for optimizing a computer system includes: reading a parameter value of a service platform configuration file by starting a network server, completing an initialization of the module according to an initial deployment process, and becoming a running module, and Synchronize the service platform and module information to the information logger, and then start the hot deployment monitoring mechanism to perform the monitoring and deployment process, complete the service platform startup, and log in or synchronize the platform information and module information to a network server platform. a registration center for the web server to send a request to the service platform, or for the network server's splitter to dispatch requests to the service platform according to the latest version of the offload or other offload policies (excluding mutual combination and specified version) . The method of claim 9, further comprising an automatic instant (hot) backup method comprising the process of: adding a platform monitoring mechanism to a router to monitor the status of the service platform, if the service of the power splitter When the status of the platform is that the quantity in the service is lower than the service platform service quantity, a backup service platform startup profile is started, so that a backup service platform registers with the platform registration center to complete the registration for the splitter to dispatch the request.