Nginx load multi-cluster access shunting method and related device

Abstract

The invention discloses an Nginx load multi-cluster access shunting method and a related device, and the method comprises the steps: intercepting and analyzing an Nginx request when a cluster front end accesses an initial page of a system, and obtaining source cluster information; according to the source cluster information, dynamically setting a reverse proxy and a cluster background, and distributing the Nginx request to the cluster background through the reverse proxy; nginx requests of other modules at the front end of the cluster for the initial page of the system are intercepted and analyzed to obtain source cluster information, and the Nginx requests of the other modules are distributed to the background of the cluster through a reverse proxy. According to the method, the Nginx request is analyzed and distributed to the corresponding cluster background through the flow controller in Nginx load balancing so as to ensure that the Nginx request can be distributed to the correct cluster background to be processed under the scene of multi-cluster cross-domain access, and the method is controlled based on the Nginx request, does not depend on users and can cover all the users.

Description

Technical Field

[0001] The present invention relates to the field of servers, and in particular to an Nginx load multi-cluster access distribution method and related devices. Background Art

[0002] With the rapid development of information technology, software business systems often face upgrades and transformations. In traditional system upgrades and releases, online shutdowns need to be announced in advance, which will cause inconvenience to users. At the same time, it is also a great challenge for developers and operation and maintenance personnel. In the process of system upgrade iteration, control the traffic to upgrade cluster services, gradually implement version switching, control the impact of failures within an acceptable range, and reduce the risk of going online. Ensure the safe, stable and reliable operation of the system and improve user experience.

[0003] At present, the commonly used version iteration method is grayscale release. Grayscale release is often used for services based on Nginx load balancing, that is, some users use the existing version of the service, and some users start using the new version, gradually expanding the scope of use, and finally all migrate to the new version. This method switches traffic based on the user dimension and cannot cover all users. At the same time, for systems with multiple modules deployed separately and accessed through domain names, when switching modules, it cannot be ensured that the system is accessed on the same cluster, resulting in request errors. Summary of the invention

[0004] In view of the above problems, the present invention provides an Nginx load multi-cluster access distribution method and related devices that overcome the above problems or at least partially solve the above problems.

[0005] In a first aspect, a method for distributing Nginx load multi-cluster access traffic includes:

[0006] When the cluster front end accesses the system initial page, the traffic controller intercepts and parses the Nginx request to obtain the source cluster information of the Nginx request, wherein the traffic controller is set in the Nginx load balancing;

[0007] According to the source cluster information, dynamically set the reverse proxy and cluster backend, so as to distribute the Nginx request to the corresponding cluster backend through the reverse proxy;

[0008] Intercept the Nginx requests of other modules of the cluster front end for the system initial page, and distribute the Nginx requests of other modules to the corresponding cluster background through the reverse proxy according to the source cluster information of the Nginx requests of other modules.

[0009] Optionally, in some optional implementations, when the cluster front end accesses the system initial page, the traffic controller intercepts and parses the Nginx request to obtain the source cluster information of the Nginx request, including:

[0010] When the cluster front end accesses the system initial page, the traffic controller intercepts the Nginx request of the cluster front end for the system initial page;

[0011] Parsing the header information in the Nginx request;

[0012] The corresponding source cluster information is matched according to the header information.

[0013] Optionally, in some optional implementations, matching corresponding source cluster information according to the header information includes:

[0014] According to the header information, calling the preset rules, determining the cluster front-end source of the Nginx request;

[0015] According to the cluster front-end source, set the cluster flag information of the Nginx request as the source cluster information;

[0016] The cluster flag information of the Nginx request is stored.

[0017] Optionally, in some optional implementations, dynamically setting a reverse proxy and a cluster backend according to the source cluster information so as to distribute the Nginx request to a corresponding cluster backend through the reverse proxy includes:

[0018] According to the stored cluster flag information, dynamically set the reverse proxy and cluster backend corresponding to the cluster flag information, wherein the cluster backend is a cluster that processes Nginx requests with the cluster flag information;

[0019] Through the reverse proxy, the Nginx request is distributed to the cluster backend for processing.

[0020] Optionally, in some optional implementations, intercepting Nginx requests of other modules of the cluster front end for the system initial page, and distributing the Nginx requests of other modules to the corresponding cluster backend through the reverse proxy according to the source cluster information of the Nginx requests of other modules, includes:

