1. A method of system deployment, comprising:

acquiring a target deployment information set; wherein, the target deployment information set comprises a program package and characteristic parameters of a target subsystem;

determining at least one target service node for deploying the target subsystem under the condition that the target subsystem is determined to be a newly added subsystem according to the characteristic parameters of the target subsystem; the target service node is a service node of an undeployed subsystem;

deploying the target subsystem into the at least one target service node according to the program package of the target subsystem;

registering the at least one target serving node with a general routing node.

2. The method of claim 1, after obtaining the target deployment information set, further comprising:

under the condition that the target subsystem is determined not to be the newly added subsystem according to the characteristic parameters of the target subsystem, stopping each service node corresponding to the running subsystem;

determining at least one target service node deploying the target subsystem; the target service node is a service node which is historically deployed by a target subsystem;

deploying the target subsystem into the at least one target service node according to the program package of the target subsystem;

registering the at least one target service node with a general routing node;

and starting each service node corresponding to the at least one target service node and the running subsystem.

3. The method of claim 1, wherein the characteristic parameters of the target subsystem comprise: the target subsystem name and the number of the required service nodes further comprise, after the target deployment information set is obtained:

acquiring subsystem information running on the total routing node;

and determining whether the target subsystem is a newly added subsystem or not according to the name of the target subsystem and the information of the running subsystem.

4. The method of claim 1, wherein the characteristic parameters of the target subsystem further comprise: the target gray-scale strategy further comprises, after acquiring the target deployment information set:

writing the target subsystem name and the target gray strategy into a gray strategy table of a target database; wherein the gray policy table comprises: the system comprises a strategy ID, a subsystem name, a gray level control field, a control dictionary value, a user gray level association table and a service node gray level association table, wherein the user gray level association table comprises the user ID and the strategy ID, and the service node gray level association table comprises the service node IP address and the strategy ID.

5. The method of claim 4, further comprising, after registering the at least one target serving node with a general routing node:

under the condition that the total routing node receives a webpage request sent by a target user, determining a target user ID and a subsystem name according to the webpage request;

acquiring the gray level strategy table;

determining a target strategy ID of a gray strategy to be adopted by utilizing the target user ID, the subsystem name and the gray strategy table;

determining a service node corresponding to the target strategy ID according to the target strategy ID and the gray strategy table;

and forwarding the webpage request to a service node corresponding to the target policy ID.

6. The method of claim 1, further comprising, after registering the at least one target serving node with a general routing node:

determining a subsystem name according to a webpage request when the total routing node receives the webpage request sent by a target user;

acquiring a currently registered service node set through the total routing node;

traversing the currently registered service node set, and determining a service node corresponding to the subsystem name;

and forwarding the webpage request to a service node corresponding to the subsystem name.

7. The method of claim 1, further comprising, after registering the at least one target serving node with a general routing node:

under the condition that the total routing node receives a webpage request sent by a target user, forwarding the webpage request to a rendering service node;

the rendering service node acquires an initial html file and a JS code file according to the message of the webpage request; the initial html file is an html file of an unrendered interface;

the rendering service node renders the initial html file by analyzing the JS code file to obtain a rendered html page;

and feeding back the rendered html page to the target user.

8. The method of claim 1, further comprising, after registering the at least one target serving node with a general routing node:

the general routing node requests the checking interface of each registered service node according to a preset time interval;

taking the service nodes which can not establish connection with the general routing node as abnormal service nodes to obtain an abnormal service node set;

and disconnecting the general routing node from each abnormal service node in the abnormal service node set.

9. The method of claim 1, further comprising, after registering the at least one target serving node with a general routing node:

acquiring traffic load information of the total routing node;

and transversely increasing the number of the total routing nodes under the condition that the flow load of the total routing nodes reaches a preset threshold value according to the flow load information.

10. A system deployment apparatus, comprising:

the acquisition module is used for acquiring a target deployment information set; wherein, the target deployment information set comprises a program package and characteristic parameters of a target subsystem;

the determining module is used for determining at least one target service node for deploying the target subsystem under the condition that the target subsystem is determined to be a newly added subsystem according to the characteristic parameters of the target subsystem; the target service node is a service node of an undeployed subsystem;

the deployment module is used for deploying the target subsystem to the at least one target service node according to the program package of the target subsystem;

a registration module to register the at least one target service node with a general routing node.

11. A system deployment device comprising a processor and a memory for storing processor-executable instructions which, when executed by the processor, implement the steps of the method of any one of claims 1 to 9.

12. A computer-readable storage medium having stored thereon computer instructions which, when executed, implement the steps of the method of any one of claims 1 to 9.

Background

