Nginx load multi-cluster access shunting method and related device

Abstract

The application discloses an Nginx load multi-cluster access distribution method and a related device. When a cluster front-end access system initial page, the Nginx request is intercepted and analyzed to obtain the source cluster information. According to the source cluster information, the reverse proxy and the cluster background are dynamically set, and the Nginx request is distributed to the 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 analyzed to obtain the source cluster information, and the Nginx request of the other modules is distributed to the cluster background through the reverse proxy. The application analyzes and distributes the Nginx request to the corresponding cluster background through the flow controller in the Nginx load balancing, so that the Nginx request can be distributed to the correct cluster background for processing in the multi-cluster cross-domain access scenario, and the application controls based on the Nginx request, does not depend on the user, and can cover all users.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of servers, in particular to an Nginx load multi-cluster access shunting method and related device. BACKGROUND

[0002] With the rapid development of information technology, software business systems often face upgrading and transformation. In traditional system upgrading and publishing, online downtime is required, and announcements are made in advance, which is inconvenient for users. At the same time, it is also a great challenge for developers and operation and maintenance personnel. During the system upgrade iteration process, the traffic is directed to the upgrade cluster service to gradually realize version switching, control the impact of faults within an acceptable range, and reduce the risk of going online. It ensures the safe, stable and reliable operation of the system and improves user experience.

[0003] The current commonly used version iteration method is gray publishing. For services based on Nginx load balancing, gray publishing is often used, that is, a part of users use the existing version service, and a part of users start to use the new version, and gradually expand the scope of use, and finally migrate to the new version. This method switches traffic in the dimension of users 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 ensure that the system is accessed on the same cluster, resulting in request errors. SUMMARY

[0004] In view of the above problems, the present application provides an Nginx load multi-cluster access shunting method and related device to overcome the above problems or at least partially solve the above problems.

[0005] In a first aspect, an Nginx load multi-cluster access shunting method comprises:

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

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

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

[0009] Optionally, in some optional embodiments, when the cluster front-end accesses the system initial page, the traffic controller intercepts and resolves 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] Resolving the header information in the Nginx request;

[0012] According to the header information, matching the corresponding source cluster information.

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

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

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

[0016] Storing the cluster flag information of the Nginx request.

[0017] Optionally, in some optional embodiments, according to the source cluster information, dynamically setting the reverse proxy and the cluster background, so as to distribute the Nginx request to the corresponding cluster background through the reverse proxy, including:

[0018] According to the stored cluster flag information, dynamically setting the reverse proxy and the cluster background corresponding to the cluster flag information, wherein the cluster background is a cluster for processing the Nginx request with the cluster flag information;

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

[0020] Optionally, in some optional embodiments, the traffic controller intercepts the Nginx request of the other module of the cluster front-end for the system initial page, and according to the source cluster information of the Nginx request of the other module, the Nginx request of the other module is distributed to the corresponding cluster background through the reverse proxy, including:

[0021] Intercepting the Nginx request of the other module of the cluster front-end for the system initial page;

[0022] analyzing the Nginx request of the other module to obtain source cluster information of the Nginx request of the other module;

[0023] According to the source cluster information, a corresponding reverse proxy is determined, and the Nginx request of the other module is distributed to the corresponding cluster background through the reverse proxy.

[0024] In a second aspect, an Nginx load multi-cluster access distribution device comprises a source cluster information analysis unit, a proxy setting unit and an other request interception unit.

[0025] The source cluster information analysis unit is configured to intercept and analyze an Nginx request by a traffic controller when a cluster front end accesses a system initial page to obtain source cluster information of the Nginx request, wherein the traffic controller is arranged in an Nginx load balancing.

[0026] The proxy setting unit is configured to dynamically set a reverse proxy and a cluster background according to the source cluster information, so as to distribute the Nginx request to the corresponding cluster background through the reverse proxy.

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

[0028] Optionally, in some optional embodiments, the source cluster information analysis unit comprises an Nginx request interception subunit, a header information analysis subunit and a source cluster information matching subunit.

[0029] The Nginx request interception subunit is configured to intercept an Nginx request of the cluster front end to the system initial page by a traffic controller when a cluster front end accesses a system initial page.

[0030] The header information analysis subunit is configured to analyze header information in the Nginx request.

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

