Upstream node accurate fusing method based on Openreset

Abstract

The invention discloses an upstream node accurate fusing method based on Openreset, and the method comprises the steps: 1) for a fusing algorithm under the condition of high concurrency of a dynamic gateway instance, obtaining a specific value through nginx and openreset self-definition and built-in variables and a lua program, thereby judging whether each request meets a condition or not, and enabling the condition to be a fusing condition F; simultaneously setting two states of the upstream node: healthy and unhealthy states; the method comprises the following steps: according to the conditions such as the load of an upstream node cpu (Central Processing Unit), dynamically determining the succeed and failed; when the success value reaches the success rate value, the health value is set to be healthy; and when the fail times reach failing, setting to be unhealthy, namely, fusing is needed, and during the fusing period, if the request cannot hit the node, finding the next node for access until the fusing time elapses or a healthy state is recovered.

Description

Technical Field

[0001] The invention belongs to the field of high-concurrency dynamic gateways, and in particular relates to security, and is a method for protecting real business services. Background Art

[0002] Nginx is a lightweight, high-performance HTTP / reverse proxy server with high concurrency and low resource consumption as its core advantages. It is suitable for handling static resource distribution, reverse proxy and other scenarios;

[0003] OpenResty: An enhanced platform based on Nginx, it integrates the LuaJIT interpreter and a rich Lua library, supports dynamic logic processing through Lua scripts, and is extended to a high-performance dynamic Web application development framework. OpenResty integrates LuaJIT and third-party modules, allowing developers to write dynamic logic in Lua, which is suitable for API gateways and complex business processing. It is necessary to emphasize the dynamic processing capabilities of OpenResty, while Nginx focuses more on static and basic proxies.

[0004] OpenResty uses Lua coroutines and non-blocking I / O to maintain Nginx's high performance while increasing flexibility. The two have an architectural inheritance relationship, and OpenResty extends Nginx's capabilities.

[0005] OpenResty is often used for microservice gateways and dynamic web applications, while Nginx is more commonly used for traditional reverse proxies and CDNs. OpenResty handles API requests, while Nginx handles static files.

[0006] At present, dynamic gateways are often developed based on nginx and openresty applications. When the number of concurrent accesses increases suddenly, the backend business services are often overloaded and the memory usage rate will also increase sharply. In this case, it will cause great pressure on the business machine. The existing nginx and openresty can only control the upstream nodes forwarded to by load balancing, HASH and other algorithms, as well as proxy_next_upstream error timeout http_xxx. However, for some particularly complex or special status code situations, it is a bit powerless. Therefore, based on this situation, a more detailed and flexible upstream node control algorithm is needed to meet the precise fuse for excessive upstream node access times, so as to protect the real business services. Summary of the invention

[0007] The technical problem to be solved by the present invention is to overcome the shortcomings of the prior art, solve the security problem of business services under high concurrency of general dynamic gateway instances (that is, a large number of requests need to be processed in a short period of time, and the gateway will forward the requests to the back end. If the CPU load of the back end application machine to process the requests cannot bear, it will cause application abnormalities), and provide an upstream node precise fuse method based on nginx and Openresty.

[0008] The technical solution of the present invention is based on the upstream node precise fuse method of Openresty, the security problem of business services under high concurrency of dynamic gateway instances, and the upstream node precise fuse method based on nginx and Openresty. The core difficulties are mainly the following two points:

[0009] 1) For the high concurrency of dynamic gateway instances, the circuit breaker algorithm is used: through nginx and openresty custom and built-in variables, the specific value is obtained through the lua program to determine whether each request meets the condition, which is the circuit breaker condition F; at the same time, two states of the upstream node are set: HEALTH (healthy) and UNHEALTH (unhealthy). When the circuit breaker condition F is true, it means that the current node is UNHEALTH, and the number of times is recorded, which is represented by the number of failures; when the circuit breaker condition F is false, it means that the current node is HEALTH, and the number of times is recorded, which is represented by the number of successes.

[0010] Success_exceed and fail_exceed can be dynamically determined according to the CPU load of the upstream node. When success reaches the success_exceed value, the current state is set to healthy. When the number of fail reaches fail_exceed, the current state is set to unhealthy, which means that a circuit breaker is required. The first unhealthy state will be 2 seconds long, the second unhealthy state will be 4 seconds long, and so on. During the circuit breaker period, the request cannot hit the node and will look for the next node for access until the circuit breaker time has passed or the healthy state is restored.

[0011] 2) How to obtain a certain upstream node configured by the upstream before forwarding to the upstream: Based on openresty, use the Lua language or some official API interfaces provided for research and development;