As the hierarchy for front-end web items becomes increasingly large, the number of systems and the number of codes increases dramatically. In the prior art, a single-page-application (single-page-application) architecture is usually adopted at the front end, when a plurality of subsystems are deployed, the subsystems are linked with each other complexly, various pages need to be nested, and the development and deployment cost is high. When a subsystem page is added on the basis of the original system, a set of corresponding front-end subsystem codes needs to be added by developers, and because the front-end framework of the original system is possibly incompatible with the front-end framework of the new subsystem but needs to be deployed on the same front-end page server, the developers need to spend a lot of time to modify the system codes to enable the subsystems to have mutual compatibility. Therefore, the technical scheme in the prior art cannot efficiently realize the development and deployment of the webpage front-end subsystem.

In view of the above problems, no effective solution has been proposed.

Disclosure of Invention

The embodiment of the specification provides a system deployment method, a system deployment device and system deployment equipment, and aims to solve the problem that development and deployment of a webpage front-end subsystem cannot be efficiently realized in the prior art.

An embodiment of the present specification provides a system deployment method, including: acquiring a target deployment information set; wherein, the target deployment information set comprises a program package and characteristic parameters of a target subsystem; determining at least one target service node for deploying the target subsystem under the condition that the target subsystem is determined to be a newly added subsystem according to the characteristic parameters of the target subsystem; the target service node is a service node of an undeployed subsystem; deploying the target subsystem into the at least one target service node according to the program package of the target subsystem; registering the at least one target serving node with a general routing node.

An embodiment of the present specification further provides a system deployment apparatus, including: the acquisition module is used for acquiring a target deployment information set; wherein, the target deployment information set comprises a program package and characteristic parameters of a target subsystem; the determining module is used for determining at least one target service node for deploying the target subsystem under the condition that the target subsystem is determined to be a newly added subsystem according to the characteristic parameters of the target subsystem; the target service node is a service node of an undeployed subsystem; the deployment module is used for deploying the target subsystem to the at least one target service node according to the program package of the target subsystem; a registration module to register the at least one target service node with a general routing node.

The present specification also provides a system deployment device, comprising a processor and a memory for storing processor-executable instructions, which when executed by the processor implement the steps of any one of the method embodiments of the specification.

The present specification embodiments also provide a computer readable storage medium having stored thereon computer instructions which, when executed, implement the steps of any one of the method embodiments of the specification embodiments.

The embodiment of the present specification provides a system deployment method, which may obtain a target deployment information set, where the target deployment information set may include a package and feature parameters of a target subsystem. And under the condition that the target subsystem is determined to be the newly added subsystem according to the characteristic parameters of the target subsystem, determining at least one target service node for deploying the target subsystem, wherein the target service node can be a service node which has not deployed the subsystem. The target subsystem can be deployed to the at least one target service node according to the program package of the target subsystem, so that different subsystems can be separately deployed to different service nodes, codes of the subsystems are isolated, the coupling degree between the subsystems is reduced, developers only need to consider codes in the newly added subsystems, and the workload of the developers is effectively simplified. Furthermore, the at least one target service node is registered in the total routing node, so that unified management can be performed through the total routing node, the system can be put into deployment to be simplified and unified, and development and deployment of the webpage front-end subsystem can be efficiently realized.

Drawings

The accompanying drawings, which are included to provide a further understanding of the embodiments of the disclosure, are incorporated in and constitute a part of this specification, and are not intended to limit the embodiments of the disclosure. In the drawings:

FIG. 1 is a schematic diagram illustrating steps of a system deployment method provided in accordance with an embodiment of the present disclosure;

fig. 2 is a schematic structural diagram of a cluster abatement system provided according to an embodiment of the present description;

fig. 3 is a schematic structural diagram of a system deployment device provided according to an embodiment of the present description;

fig. 4 is a schematic structural diagram of a system deployment device provided according to an embodiment of the present specification.

Detailed Description

The principles and spirit of the embodiments of the present specification will be described with reference to a number of exemplary embodiments. It should be understood that these embodiments are presented merely to enable those skilled in the art to better understand and to implement the embodiments of the present description, and are not intended to limit the scope of the embodiments of the present description in any way. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

As will be appreciated by one skilled in the art, implementations of the embodiments of the present description may be embodied as a system, an apparatus, a method, or a computer program product. Therefore, the disclosure of the embodiments of the present specification can be embodied in the following forms: entirely hardware, entirely software (including firmware, resident software, micro-code, etc.), or a combination of hardware and software.

Although the flow described below includes operations that occur in a particular order, it should be appreciated that the processes may include more or less operations that are performed sequentially or in parallel (e.g., using parallel processors or a multi-threaded environment).