[0021] Intercept Nginx requests for the system initial page from other modules at the front end of the cluster;

[0022] Parse the Nginx requests of the other modules to obtain source cluster information of the Nginx requests of the other modules;

[0023] According to the source cluster information, the corresponding reverse proxy is determined, and the Nginx requests of the other modules are distributed to the corresponding cluster backend through the reverse proxy.

[0024] In a second aspect, an Nginx load multi-cluster access distribution device includes: a source cluster information parsing unit, a proxy setting unit, and other request interception units;

[0025] The source cluster information parsing unit is used for the flow controller to intercept and parse the Nginx request when the cluster front end accesses the system initial page, and obtain the source cluster information of the Nginx request, wherein the flow controller is set in the Nginx load balancing;

[0026] The proxy setting unit is used to dynamically set the reverse proxy and the cluster backend according to the source cluster information, so as to distribute the Nginx request to the corresponding cluster backend through the reverse proxy;

[0027] The other request interception unit is used to intercept Nginx requests of other modules of the cluster front end for the system initial page, and distribute the Nginx requests of other modules to the corresponding cluster background through the reverse proxy according to the source cluster information of the Nginx requests of other modules.

[0028] Optionally, in certain optional implementations, the source cluster information parsing unit includes: an Nginx request interception subunit, a header information parsing subunit, and a source cluster information matching subunit;

[0029] The Nginx request interception subunit is used for the flow controller to intercept the Nginx request of the cluster front end for the system initial page when the cluster front end accesses the system initial page;

[0030] The header information parsing subunit is used to parse the header information in the Nginx request;

[0031] The source cluster information matching subunit is used to match the corresponding source cluster information according to the header information.

[0032] Optionally, in some optional implementations, the source cluster information matching subunit includes: a rule calling subunit, a flag information setting subunit and a flag information storage subunit;

[0033] The rule calling subunit is used to call a preset rule according to the header information to determine the cluster front-end source of the Nginx request;

[0034] The flag information setting subunit is used to set the cluster flag information of the Nginx request as the source cluster information according to the cluster front-end source;

[0035] The flag information storage subunit is used to store the cluster flag information requested by the Nginx.

[0036] In a third aspect, a computer-readable storage medium stores a program thereon, and when the program is executed by a processor, the Nginx load multi-cluster access distribution method described in any one of the above items is implemented.

[0037] In a fourth aspect, an electronic device comprises at least one processor, and at least one memory and a bus connected to the processor; wherein the processor and the memory communicate with each other through the bus; and the processor is used to call program instructions in the memory to execute any of the Nginx load multi-cluster access diversion methods described above.

[0038] By means of the above technical scheme, the present invention provides a Nginx load multi-cluster access diversion method and related devices, when the cluster front end accesses the system initial page, the flow controller intercepts and parses the Nginx request to obtain the source cluster information of the Nginx request, wherein the flow controller is set in the Nginx load balancing; according to the source cluster information, the reverse proxy and the cluster background are dynamically set so that the Nginx request is distributed to the corresponding cluster background through the reverse proxy; the Nginx request of other modules of the cluster front end for the system initial page is intercepted, and according to the source cluster information of the Nginx request of other modules, the Nginx request of other modules is distributed to the corresponding cluster background through the reverse proxy. It can be seen from this that the present invention sets a flow controller in the Nginx load balancing, and then parses and distributes the Nginx request to the corresponding cluster background based on the flow controller, so as to ensure that the Nginx request can be distributed to the correct cluster background for processing in the scenario of multi-cluster cross-domain access, and the present invention is based on the Nginx request for control, does not rely on users, can cover all users, and has a wide coverage.

[0039] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented according to the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Various other advantages and benefits will become apparent to those of ordinary skill in the art by reading the detailed description of the preferred embodiments below. The accompanying drawings are only for the purpose of illustrating the preferred embodiments and are not to be considered as limiting the present invention. Moreover, the same reference symbols are used throughout the accompanying drawings to represent the same components. In the accompanying drawings:

[0041] Figure 1 A system architecture diagram of Nginx load balancing provided by the present invention is shown;

[0042] Figure 2 A flow chart of a Nginx load multi-cluster access distribution method provided by the present invention is shown;

[0043] Figure 3 Another Nginx load balancing system architecture diagram provided by the present invention is shown;

[0044] Figure 4 A schematic diagram of the structure of an Nginx load multi-cluster access distribution device provided by the present invention is shown;