[0012] The specific value of the fuse condition is status S, which is above 100, that is, the request response status code is S, success 2 times, and fail 3 times. When the routing request to a certain node is all S response code 3 times, the node is in an unhealthy state and needs to be fused. The fuse is fused for 2 seconds. During this period, the request reaches other nodes. If the fuse time is exceeded, the request will be re-initiated to the node. If the 200 status code continues to be returned, the number of times reaches 3 again, and the fuse is fused for 4 seconds; and so on (2, 4, 8, 16...), until the preset max_breaker_sec is reached (the default is 300 seconds, which can be adjusted dynamically). 2, 4, 8, 16, etc. are based on the base 2, and this base can also be adjusted dynamically according to the situation. When the status code returned by accessing the node is not 200 and reaches 2 times, the node is restored to a healthy state.

[0013] The lua program obtains the specific value through the first module: supplement and expand the proxy_next_upstream function

[0014] By dynamically configuring the response status code, in the before_proxy stage (the last stage of forwarding the request to the upstream), first obtain a certain upstream node, forward the request to the node, and determine whether the response status code is consistent with the configuration. If not, directly return the response; if it is consistent, it means that you need to find the next node to access, and then obtain the next node through the method for forwarding, and so on; in this way, even for some special status codes, the next_upstream function can still be implemented, such as 532.

[0015] The lua program obtains the specific value through the second module: supplement and expand the error_page function

[0016] This is satisfied by configuring the standby node. When the response status code is consistent with the configuration, the access node is directly selected in the standby node, and the protocol (http or https) forwarded to the standby node can be dynamically set.

[0017] The lua program can easily obtain the specific value through the precise fuse of the upstream node and obtain the upstream node.

[0018] Beneficial Effects

[0019] Based on nginx and openresty, under the guidance of this design idea, the present invention can realize more detailed, more flexible and more accurate upstream node fuse, thereby realizing the protection of business services. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 This is a block diagram of the present invention. DETAILED DESCRIPTION

[0021] Referring to the attached figure, the main points are as follows:

[0022] 1) How to design a circuit breaker algorithm:

[0023] 1. Through nginx and openresty custom and built-in variables, the specific value can be obtained through the Lua program to determine whether each request meets the conditions, which is the fuse condition F;

[0024] 2. Set two states of the upstream node at the same time: HEALTH (healthy) and UNHEALTH (unhealthy);

[0025] 3. When the circuit breaker condition F is true, record the number of true times, which is represented by the number of fail times;

[0026] When the circuit breaker condition F is false, the number of false times is recorded, which is represented by the number of success times.

[0027] 4. Success_exceed and fail_exceed can be dynamically determined based on the CPU load of the upstream node. These two parameters determine whether the node is healthy. When the number of successes reaches the success_exceed value, it indicates that the node is in HEALTH state and no circuit breaker is required. When the number of failures reaches the fail_exceed value, it indicates that the node is in UNHEALTH state and circuit breaker is required.

[0028] 5. The circuit breaker time is calculated incrementally according to the number of times the unhealthy state is triggered. That is, the first time the node state is UNHEALTH, the circuit breaker is 2 seconds, the second time it is UNHEALTH, the circuit breaker is 4 seconds, and so on. During the circuit breaker period, the request cannot hit the node and will look for the next node to access until the circuit breaker time passes or the healthy state is restored.

[0029] 6. Example: Now the fuse condition F is status 200, that is, the request response status code is 200, success_exceed 2 times, fail_exceed 3 times. When the routing request to a certain node is 200 response code 3 times, the node is in UNHEALTH state and needs to be fused. The fusion is 2 seconds. During this period, the request reaches other nodes. If the fusion time is exceeded, the request will be re-initiated to the node. If the 200 status code continues to be returned, the number of times reaches 3 again, and the fusion is 4 seconds. And so on (2, 4, 8, 16...), until the preset max_breaker_sec is reached (the default is 300 seconds, which can be adjusted dynamically). 2, 4, 8, 16, etc. are based on the base 2, and this base can also be adjusted dynamically according to the situation. When the status code returned by accessing the node is not 200 and reaches 2 times, the node returns to the healthy state HEALTH.

[0030] 2) How to obtain a certain upstream node configured by the upstream before forwarding to the upstream: This mainly involves the gateway technology used. Since different technologies use different methods, we will not explain it in detail here. The general situation is probably based on openresty, using the Lua language or some official API interfaces provided for research and development. Here we take the recently popular apisix as an example. Its forwarding strategy is actually implemented in Lua. There are four main strategies: chash.lua ewma.lua least_conn.lua roundrobin.lua: By analyzing its implementation logic, it is easy to find the common method of the upstream nodes forwarded to by these forwarding strategies: the roughly implemented Lua logic is as follows:

[0031] local picker=require("roundrobin")

[0032] local server_picker=picker.new(upnodes)

[0033] local server,err=server_picker.get(ctx)

[0034] That is, the server is the final upstream node.