Referring to fig. 1, the present embodiment may provide a system deployment method, which may be applied to a distributed system. The system deployment method can be used for separately deploying front-end pages of different subsystems to different service nodes, isolating codes of the subsystems and reducing the coupling degree between the subsystems. The system deployment method may include the following steps.

S101: acquiring a target deployment information set; the target deployment information set comprises a program package and characteristic parameters of the target subsystem.

In this embodiment, a target deployment information set may be obtained. The target deployment information set may be a related information set of a subsystem to be deployed, and the target deployment information set may include a program package of the target subsystem and a feature parameter of the target subsystem. The program package of the target subsystem may be a compressed package or a file, which may be determined according to actual situations, and this is not limited in this embodiment of the present specification.

In this embodiment, after the developer has developed the project code of the subsystem, the developer can compile the code and package it into zIP (compressed package). The developer may enter the service management and control center page, upload the program zIP package of the subsystem, and fill in the feature parameters of the subsystem in the service management and control center page. By clicking the submit button, the developer can submit the program zIP package of the subsystem and the feature parameters of the subsystem and generate a deployment request at the same time.

In this embodiment, the deployment request may include the program zIP package of the subsystem and the feature parameters of the subsystem, and the deployment request may be put into a thread to wait for processing. Correspondingly, when the server receives the deployment request, the server may analyze and acquire the target deployment information set in the target deployment request under the condition that it is determined that the deployment request can be currently processed.

In this embodiment, the characteristic parameters of the target subsystem may be used to characterize attribute information of the target subsystem. In some embodiments, the characteristic parameters may include: subsystem name, number of required nodes, gray policy, subsystem description, version number, etc., it is understood that the above feature parameters may also include other information, such as: the specific items such as the names of the items may be determined according to actual situations, and the examples in this specification do not limit the specific items.

S102: determining at least one target service node for deploying the target subsystem under the condition that the target subsystem is determined to be a newly added subsystem according to the characteristic parameters of the target subsystem; the target service node is a service node of an undeployed subsystem.

In the embodiment, since the front end adopts a single-page-application architecture, when a plurality of subsystems are deployed, the subsystems are linked with each other complicatedly, various pages need to be nested, the development and deployment costs are high, and many codes have high repetition degree, are coupled with each other and have poor maintainability. Therefore, the front-end pages of the subsystems can be separately deployed to the servers, and one server corresponds to one service node.

In this embodiment, it may be determined in advance according to the characteristic parameter of the target subsystem whether the target subsystem is a newly added subsystem, and if the target subsystem and the currently operating subsystem are renamed, it indicates that the target subsystem is not the newly added subsystem, otherwise, it indicates that the target subsystem is the newly added subsystem.

In this embodiment, when the target subsystem is determined to be the newly added subsystem, at least one target service node to which the target subsystem is deployed may be determined. Since different subsystems need to be deployed to different service nodes, the target service node may be a service node to which a subsystem is not deployed, and the target service node may be a newly added service node.

In this embodiment, the number of target service nodes may be determined according to the number of service nodes required by the target subsystem, so as to add a corresponding number of service nodes and obtain the target service node. In some embodiments, the number of target service nodes may also be determined according to the number of service nodes available in the current system, so as to obtain the target service node. Of course, the method for determining the target service node is not limited to the above example, and other modifications may be made by those skilled in the art within the spirit of the embodiments of the present disclosure, but all embodiments are within the scope of the embodiments of the present disclosure as long as the functions and effects achieved by the embodiments of the present disclosure are the same or similar to the embodiments of the present disclosure.

S103: and deploying the target subsystem to at least one target service node according to the program package of the target subsystem.

In this embodiment, the target subsystem may be deployed to the at least one target service node according to a package of the target subsystem, so that the at least one service node may all execute the function of the target subsystem.

S104: at least one target serving node is registered with the general routing node.

In this embodiment, at least one target service node may be registered in the total routing node, so that when a user accesses the system, the total routing node is accessed to obtain a front-end page resource to display a first screen (the first screen refers to a first page accessed by the user), and the total routing node is used to uniformly schedule a request submitted by the user to forward the request to a corresponding service node for processing. Therefore, the system deployment can be simplified and unified, and developers can complete one-key deployment by submitting a program package only by considering codes in the newly added subsystems. The method has the advantages of simplifying the treatment of the front end of the webpage, having clear logic and high maintainability, and solving the problem of high development and deployment cost of the subsystem.

In this embodiment, different front end frames may be used between the subsystems, for example: subsystem a uses the fact frame and subsystem B uses the Vue frame. Therefore, different frames can be used according to requirements to obtain the advantages of the different frames, and the historical items can be integrated without changing frame codes and modifying the historical items. Different frameworks can be isolated by JS (JavaScript), CSS (Cascading Style Sheets) resources to prevent codes from polluting each other. The corresponding subsystem can be controlled to be exposed by monitoring the change of URL (Uniform Resource Locator), for example: http:// a.com/system mA will show subsystem A and http:// a.com/system B will show subsystem B.