[0045] Figure 5 A structural schematic diagram of an electronic device provided by the present invention is shown. DETAILED DESCRIPTION

[0046] With the rapid development of information technology, software business systems often face upgrades and transformations. In traditional system upgrades and releases, online shutdowns need to be announced in advance, which will cause inconvenience to users. At the same time, it is also a great challenge for developers and operation and maintenance personnel. In the process of system upgrade iteration, control the traffic to upgrade cluster services, gradually implement version switching, control the impact of failures within an acceptable range, and reduce the risk of going online. Ensure the safe, stable and reliable operation of the system and improve user experience.

[0047] At present, the commonly used version iteration method is grayscale release. Grayscale release is often used for services based on Nginx load balancing, that is, some users use the existing version of the service, and some users start using the new version, gradually expanding the scope of use, and finally all migrate to the new version. This method switches traffic based on the user dimension and cannot cover all users. At the same time, for systems with multiple modules deployed separately and accessed through domain names, when switching modules, it cannot be ensured that the system is accessed on the same cluster, resulting in request errors.

[0048] The specific system structure of the existing Nginx load balancing, such as Figure 1As shown in the figure, this architecture is often used for trial runs in advance of version releases. When the program accesses, if the access from cluster A is not controlled, it may not be distributed to the background service of cluster A, but may be distributed to the background service of cluster B, resulting in request confusion and possible errors. Similarly, the same is true for cluster B.

[0049] When each module is accessed through an independent domain name, front-end loading confusion may occur. For example, if you are currently in cluster A and want to switch to module 2 for access, it may be distributed to module 2 in cluster B, causing page loading errors, etc.

[0050] The exemplary embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. Although the exemplary embodiments of the present invention are shown in the accompanying drawings, it should be understood that the present invention can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided in order to enable a more thorough understanding of the present invention and to enable the scope of the present invention to be fully communicated to those skilled in the art.

[0051] like Figure 2 As shown, the present invention provides an Nginx load multi-cluster access distribution method, including: S100, S200 and S300;

[0052] S100, when the cluster front end accesses the system initial page, the traffic controller intercepts and parses the Nginx request to obtain the source cluster information of the Nginx request, wherein the traffic controller is set in the Nginx load balancing;