[0035] Note: This is just a brief explanation. The implementation methods are different depending on the technology stack used.

[0036] Functional modules of the present invention:

[0037] Module 1: Supplement and expand proxy_next_upstream function

[0038] Implementation idea: By dynamically configuring the response status code, first obtain a certain upstream node in the before_proxy stage (the last stage of forwarding the request to the upstream), forward the request to the node, and determine whether the response status code is consistent with the configuration. If not, directly return the response; if it is consistent, it means that you need to find the next node to access, and then obtain the next node through the method for forwarding, and so on; in this way, even for some special status codes, the next_upstream function can still be implemented, such as 532.

[0039] Module 2: Supplement and expand the error_page function

[0040] Implementation idea: Generally the same as the first module, it can be satisfied by configuring the standby node. When the response status code is consistent with the configuration, the access node is directly selected in the standby node, and the protocol forwarded to the standby node can be dynamically set (http or https)

[0041] Module 3: Accurate circuit breaking at upstream nodes

[0042] Implementation idea: Combined with the above-mentioned circuit breaker algorithm, success 2 times, fail 3 times, when the routing request to a certain node is 3 times and all the response codes are 200; and the upstream node is obtained, it can be easily implemented.

[0043] Summarize:

[0044] Based on this technical solution, we can expand on this basis to more accurately and flexibly meet specific needs or upstream node protection requirements in more complex situations.

[0045] The present invention may also have many other implementation modes. Without departing from the spirit and essence of the present invention, technicians familiar with the field may make various corresponding changes and deformations according to the present invention, and these corresponding changes and deformations should all fall within the protection scope of the claims of the present invention; the above design ideas do not limit the present invention in any way, and all other improvements and applications made to the above design ideas in an equivalent transformation manner fall within the protection scope of the present invention.

Claims

1. The upstream node precise circuit breaking method based on Openresty is characterized by: 1) For the high concurrency of dynamic gateway instances, the circuit breaker algorithm is used: through nginx and openresty custom and built-in variables, the specific value is obtained through the lua program to determine whether each request meets the condition, which is the circuit breaker condition F; at the same time, two states of the upstream node are set: HEALTH healthy and UNHEALTH unhealthy; when the circuit breaker condition F is true, it means that the current node is UNHEALTH, and the number of times is recorded, which is represented by the number of fail; when the circuit breaker condition F is false, it means that the current node is HEALTH, and the number of times is recorded, which is represented by the number of success; According to the CPU load of the upstream node and other conditions, success_exceed and fail_exceed are dynamically determined; when the success reaches the success_exceed value, the current state is set to healthy; when the number of failures reaches fail_exceed, the current state is set to unhealthy, which means that a circuit breaker is required. The first unhealthy condition is 2 seconds, the second unhealthy condition is 4 seconds, and so on. During the circuit breaker period, the request cannot hit the node and will go to the next node for access until the circuit breaker time is over or the healthy state is restored; 2) How to obtain an upstream node configured by the upstream before forwarding to the upstream: Based on openresty, use the Lua language or some official API interfaces provided for research and development.

2. The upstream node precise fusing method based on Openresty according to claim 1 is characterized in that: The specific value of the circuit breaker condition is status S, which is above 100, that is, the request response status code is S, success 2 times, and fail 3 times. When the routing request to a certain node is all S response code 3 times, the node is in an unhealthy state and needs to be fused. The fusion is 2 seconds. During this period, the request reaches other nodes. If the fusion time is exceeded, the request will be re-initiated to the node. If the status code 200 continues to be returned and the number of times reaches 3 again, the fusion will be 4 seconds; and so on (2, 4, 8, 16...) until the preset max_breaker_sec is reached, which is 300 seconds by default and can be adjusted dynamically; the time of 2, 4, 8, and 16 is based on the base 2, and this base is dynamically adjusted according to the situation; when the status code returned by accessing the node is not 200 and reaches 2 times, the node is restored to a healthy state.

3. The upstream node precise fusing method based on Openresty according to claim 1 is characterized in that: The lua program obtains the specific value through the first module: supplement and expand the proxy_next_upstream function; through dynamic configuration of the response status code, in the before_proxy stage, which is the last stage of forwarding the request to the upstream, first obtain a certain upstream node, forward the request to the node, and judge whether the response status code is consistent with the configuration. If not, directly return the response; if it is consistent, it means that you need to find the next node to access, and then obtain the next node through the method again for forwarding, and so on; in this way, even some special status codes can still realize the next_upstream function; The lua program obtains the specific value through the second module: supplements and expands the error_page function: it is satisfied by configuring the standby node. When the response status code is consistent with the configuration, the access node is directly selected in the standby node, and the protocol http or https forwarded to the standby node can be dynamically set; the lua program obtains the specific value through the precise fuse of the upstream node, and obtains the upstream node.

Images