In this embodiment, fact is a JavaScript library for constructing a user interface, and Vue is a progressive framework for constructing a user interface. JavaScript is a high-level, multi-modal, interpreted programming language, a prototype-based, function-antecedent language that supports object-oriented programming, imperative programming, and functional programming.

From the above description, it can be seen that the embodiments of the present specification achieve the following technical effects: a target deployment information set may be obtained, where the target deployment information set may include a package and feature parameters of a target subsystem. And under the condition that the target subsystem is determined to be the newly added subsystem according to the characteristic parameters of the target subsystem, determining at least one target service node for deploying the target subsystem, wherein the target service node can be a service node which has not deployed the subsystem. The target subsystem can be deployed to the at least one target service node according to the program package of the target subsystem, so that front-end pages of different subsystems can be separately deployed to different service nodes, codes of the subsystems are isolated, the coupling degree between the subsystems is reduced, developers only need to consider codes in the newly-added subsystems, and the workload of the developers is effectively simplified. Furthermore, the at least one target service node is registered in the total routing node, so that unified management can be performed through the total routing node, the system can be put into deployment to be simplified and unified, and development and deployment of the webpage front-end subsystem can be efficiently realized.

In one embodiment, after obtaining the target deployment information set, the method may further include: and under the condition that the target subsystem is determined not to be the newly added subsystem according to the characteristic parameters of the target subsystem, stopping each service node corresponding to the running subsystem. At least one target service node to deploy the target subsystem may be determined; and the target service node is a service node which is historically deployed by the target subsystem. Further, the target subsystem may be deployed to the at least one target service node according to the package of the target subsystem. And registering the at least one target service node to a total routing node, and starting each service node corresponding to the at least one target service node and the running subsystem.

In this embodiment, if the subsystem is not a newly added subsystem, the service nodes corresponding to the currently operating subsystem may be stopped. And judging whether each service node corresponding to the subsystem needing shutdown is completely shutdown, and decompressing the program package of the target subsystem and deploying the program package to the at least one target service node under the condition of determining that all the shutdown is completely completed.

In this embodiment, after determining that at least one target service node is successfully registered in the total routing node, each service node corresponding to the at least one target service node and the running subsystem may be started, so as to complete deployment of the target subsystem.

In this embodiment, since the target subsystem is not a newly added subsystem, in order to ensure complete provision of the service, the target subsystem may be directly deployed to a service node where the target subsystem is historically deployed. Of course, it can be understood that when the number of service nodes historically deployed by the target subsystem is not enough, a new service node may be added to deploy the target subsystem. The specific situation can be determined according to actual situations, and the embodiment of the present specification does not limit the specific situation.

In one embodiment, the characteristic parameters of the target subsystem may include: the target subsystem name and the number of the required service nodes may further include, after the target deployment information set is acquired: and acquiring the information of the running subsystem on the total routing node, and determining whether the target subsystem is a newly added subsystem or not according to the name of the target subsystem and the information of the running subsystem.

In this embodiment, since all the service nodes deploying the subsystems need to be registered in the total routing node, the subsystem information running on the total routing node can be acquired. The subsystem information may include a subsystem name. It is understood that the subsystem information may also include other information, such as: corresponding service node, version number, etc. The specific situation can be determined according to actual situations, and the embodiment of the present specification does not limit the specific situation.

In this embodiment, if there is a subsystem with the same name as the target subsystem in the running subsystem information, it indicates that the target subsystem is not a newly added subsystem and has been deployed historically. Otherwise, the target subsystem is the newly added subsystem.

In one embodiment, the characteristic parameters of the target subsystem may further include: the target grayscale policy, after acquiring the target deployment information set, may further include: writing the target subsystem name and the target gray strategy into a gray strategy table of a target database; wherein, the gray policy table may include: the system comprises a strategy ID, a subsystem name, a gray level control field, a control dictionary value, a user gray level association table and a service node gray level association table, wherein the user gray level association table comprises the user ID and the strategy ID, and the service node gray level association table comprises the service node IP address and the strategy ID.

In this embodiment, the characteristic parameters of the target subsystem may further include: target grayscale policy, which may be used to describe what requests should be routed to the grayscale version (grayscale server), grayscale publication refers to a way of publication that enables smooth transitions between black and white, for example: and (3) continuing to use A by a part of users, starting to use B by a part of users, and gradually expanding the range and migrating all the users to the B if the users do not have any objection to the B. The stability of the whole system can be ensured by gray scale release, and problems can be found and adjusted in the initial gray scale so as to ensure the influence degree of the gray scale.