[0032] Optionally, in some optional embodiments, the source cluster information matching subunit comprises a rule calling subunit, a flag information setting subunit and a flag information storage subunit.

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

[0034] The flag information setting subunit is configured to set 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 configured to store the cluster flag information of the Nginx request.

[0036] In a third aspect, a computer readable storage medium has a program stored thereon, and the program, when executed by a processor, implements the Nginx load multi-cluster access distribution method of any of the preceding aspects.

[0037] In a fourth aspect, an electronic device includes at least one processor and at least one memory connected to the processor; the processor and the memory complete communication with each other through the bus; the processor is configured to call program instructions in the memory to execute the Nginx load multi-cluster access distribution method of any of the preceding aspects.

[0038] Through the above technical solution, the Nginx load multi-cluster access distribution method and related device provided by the application can intercept and analyze Nginx requests when a cluster front-end access system accesses an initial page, obtain source cluster information of the Nginx request, and set a reverse proxy and a cluster background dynamically according to the source cluster information, so as to distribute the Nginx request to a corresponding cluster background through the reverse proxy. The application also intercepts Nginx requests of other modules of the cluster front-end for the initial page of the system, and distributes the Nginx requests of the other modules to corresponding cluster backgrounds through the reverse proxy according to source cluster information of the Nginx requests of the other modules. As can be seen, the application sets a traffic controller in Nginx load balancing, and then analyzes and distributes Nginx requests to corresponding cluster backgrounds based on the traffic controller, so as to ensure that Nginx requests can be distributed to correct cluster backgrounds for processing in a multi-cluster cross-domain access scenario, and the application controls based on Nginx requests, does not depend on users, can cover all users, and has a wide coverage.

[0039] The above description is only a summary of the technical solutions of the application. In order to more clearly understand the technical means of the application, the application can be implemented according to the content of the specification, and in order to make the above and other purposes, features and advantages of the application more obvious and easy to understand, the following specific embodiments of the application are described. BRIEF DESCRIPTION OF DRAWINGS

[0040] Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The detailed description is made with reference to the accompanying drawings.

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

[0042] Figure 2 A flowchart of an Nginx load multi-cluster access shunting method provided by the present application is shown;

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

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

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

[0046] With the rapid development of information technology, software business systems often face upgrading and reconstruction. In traditional system upgrading and publishing, online downtime is required, and announcements are made in advance, which is inconvenient for users. At the same time, it is also a great challenge for developers and maintenance personnel. During the system upgrade iteration process, the traffic is directed to the upgrade cluster service, and the version switching is gradually realized, so as to control the fault impact within an acceptable range and reduce the online risk. The safe, stable and reliable operation of the system is ensured, and the user experience is improved.

[0047] The current common version iteration method is gray publishing. For services based on Nginx load balancing, gray publishing is often used, that is, a part of users use the existing version service, and a part of users start to use the new version, and gradually expand the use range, and finally migrate to the new version. This method switches traffic in the dimension of users and cannot cover all users. At the same time, for systems in which multiple modules are deployed separately and accessed through domain names, when the modules are switched, 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 is as follows: Figure 1As shown, this architecture is often pre-tested for version release, and when the program is accessed, the access from cluster A is not necessarily distributed to the background service of cluster A, but can be distributed to the background service of cluster B, causing request confusion and possible errors. The same is true for cluster B.

[0049] In the case where each module is accessed by accessing an independent domain name, front-end loading confusion can be caused. For example, when switching to module two in cluster A, it is possible to distribute to module two of cluster B, causing page loading errors, etc.

[0050] Exemplary embodiments of the present application will be described in greater detail below with reference to the accompanying drawings. Although exemplary embodiments of the present application are shown in the drawings, it is understood that the present application can be implemented in various forms and should not be limited by the embodiments set forth herein. Rather, these embodiments are provided so that the present application can be more thoroughly understood and so that the scope of the present application can be conveyed to those skilled in the art.

[0051] As Figure 2 shown, the present application provides a method for Nginx load multi-cluster access distribution, comprising: S100, S200 and S300;

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