[0053] Optionally, the current application system uses Nginx load balancing to achieve multiple clusters in parallel. Cluster information can be configured in the Nginx load balancer to achieve the purpose of multi-cluster load, so that requests from the front end (such as Figure 1 The front end of cluster A in the example above can be distributed to the backend service (for example, Figure 1 In the cluster A background), the present invention does not limit this.

[0054] Optional, as mentioned above, the main problems with the existing solutions are: after the system is updated, the traffic is switched according to the user dimension, and full coverage cannot be achieved. At the same time, the current system mostly adopts front-end and back-end separation, which is relatively complex in the system and multiple modules are deployed separately. When the resources of the deployment cluster are insufficient, it is often necessary to establish a new cluster separately to meet resource needs. At this time, the same service may exist on different clusters, and different clusters may need requests to flow within the cluster and cannot flow to other clusters. If the router in the middle does not control it, it will not be possible to ensure that the request flows in the same cluster, and cross-domain access to different cluster services will occur, causing business logic errors.

[0055] That is, after the system is updated, Nginx requests that are allowed to access the new system generally access the system initial page of the new system first. Therefore, the flow controller of the present invention can intercept and parse Nginx requests to obtain the information of the cluster front end (i.e., the cluster that issues the Nginx request) (i.e., the source cluster information) for subsequent setting of reverse proxy and cluster information, which is not limited by the present invention.

[0056] Optionally, the traffic controller is set in Nginx load balancing to intercept each Nginx request at the cluster front end, and then parse the source cluster information to distribute traffic. The specific system architecture is as follows: Figure 3 As shown, the present invention is not limited to this.

[0057] Nginx: A high-performance HTTP and reverse proxy web server that also provides services such as IMAP (Internet Message Access Protocol), POP3 (Post Office Protocol-Version 3), and SMTP (Simple Mail Transfer Protocol, a standard protocol for email transmission). It is characterized by low memory usage and high concurrency capabilities.

[0058] Load balancing: The English name is LoadBalance, which means balancing and distributing the load (work tasks) to multiple operation units for operation, such as FTP servers, Web servers, enterprise core application servers and other major task servers, so as to complete the work tasks in a collaborative manner.

[0059] Optionally, in some optional embodiments, the S100 includes: step 1.1, step 1.2 and step 1.3;

[0060] Step 1.1, when the cluster front end accesses the system initial page, the traffic controller intercepts the Nginx request of the cluster front end for the system initial page;

[0061] Step 1.2, parsing the header information in the Nginx request;

[0062] Step 1.3, matching corresponding source cluster information according to the header information.

[0063] Optionally, the present invention can parse the http request information of the system initial page (ie, the information requested by Nginx): intercept the system initial page access request, parse the information in the request header, and match the cluster information. The present invention does not impose any limitation on this.

[0064] Optional, http: HyperText Transfer Protocol (HTTP) is a simple request-response protocol that usually runs on top of TCP.

[0065] Optionally, in some optional embodiments, the step 1.3 includes: step 1.31, step 1.32 and step 1.33;

[0066] Step 1.31, according to the header information, call the preset rule to determine the cluster front-end source of the Nginx request;

[0067] Step 1.32 and, according to the cluster front-end source, set the cluster flag information of the Nginx request as the source cluster information;

[0068] Step 1.33, store the cluster flag information of the Nginx request.

[0069] Optionally, the present invention can determine the source of the request according to the relevant information in the header of the request for the system initial page according to the corresponding rules, and set the value of the corresponding cluster flag. For example, the value of the cluster flag of cluster A is set to 0, and the value of the cluster flag of cluster B is set to 1, and the present invention does not limit this.

[0070] Optionally, based on the matching results, the present invention can store the value of the cluster flag as a basis for setting the cluster for subsequent access requests. Generally, access requests from the same cluster should have the same reverse proxy settings and cluster background settings, and the present invention does not impose any restrictions on this.

[0071] S200, dynamically setting a reverse proxy and a cluster backend according to the source cluster information, so as to distribute the Nginx request to the corresponding cluster backend through the reverse proxy;

[0072] Optionally, in some optional embodiments, the S200 includes: step 2.1 and step 2.2;

[0073] Step 2.1, according to the stored cluster flag information, dynamically set the reverse proxy and cluster backend corresponding to the cluster flag information, wherein the cluster backend is a cluster that processes Nginx requests with the cluster flag information;

[0074] Step 2.2: Distribute the Nginx request to the cluster backend for processing through the reverse proxy.

[0075] Optionally, the present invention can dynamically set the reverse proxy in Nginx load balancing according to the cluster flag value, and set the corresponding cluster to ensure that each module is accessed within a cluster at the front and back ends, and the present invention does not limit this.

[0076] S300, intercepting Nginx requests of other modules of the cluster front end for the system initial page, and distributing the Nginx requests of other modules to the corresponding cluster backend through the reverse proxy according to the source cluster information of the Nginx requests of other modules.

[0077] In the present invention, as mentioned above, the reverse proxy settings and cluster background settings of access requests from the same cluster are generally consistent. After the reverse proxy and cluster background are set up in the front, for access requests of other modules of the same cluster, the present invention can directly distribute them to the corresponding cluster background for processing according to the already set parameters. Of course, the present invention can also set up the corresponding reverse proxy and cluster background again according to the access requests of other modules of the same cluster, and then distribute them to the access requests, and the present invention does not limit this.

[0078] Optionally, in the context of the present invention, it is required that the data storage medium used by the existing cluster service and the upgraded cluster service be consistent to ensure consistency of system data and functions.

[0079] Optionally, in some optional implementations, the S300 includes: step 3.1, step 3.2 and step 3.3;

[0080] Step 3.1, intercepting Nginx requests for the system initial page from other modules at the front end of the cluster;

[0081] Step 3.2, parsing the Nginx requests of the other modules to obtain the source cluster information of the Nginx requests of the other modules;

[0082] Step 3.3: Determine the corresponding reverse proxy according to the source cluster information, and distribute the Nginx requests of the other modules to the corresponding cluster backend through the reverse proxy.

[0083] Alternatively, the existing Nginx load balancing performs load balancing on multiple clusters, which cannot directly solve the problem of multi-cluster cross-domain control access traffic, while other solutions only perform load balancing on background services, and distribute services to client requests based on users, which cannot fully cover users. The present invention ensures cluster traffic stability through a traffic controller and avoids the problem of incomplete user coverage.

[0084] That is, the present invention adds a traffic controller in Nginx load balancing, intercepts and analyzes the access request of the front end, determines the access cluster information through the system initial page, dynamically sets the reverse proxy, specifies the access cluster, ensures that the access traffic is stably carried out in one cluster, and enhances the flexibility and traffic controllability of the entire architecture.

[0085] like Figure 4 As shown, the present invention provides an Nginx load multi-cluster access distribution device, comprising: a source cluster information parsing unit 100, a proxy setting unit 200 and other request interception units 300;

[0086] The source cluster information parsing unit 100 is used for the flow controller to intercept and parse the Nginx request when the cluster front end accesses the system initial page, and obtain the source cluster information of the Nginx request, wherein the flow controller is set in the Nginx load balancing;

[0087] The proxy setting unit 200 is used to dynamically set the reverse proxy and the cluster backend according to the source cluster information, so as to distribute the Nginx request to the corresponding cluster backend through the reverse proxy;

[0088] The other request interception unit 300 is used to intercept Nginx requests of other modules of the cluster front end for the system initial page, and distribute the Nginx requests of other modules to the corresponding cluster background through the reverse proxy according to the source cluster information of the Nginx requests of other modules.

[0089] Optionally, in some optional implementations, the source cluster information parsing unit 100 includes: an Nginx request interception subunit, a header information parsing subunit, and a source cluster information matching subunit;

[0090] The Nginx request interception subunit is used for the flow controller to intercept the Nginx request of the cluster front end for the system initial page when the cluster front end accesses the system initial page;

[0091] The header information parsing subunit is used to parse the header information in the Nginx request;

[0092] The source cluster information matching subunit is used to match the corresponding source cluster information according to the header information.

[0093] Optionally, in some optional implementations, the source cluster information matching subunit includes: a rule calling subunit, a flag information setting subunit and a flag information storage subunit;

[0094] The rule calling subunit is used to call a preset rule according to the header information to determine the cluster front-end source of the Nginx request;

[0095] The flag information setting subunit is used to set the cluster flag information of the Nginx request as the source cluster information according to the cluster front-end source;

[0096] The flag information storage subunit is used to store the cluster flag information requested by the Nginx.

[0097] Optionally, in some optional implementations, the proxy setting unit 200 includes: a proxy cluster setting subunit and a request distribution subunit;

[0098] The proxy cluster setting subunit is used to dynamically set the reverse proxy and cluster backend corresponding to the cluster flag information according to the stored cluster flag information, wherein the cluster backend is a cluster that processes Nginx requests with the cluster flag information;

[0099] The request distribution subunit is used to distribute the Nginx request to the cluster background for processing through the reverse proxy.

[0100] Optionally, in some optional implementations, the other request interception unit 300 includes: other interception subunits, other parsing subunits and other distribution subunits;

[0101] The other interception sub-unit is used to intercept Nginx requests for the system initial page from other modules of the cluster front end;

[0102] The other parsing subunit is used to parse the Nginx request of the other module and obtain the source cluster information of the Nginx request of the other module;

[0103] The other distribution sub-unit is used to determine the corresponding reverse proxy according to the source cluster information, and distribute the Nginx requests of the other modules to the corresponding cluster background through the reverse proxy.

[0104] The present invention provides a computer-readable storage medium on which a program is stored. When the program is executed by a processor, any of the above-mentioned Nginx load multi-cluster access distribution methods is implemented.

[0105] like Figure 5As shown, the present invention provides an electronic device 70, which includes at least one processor 701, and at least one memory 702 and a bus 703 connected to the processor 701; wherein the processor 701 and the memory 702 communicate with each other through the bus 703; the processor 701 is used to call the program instructions in the memory 702 to execute any of the Nginx load multi-cluster access diversion methods described above.

[0106] In the present invention, relational terms such as first and second, etc. are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "comprise", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the statement "comprise a ..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.

[0107] Each embodiment in this specification is described in a related manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0108] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present invention. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined in the present invention may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to the embodiments shown in the present invention, but will conform to the widest scope consistent with the principles and novel features disclosed in the present invention.