In this embodiment, each gray policy may correspond to a policy ID (identity), and one policy ID may uniquely determine one gray policy. IP addresses are collectively referred to as internet protocol addresses, which is a way to address hosts on the internet. The user ID may be a unique identifier of the user, for example: user name, identification number, etc. The specific situation can be determined according to actual situations, and the embodiment of the present specification does not limit the specific situation.

In this embodiment, the target database may be a database used by the total routing node to store data, or may also be a database used by a distributed system to store data, which may be determined specifically according to an actual situation, and this is not limited in this specification.

In one embodiment, after registering the at least one target serving node with the general routing node, the method may further include: and under the condition that the total routing node receives a webpage request sent by a target user, determining the ID and the subsystem name of the target user according to the webpage request. And acquiring the gray level strategy table, and determining a target strategy ID of the gray level strategy to be adopted by using the target user ID, the subsystem name and the gray level strategy table. Further, a service node corresponding to the target policy ID may be determined according to the target policy ID and the grayscale policy table, and the web page request may be forwarded to the service node corresponding to the target policy ID.

In the embodiment, when the gray scale user accesses the gray scale function, the user needs to access a plurality of back-end servers for multiple times to obtain the gray scale labels, the management is complex, and the gray scale strategy is not completely credible due to the front end of the source of the gray scale mark and can be cracked by the user. Specifically, after a user enters a page, a first request may obtain a gray label belonging to the user and corresponding to a back-end server, the returned gray label may be placed in a cache of a client browser, and a subsequent request may forward the request to the corresponding gray-end server according to the gray label cached in the browser. In this scenario, the user can switch the grayscale state by manually changing the browser cache, so that the system risks grayscale management. Therefore, in order to solve the problem, the total routing node can uniformly process the web page requests submitted by the users, the session IDs of the login users in the web page requests can be obtained to obtain the grayscale policies corresponding to the users, and finally the requests are forwarded to the corresponding grayscale servers. The method avoids the possibility that a user modifies the gray label, the user cannot control the gray state of the user, and the problem of low safety of the gray scheme is solved.

In this embodiment, when receiving a web page request, the total routing node may analyze an HTTP message of the web page request to obtain a user session ID (generally, a session ID), a subsystem name, and a URL. The target user ID may be obtained from the backend server according to the user session ID. Among them, HTTP (hypertext transfer protocol) is a transfer protocol for transferring hypertext from a web server to a local browser.

In this embodiment, the target policy ID of the grayscale policy to be adopted may be determined by querying the target database to obtain the grayscale policy table, and thus using the target user ID, the subsystem name, the URL, and the grayscale policy table. Further, a service node corresponding to the target policy ID may be determined according to the target policy ID and the service node gray level association table. The service node corresponding to the target policy ID may be a grayscale server.

In this embodiment, the web page request may be forwarded to a service node corresponding to the target policy ID, for example: the gray level is made according to the region to which the user belongs, only the user in the region A can access the function A, and the user request in the region A can be forwarded to the service node with the function A according to the region gray level strategy through the embodiment.

In one embodiment, after registering the at least one target serving node with the general routing node, the method may further include: and determining the subsystem name according to the webpage request under the condition that the total routing node receives the webpage request sent by the target user. And acquiring a currently registered service node set through the total routing node, traversing the currently registered service node set, and determining a service node corresponding to the subsystem name. Further, the web page request may be forwarded to a service node corresponding to the subsystem name.

In this embodiment, when receiving an external web page request, the total routing node may parse the request URL of the web page request from the web page request to obtain the subsystem name. Further, the currently registered service node set may be obtained through the total routing node, and the currently registered service node set is traversed. If a service node with the same name as the subsystem exists in the currently registered service node set, it is indicated that the service node is the service node corresponding to the subsystem, and the web page request may be forwarded to the service node corresponding to the subsystem name.

In this embodiment, whether traversal of the currently registered service node set is completed may be determined in real time, and if the service node corresponding to the subsystem name is not determined yet when traversal is completed, the web page request 404 packet may be returned. The 404 message may be used to indicate that the accessed specified resource does not exist, so as to perform error notification.

In one embodiment, after registering the at least one target serving node with the general routing node, the method may further include: and under the condition that the total routing node receives a webpage request sent by a target user, forwarding the webpage request to a rendering service node. The rendering service node can acquire an initial html file and a JS code file according to the message requested by the webpage; and the initial html file is an html file of an unrendered interface. Further, the rendering service node renders the initial html file by analyzing the JS code file to obtain a rendered html page, and feeds the rendered html page back to the target user.