[0053] Optionally, the current application system realizes parallel of multiple clusters through Nginx load balancing, and cluster information can be configured in the Nginx load balancer to achieve the purpose of multi-cluster load. Thus, the front-end request (for example Figure 1 from cluster A) can be distributed to the back-end service (for example Figure 1 of cluster A) through Nginx load balancing, and the present application does not limit this.

[0054] Optionally, as described above, the main problem of the existing solution is that after the system is updated, the traffic is switched according to the user dimension, which cannot achieve comprehensive coverage. At present, the system is mostly separated into front-end and back-end, and multiple modules are separately deployed. When the resources of the deployed cluster are insufficient, a new cluster often needs to be established to meet the resource needs. At this time, the same service can exist on different clusters, and the request can need to flow within the cluster and cannot flow to other clusters. If the router in the middle does not control, it will not be able to guarantee that the request flows within the same cluster, and the problem of cross-domain access to different cluster services can cause business logic errors.

[0055] That is, after the system is updated, the Nginx request for accessing the new system is generally first accessed to the system initial page of the new system. Therefore, the traffic controller of the present application can intercept and analyze the Nginx request to obtain the information of the cluster front end (i.e., the cluster sending the Nginx request) (i.e., the source cluster information) for subsequent setting of the reverse proxy and cluster information, which is not limited by the present application.

[0056] Optionally, the traffic controller is arranged in the Nginx load balancing to facilitate interception of each Nginx request of the cluster front end, and then analysis of the source cluster information for distribution of traffic, and the specific system architecture is as shown in Figure 3 , which is not limited by the present application.

[0057] Nginx: a high-performance HTTP and reverse proxy web server, which also provides IMAP (Internet Message Access Protocol), POP3 (Post Office Protocol-Version 3) and SMTP (Simple Mail Transfer Protocol) services. Its characteristics are small memory occupation and strong concurrency capability.

[0058] Load balancing: the English name is Load Balance, which refers to balancing and distributing the load (work tasks) to multiple operation units for running, such as FTP servers, web servers, enterprise core application servers and other main task servers, so as to cooperatively complete the work tasks.

[0059] Optionally, in some optional embodiments, the S100 comprises steps 1.1, 1.2 and 1.3.

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

[0061] Step 1.2: analyzing the header information in the Nginx request.

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

[0063] Optionally, the present application can analyze the http request information of the system initial page (i.e., the information of the Nginx request): intercepting the access request of the system initial page, analyzing the information in the request header, and matching the cluster information, which is not limited by the present application.

[0064] Optionally, http: HyperText Transfer Protocol (HTTP) is a simple request-response protocol, which is usually run on TCP.

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

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

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

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

[0069] Optionally, the application can determine the source of the request according to the corresponding rule according to the relevant information in the header of the request of the initial page of the system, 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, which is not limited by the application.

[0070] Optionally, according to the matching result, the application can store the value of the cluster flag as the basis for setting the cluster for subsequent access requests. Generally, the access requests from the same cluster should be consistent in reverse proxy setting and cluster background setting, which is not limited by the application.

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

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

[0073] Step 2.1, according to the stored cluster flag information, dynamically setting the reverse proxy and the cluster background corresponding to the cluster flag information, wherein the cluster background is a cluster for processing Nginx requests with the cluster flag information;

[0074] Step 2.2, distributing the Nginx request to the cluster background for processing through the reverse proxy.

[0075] Optionally, the application can dynamically set the reverse proxy in Nginx load balancing according to the cluster flag value, set the corresponding cluster, and ensure that the front end and the back end and each module are accessed in a cluster. The application does not limit this.

[0076] S300, intercept the Nginx request of the other module of the cluster front end to the initial page of the system, and distribute the Nginx request of the other module to the corresponding cluster background through the reverse proxy according to the source cluster information of the Nginx request of the other module.

[0077] As mentioned earlier, the reverse proxy settings and cluster background settings of access requests from the same cluster are generally consistent. After setting the reverse proxy and cluster background, the application can directly distribute the access request of the other module of the same cluster to the corresponding cluster background for processing according to the already set parameters. Of course, the application can also set the corresponding reverse proxy and cluster background again according to the access request of the other module of the same cluster, and then distribute the access request. The application does not limit this.

[0078] Optionally, in the context of the application, the data storage medium used by the existing cluster service and the upgraded cluster service needs to be consistent to ensure the consistency of system data and functions.