[0109] The above description is only a preferred embodiment of the present invention and is not intended to limit the protection scope of the present invention. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention are included in the protection scope of the present invention.

Claims

1. A method for Nginx load multi-cluster access distribution, characterized in that: include: When the cluster front end accesses the system initial page, the traffic controller intercepts and parses the Nginx request to obtain the source cluster information of the Nginx request, wherein the traffic controller is set in the Nginx load balancing; According to the source cluster information, dynamically set the reverse proxy and cluster backend, so as to distribute the Nginx request to the corresponding cluster backend through the reverse proxy; Intercept the Nginx requests of other modules of the cluster front end for the system initial page, and distribute the Nginx requests of other modules to the corresponding cluster background through the reverse proxy according to the source cluster information of the Nginx requests of other modules.

2. The method according to claim 1, characterized in that When the cluster front end accesses the system initial page, the traffic controller intercepts and parses the Nginx request to obtain the source cluster information of the Nginx request, including: When the cluster front end accesses the system initial page, the traffic controller intercepts the Nginx request of the cluster front end for the system initial page; Parsing the header information in the Nginx request; The corresponding source cluster information is matched according to the header information.

3. The method according to claim 2, characterized in that The matching corresponding source cluster information according to the header information includes: According to the header information, calling the preset rules, determining the cluster front-end source of the Nginx request; According to the cluster front-end source, set the cluster flag information of the Nginx request as the source cluster information; The cluster flag information of the Nginx request is stored.