Generally, the JS codes are rendered into html pages by the pages by relying on a client browser, and the first screen needs a large amount of computer computing power to render, so that the browser can whitely display for a long time, even is stuck, and the user experience is reduced. In the embodiment, the rendering calculation of the client browser can be migrated to the rendering service node with strong computing power, so that the use pressure of the hardware of a user computer is reduced, the rendering service node can be brought into cluster management, the system crash caused by the blocking of the rendering server during the flow peak is prevented, and the problem of low loading speed of the first screen is solved.

In this embodiment, the rendering service node may analyze a message of the web page request, and the message of the web page request may include a target URL and a service parameter message. The initial html file and the JS code file of the service node can be obtained according to the target URL, wherein the initial html file is an html file of an unrendered interface. The rendering service node can analyze the JS codes and render the html file, so that the rendered html page can be efficiently returned to the target user. Html (Hyper Text Markup Language) is an application under standard universal Markup Language.

In one embodiment, after registering the at least one target serving node with the general routing node, the method may further include: the master routing node requests the checking interface of each registered service node according to a preset time interval, the service node which cannot establish connection with the master routing node is used as an abnormal service node to obtain an abnormal service node set, and the master routing node is disconnected with each abnormal service node in the abnormal service node set.

In this embodiment, the health check may be performed on each service definition by the master routing node according to a preset time interval, and specifically, the master routing node may request a check interface of each registered service node according to the preset time interval. The preset time interval may be a value greater than 0, for example: the time period may be 30 seconds, 10 minutes, 1 hour, etc., and may be determined according to actual conditions, which is not limited in the examples of the present specification.

In this embodiment, each health check may generate a normal service node set and an abnormal service node set, and the normal service node set and the abnormal service node set obtained when the health check is initially performed for the first time may be stored in the cache. Subsequently, when health check is performed each time, the normal service node set and the abnormal service node set in the cache can be obtained first, the normal service node set is traversed, whether the current service node in the normal service node set can be connected with the general routing node or not is judged, if not, the service node is removed from the normal service node set, and the service node is added into the abnormal service node set.

In this embodiment, the connection between the master routing node and each abnormal service node in the abnormal service node set may be disconnected, so that the master routing node does not forward the user request to a service node in the abnormal service node set any more in the following.

In this embodiment, the abnormal service node set obtained from the cache may also be traversed, and whether the currently traversed service node in the abnormal service node set can establish a connection with the total routing node is determined, if yes, the service node is removed from the abnormal service node set, and the service node is added to the normal service node set; if not, the service node is continuously kept in the abnormal service node set, so that a normal service node set and an abnormal service node set of the health check can be obtained. Further, the normal service node set and the abnormal service node set in the cache may be updated to store the latest normal service node set and abnormal service node set.

In one embodiment, after registering the at least one target serving node with the general routing node, the method may further include: and acquiring the traffic load information of the total routing node, and transversely increasing the number of the total routing nodes under the condition that the traffic load of the total routing node reaches a preset threshold value according to the traffic load information.

In this embodiment, since there are many service nodes for deploying the subsystem, one server is required to upload the program and input the start command each time the update program is deployed, so that the workload of deploying the program is large. Therefore, it is necessary to perform health check and gray level total control on the service nodes through the total routing node, detect abnormal service nodes in time, and dynamically expand or reduce the capacity of the server nodes according to the real-time traffic load information. Therefore, all nodes can be brought into management and control through cluster management, a system program can be deployed by one key, the problem of large operation and maintenance workload of the deployed program is solved, and the distributed management for the front end of the webpage is realized.

In this embodiment, traffic load information of the current total routing node may be obtained, where the traffic load information may include the number of concurrent accesses per second, a CPU (central processing unit) frequency, an amount of occupied memory, and the like. Further, it may be determined whether the traffic load of the total routing node reaches a preset threshold, for example: whether the number of concurrent accesses reaches a preset threshold 10000. Preset thresholds can be set for different flow load parameters, and specific values of the preset thresholds can be determined according to actual conditions, which is not limited in the embodiments of the present specification.

In this embodiment, when any one of the traffic load parameters in the traffic load information reaches the preset threshold, it indicates that the total routing node is in an overloaded state, and the number of the total routing nodes can be increased horizontally, so as to reduce the traffic load pressure of the total routing node.

In one scenario example, a cluster abatement system may be as shown in fig. 2, and may include: the system comprises a service management and control center 201, a total routing node 202, a rendering service node 203, a service node 204, a health check 205 and a gray total control 206.

In this scenario example, the deployment process of the service management and control center 201 may include:

step 201: the service management and control center obtains the uploaded program package and the subsystem parameters (subsystem name, required node number and gray level strategy).

Step 202: the subsystem name and the grayscale policy are inserted into a grayscale policy table in the target database.