[0079] Optionally, in some optional embodiments, the S300 includes steps 3.1, 3.2 and 3.3.

[0080] Step 3.1, intercept the Nginx request of the other module of the cluster front end to the initial page of the system;

[0081] Step 3.2, parse the Nginx request of the other module to obtain the source cluster information of the Nginx request of the other module;

[0082] Step 3.3, according to the source cluster information, determine the corresponding reverse proxy, and distribute the Nginx request of the other module to the corresponding cluster background through the reverse proxy.

[0083] Optionally, the existing Nginx load balancing does load balancing for multiple clusters, and cannot directly solve the problem of multi-cluster cross-domain control access traffic. Other solutions only do load balancing for the background service and distribute services to the client request based on users, which cannot fully cover the users. The application ensures the stability of cluster traffic through the traffic controller, and avoids the problem of incomplete user coverage.

[0084] That is, the application adds a flow controller in Nginx load balancing, intercepts and analyzes access requests of the front end, determines access cluster information through a system initial page, dynamically sets a reverse proxy, specifies an access cluster, ensures that access traffic is stable in a cluster, and enhances flexibility and flow controllability of the entire architecture.

[0085] As shown in Figure 4 The application provides an Nginx load multi-cluster access shunting device, which comprises a source cluster information analysis unit 100, a proxy setting unit 200, and an other request interception unit 300.

[0086] The source cluster information analysis unit 100 is configured to intercept and analyze an Nginx request by a flow controller when a cluster front end accesses a system initial page, and obtain source cluster information of the Nginx request, wherein the flow controller is arranged in Nginx load balancing.

[0087] The proxy setting unit 200 is configured to dynamically set a reverse proxy and a cluster background according to the source cluster information, so as to distribute the Nginx request to the corresponding cluster background through the reverse proxy.

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

[0089] Optionally, in some optional embodiments, the source cluster information analysis unit 100 comprises an Nginx request interception subunit, a header information analysis subunit, and a source cluster information matching subunit.

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

[0091] The header information analysis subunit is configured to analyze header information in the Nginx request.

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

[0093] Optionally, in some optional embodiments, the source cluster information matching subunit comprises a rule calling subunit, a flag information setting subunit, and a flag information storage subunit.

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

[0095] The flag information setting subunit is configured to set 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 configured to store the cluster flag information of the Nginx request.

[0097] Optionally, in some optional embodiments, the proxy setting unit 200 comprises a proxy cluster setting subunit and a request distribution subunit.

[0098] The proxy cluster setting subunit is configured to dynamically set a reverse proxy corresponding to the cluster flag information and a cluster background according to the stored cluster flag information, wherein the cluster background is a cluster for processing the Nginx request with the cluster flag information.

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

[0100] Optionally, in some optional embodiments, the other request interception unit 300 comprises an other interception subunit, an other analysis subunit and an other distribution subunit.

[0101] The other interception subunit is configured to intercept an Nginx request of other modules of the cluster front-end to the system initial page.

[0102] The other analysis subunit is configured to analyze the Nginx request of the other modules to obtain source cluster information of the Nginx request of the other modules.

[0103] The other distribution subunit is configured to determine a corresponding reverse proxy according to the source cluster information, and distribute the Nginx request of the other modules to a corresponding cluster background through the reverse proxy.

[0104] The application provides a computer readable storage medium, which stores a program, and the program is executed by a processor to implement the Nginx load multi-cluster access distribution method.

[0105] As Figure 5As shown, the present application provides an electronic device 70, which comprises at least one processor 701, and at least one memory 702 connected with the processor 701, a bus 703; wherein the processor 701, the memory 702 complete mutual communication through the bus 703; the processor 701 is used to call the program instruction in the memory 702, to execute the Nginx load multi-cluster access shunting method of any one described above.

[0106] In the present application, the relational terms such as first and second and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any such actual relationship or order between such entities or actions. Moreover, the terms "comprises", "comprising", or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by "comprises... a" does not, without more constraints, exclude the presence of additional identical elements in the process, method, article, or apparatus that comprises the element.

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

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

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

Claims