4. The method according to claim 3, characterized in that The method of dynamically setting a reverse proxy and a cluster backend according to the source cluster information so as to distribute the Nginx request to the corresponding cluster backend through the reverse proxy includes: According to the stored cluster flag information, dynamically set the reverse proxy and cluster backend corresponding to the cluster flag information, wherein the cluster backend is a cluster that processes Nginx requests with the cluster flag information; Through the reverse proxy, the Nginx request is distributed to the cluster backend for processing.

5. The method according to claim 1, characterized in that The intercepting of Nginx requests of other modules of the cluster front end for the system initial page and distributing the Nginx requests of other modules to the corresponding cluster backend through the reverse proxy according to the source cluster information of the Nginx requests of other modules include: Intercept Nginx requests for the system initial page from other modules at the front end of the cluster; Parse the Nginx requests of the other modules to obtain source cluster information of the Nginx requests of the other modules; According to the source cluster information, the corresponding reverse proxy is determined, and the Nginx requests of the other modules are distributed to the corresponding cluster backend through the reverse proxy.

6. An Nginx load multi-cluster access distribution device, characterized in that: include: Source cluster information parsing unit, proxy setting unit and other request interception units; The source cluster information parsing unit is used for the flow controller to intercept and parse the Nginx request when the cluster front end accesses the system initial page, and obtain the source cluster information of the Nginx request, wherein the flow controller is set in the Nginx load balancing; The proxy setting unit is used to dynamically set the reverse proxy and the cluster backend according to the source cluster information, so as to distribute the Nginx request to the corresponding cluster backend through the reverse proxy; The other request interception unit is used to intercept Nginx requests of other modules of the cluster front end for the system initial page, and distribute the Nginx requests of other modules to the corresponding cluster background through the reverse proxy according to the source cluster information of the Nginx requests of other modules.

7. The device according to claim 6, characterized in that The source cluster information parsing unit includes: an Nginx request interception subunit, a header information parsing subunit and a source cluster information matching subunit; The Nginx request interception subunit is used for the flow controller to intercept the Nginx request of the cluster front end for the system initial page when the cluster front end accesses the system initial page; The header information parsing subunit is used to parse the header information in the Nginx request; The source cluster information matching subunit is used to match the corresponding source cluster information according to the header information.

8. The device according to claim 7, characterized in that The source cluster information matching subunit includes: a rule calling subunit, a flag information setting subunit and a flag information storage subunit; The rule calling subunit is used to call a preset rule according to the header information to determine the cluster front-end source of the Nginx request; The flag information setting subunit is used to set the cluster flag information of the Nginx request as the source cluster information according to the cluster front-end source; The flag information storage subunit is used to store the cluster flag information requested by the Nginx.

9. A computer-readable storage medium having a program stored thereon, characterized in that: When the program is executed by the processor, the Nginx load multi-cluster access distribution method as described in any one of claims 1 to 5 is implemented.

10. An electronic device, characterized in that: The electronic device includes at least one processor, and at least one memory and a bus connected to the processor; wherein the processor and the memory communicate with each other through the bus; the processor is used to call program instructions in the memory to execute the Nginx load multi-cluster access diversion method as described in any one of claims 1 to 5.

Images