Step 203: and judging whether the uploaded subsystem is a newly added subsystem (whether the uploaded subsystem is renamed with a currently running subsystem).

Step 204: and if the subsystem is not the newly added subsystem, stopping the service node corresponding to the currently running subsystem.

Step 205: and judging whether all service nodes of the subsystem needing to be shut down are shut down completely.

Step 206: and under the condition that all the shutdown is determined to be completed, decompressing and deploying the program package to each service node according to the required number of the nodes.

Step 207: the service node where the program is deployed is registered with the general routing node.

Step 208: and starting each stopped service node.

In the present scenario example, the flow of the gray master 206 may include:

step 301: the master routing node receives the web page request.

Step 302: the HTTP message of the webpage request is analyzed, and a user session ID (usually a session ID), a subsystem name and a URL (uniform resource locator) are obtained from the HTTP message.

Step 303: and acquiring the user ID from the back-end server according to the user session ID.

Step 304: and inquiring a database, and inquiring a gray level policy table in the database according to the user ID, the subsystem name and the URL.

Step 305: and forwarding the webpage request to the corresponding service node according to the corresponding gray level strategy. Specifically, the used subsystem name (e.g., system _ a) may be obtained according to the URL, then the user grayscale association table and the grayscale policy table may be searched according to the user ID, the grayscale control field (e.g., area) corresponding to the user ID may be searched, if the region dictionary value of the user is 01, the service node grayscale association table may be searched according to the policy of the grayscale policy table in which the system name is system _ a, the control field is area, and the control dictionary value is 01, so as to obtain the IP of the service node, and forwarding is performed according to the IP. If the gray level is made according to the region to which the user belongs, and only the user in the region A can access the function A, the user request in the region A is forwarded to the service node with the function A according to the region gray level strategy.

In this scenario example, the processing flow of the rendering service node 203 may include:

step 401: the master routing node receives the web page request.

Step 402: the general routing node forwards the web page request to the rendering service node.

Step 403: and the rendering service node analyzes the message of the webpage request, and acquires an empty html file (html file of an unrendered interface) and a JS code file of the service node according to the URL in the message of the webpage request.

Step 404: and the rendering service node analyzes the JS codes and renders the html file.

Step 405: and returning the html page with the finished rendering to the user.

In this scenario example, the health check flow of health check node 205 may include:

step 501: the general routing node periodically requests the health check interface of each service node, and the timing time can be customized, such as once in 10 minutes.

Step 502: and traversing the normal service node set.

Step 503: and judging whether the currently traversed service node can establish connection with the total routing node.

Step 504: if the connection can not be established, the service node is removed from the normal service node set.

Step 505: and if the connection can be established, adding the service node into the abnormal service node set.

Step 506: and disconnecting the total routing node from the abnormal service node, wherein the total routing node does not subsequently forward the user request to the service node in the abnormal service node set.

Step 507: and traversing the abnormal service node set.

Step 508: and judging whether the currently traversed service node can establish connection with the total routing node.

Step 509: and if the connection can not be established, removing the service node from the abnormal service node set.

Step 510: and adding the service node into the normal service node set.

Step 511: and acquiring the traffic load information of the current total routing node, wherein the traffic load information comprises the concurrent access quantity per second, the CPU frequency and the memory occupation quantity.

Step 512: judging whether the flow load reaches a preset threshold value, for example: whether the number of concurrent accesses reaches a preset value 10000.

Step 513: and the number of the total routing nodes is transversely increased, and the flow load pressure of the total routing nodes is reduced.

Based on the same inventive concept, embodiments of the present specification further provide a system deployment apparatus, as described in the following embodiments. Since the principle of the system deployment apparatus for solving the problem is similar to that of the system deployment method, the implementation of the system deployment apparatus can be referred to the implementation of the system deployment method, and repeated details are not repeated. As used hereinafter, the term "unit" or "module" may be a combination of software and/or hardware that implements a predetermined function. Although the means described in the embodiments below are preferably implemented in software, an implementation in hardware, or a combination of software and hardware is also possible and contemplated. Fig. 3 is a block diagram of a structure of a system deployment apparatus according to an embodiment of the present disclosure, and as shown in fig. 3, the system deployment apparatus may include: an obtaining module 301, a determining module 302, a deploying module 303, and a registering module 304, which are described below.

An obtaining module 301, configured to obtain a target deployment information set; wherein, the target deployment information set comprises a program package and characteristic parameters of a target subsystem;

a determining module 302, configured to determine at least one target service node for deploying the target subsystem when the target subsystem is determined to be a newly added subsystem according to the characteristic parameter of the target subsystem; the target service node is a service node of an undeployed subsystem;

a deployment module 303, configured to deploy the target subsystem into the at least one target service node according to the package of the target subsystem;