1. An Nginx load multi-cluster access shunting method, characterized in that, The method comprises the following steps: When a cluster front end accesses a system initial page, a traffic controller intercepts and analyzes an Nginx request to obtain source cluster information of the Nginx request, wherein the traffic controller is arranged in Nginx load balancing; According to the source cluster information, a reverse proxy and a cluster background are dynamically set so as to distribute the Nginx request to a corresponding cluster background through the reverse proxy; Nginx requests of other modules of the cluster front end to the system initial page are intercepted, and according to source cluster information of the Nginx requests of the other modules, the Nginx requests of the other modules are distributed to corresponding cluster backgrounds through the reverse proxy.

2. The method of claim 1, wherein, The step of, when a cluster front end accesses a system initial page, a traffic controller intercepts and analyzes an Nginx request to obtain source cluster information of the Nginx request, comprises the following steps: When a cluster front end accesses a system initial page, a traffic controller intercepts an Nginx request of the cluster front end to the system initial page; Header information in the Nginx request is analyzed; According to the header information, corresponding source cluster information is matched.

3. The method of claim 2, wherein, The step of, according to the header information, corresponding source cluster information is matched, comprises the following steps: According to the header information, a preset rule is called to determine a cluster front end source of the Nginx request; According to the cluster front end source, cluster flag information of the Nginx request is set as the source cluster information; The cluster flag information of the Nginx request is stored.

4. The method of claim 3, wherein, The step of, according to the source cluster information, a reverse proxy and a cluster background are dynamically set so as to distribute the Nginx request to a corresponding cluster background through the reverse proxy, comprises the following steps: According to stored cluster flag information, a reverse proxy and a cluster background corresponding to the cluster flag information are dynamically set, wherein the cluster background is a cluster for processing Nginx requests with the cluster flag information; The Nginx request is distributed to the cluster background for processing through the reverse proxy.

5. The method of claim 1, wherein, The step of, Nginx requests of other modules of the cluster front end to the system initial page are intercepted, and according to source cluster information of the Nginx requests of the other modules, the Nginx requests of the other modules are distributed to corresponding cluster backgrounds through the reverse proxy, comprises the following steps: Nginx requests of other modules of the cluster front end to the system initial page are intercepted; The Nginx requests of the other modules are analyzed to obtain source cluster information of the Nginx requests of the other modules; According to the source cluster information, corresponding reverse proxies are determined, and the Nginx requests of the other modules are distributed to corresponding cluster backgrounds through the reverse proxies.

6. An Nginx load multi-cluster access shunting device, characterized in that, The method comprises the following steps: A source cluster information analysis unit, a proxy setting unit and an other request interception unit are arranged. The source cluster information analysis unit is configured to, when the cluster front end accesses the system initial page, intercept and analyze an Nginx request by a traffic controller to obtain source cluster information of the Nginx request, wherein the traffic controller is arranged in an Nginx load balancing. The proxy setting unit is configured to, according to the source cluster information, dynamically set a reverse proxy and a cluster background, so as to distribute the Nginx request to the corresponding cluster background through the reverse proxy. The other request interception unit is configured to intercept an Nginx request of other modules of the cluster front end for the system initial page, and distribute the Nginx request of the other modules to the corresponding cluster background through the reverse proxy according to source cluster information of the Nginx request of the other modules.

7. The apparatus of claim 6, wherein, The source cluster information analysis unit comprises an Nginx request interception subunit, a header information analysis subunit and a source cluster information matching subunit. The Nginx request interception subunit is configured to, when the cluster front end accesses the system initial page, intercept an Nginx request of the cluster front end for the system initial page by a traffic controller. The header information analysis subunit is configured to analyze header information in the Nginx request. The source cluster information matching subunit is configured to match corresponding source cluster information according to the header information.

8. The apparatus of claim 7, wherein, The source cluster information matching subunit comprises a rule calling subunit, a flag information setting subunit and a flag information storage subunit. The rule calling subunit is configured to call a preset rule according to the header information to determine a cluster front end source of the Nginx request. The flag information setting subunit is configured to set 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 configured to store the cluster flag information of the Nginx request.

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

10. An electronic device, comprising: The electronic device comprises at least one processor, at least one memory connected with the processor and a bus; wherein the processor, the memory and the bus complete mutual communication through the bus; the processor is used to call program instructions in the memory to execute the Nginx load multi-cluster access distribution method of any one of claims 1 to 5.

Images