a registration module 304 may be configured to register the at least one target serving node with a general routing node.

The embodiment of the present specification further provides an electronic device, which may specifically refer to a schematic structural diagram of an electronic device based on the system deployment method provided by the embodiment of the present specification, and the electronic device may specifically include an input device 41, a processor 42, and a memory 43. The input device 41 may be specifically configured to input a target deployment information set. The processor 42 may be specifically configured to obtain a target deployment information set; wherein, the target deployment information set comprises a program package and characteristic parameters of a target subsystem; determining at least one target service node for deploying the target subsystem under the condition that the target subsystem is determined to be a newly added subsystem according to the characteristic parameters of the target subsystem; the target service node is a service node of an undeployed subsystem; deploying the target subsystem into the at least one target service node according to the program package of the target subsystem; registering the at least one target serving node with a general routing node. The memory 43 may be specifically configured to store data such as program packages and characteristic parameters of the target subsystem.

In this embodiment, the input device may be one of the main apparatuses for information exchange between a user and a computer system. The input device may include a keyboard, a mouse, a camera, a scanner, a light pen, a handwriting input board, a voice input device, etc.; the input device is used to input raw data and a program for processing the data into the computer. The input device can also acquire and receive data transmitted by other modules, units and devices. The processor may be implemented in any suitable way. For example, the processor may take the form of, for example, a microprocessor or processor and a computer-readable medium that stores computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, an embedded microcontroller, and so forth. The memory may in particular be a memory device used in modern information technology for storing information. The memory may include multiple levels, and in a digital system, the memory may be any memory as long as it can store binary data; in an integrated circuit, a circuit without a physical form and with a storage function is also called a memory, such as a RAM, a FIFO and the like; in the system, the storage device in physical form is also called a memory, such as a memory bank, a TF card and the like.

In this embodiment, the functions and effects specifically realized by the electronic device can be explained by comparing with other embodiments, and are not described herein again.

Embodiments of the present specification further provide a computer storage medium based on a system deployment method, where the computer storage medium stores computer program instructions, and when the computer program instructions are executed, the computer storage medium may implement: acquiring a target deployment information set; wherein, the target deployment information set comprises a program package and characteristic parameters of a target subsystem; determining at least one target service node for deploying the target subsystem under the condition that the target subsystem is determined to be a newly added subsystem according to the characteristic parameters of the target subsystem; the target service node is a service node of an undeployed subsystem; deploying the target subsystem into the at least one target service node according to the program package of the target subsystem; registering the at least one target serving node with a general routing node.

In this embodiment, the storage medium includes, but is not limited to, a Random Access Memory (RAM), a Read-Only Memory (ROM), a Cache (Cache), a Hard Disk Drive (HDD), or a Memory Card (Memory Card). The memory may be used to store computer program instructions. The network communication unit may be an interface for performing network connection communication, which is set in accordance with a standard prescribed by a communication protocol.

In this embodiment, the functions and effects specifically realized by the program instructions stored in the computer storage medium can be explained by comparing with other embodiments, and are not described herein again.

It will be apparent to those skilled in the art that the modules or steps of the embodiments of the present specification described above may be implemented by a general purpose computing device, they may be centralized on a single computing device or distributed over a network of multiple computing devices, and alternatively, they may be implemented by program code executable by a computing device, such that they may be stored in a storage device and executed by a computing device, and in some cases, the steps shown or described may be performed in an order different from that described herein, or they may be separately fabricated into individual integrated circuit modules, or multiple ones of them may be fabricated into a single integrated circuit module. Thus, embodiments of the present description are not limited to any specific combination of hardware and software.

Although the embodiments herein provide the method steps as described in the above embodiments or flowcharts, more or fewer steps may be included in the method based on conventional or non-inventive efforts. In the case of steps where no causal relationship is logically necessary, the order of execution of the steps is not limited to that provided by the embodiments of the present description. When the method is executed in an actual device or end product, the method can be executed sequentially or in parallel according to the embodiment or the method shown in the figure (for example, in the environment of a parallel processor or a multi-thread processing).

It is to be understood that the above description is intended to be illustrative, and not restrictive. Many embodiments and many applications other than the examples provided will be apparent to those of skill in the art upon reading the above description. The scope of embodiments of the present specification should, therefore, be determined not with reference to the above description, but should instead be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

The above description is only a preferred embodiment of the embodiments of the present disclosure, and is not intended to limit the embodiments of the present disclosure, and it will be apparent to those skilled in the art that various modifications and variations can be made in the embodiments of the present disclosure. Any modification, equivalent replacement, improvement and the like made within the spirit and principle of the embodiments of the present disclosure should be included in the protection scope of the embodiments of the present disclosure.