A method for dynamically obtaining upstream service health nodes of an OpenResty gateway

Abstract

The application discloses a method for dynamically acquiring upstream service health nodes of an OpenResty gateway, and has the following steps: each worker process of the OpenResty gateway acquires node IP of nodes of an upstream service from a configuration center to initialize a health node set corresponding to each upstream service, and simultaneously, listens to node health state change events of the upstream service of the configuration center; an independent checking service periodically checks the upstream service and publishes the node health state change events of the upstream service to the configuration center; after each worker process of the OpenResty gateway receives the node state change events of the upstream service, the health node list of the corresponding service is updated.

Description

Technical Field

[0001] This invention relates to a method for upstream health checks for OpenResty API gateways. Background Technology

[0002] In the web server field, OpenResty has gained favor among many enterprises due to its dynamic and high-performance advantages, with API gateways being one of its key application areas. When handling HTTP requests from clients, the OpenResty gateway undergoes a content retrieval phase. This phase requires establishing a connection with the upstream service and forwarding the request, then retrieving the response processed by the upstream service and forwarding it to the client. For many internet applications, 24 / 7 operation has become the norm, so upstream services are typically deployed in clusters to achieve high system availability. The advantage of the OpenResty gateway is that its configuration can be changed and taken effect in real time. Operations personnel can maintain the cluster information of upstream services in the configuration center and publish it to the OpenResty gateway, eliminating the need to modify static configurations and reload like with Nginx. Therefore, the gateway possesses service discovery capabilities. Figure 1 As shown, node unavailability can occur at any time due to many unreliable factors such as the network. Therefore, health checks of upstream service nodes have become a core function. Only by identifying and selecting a healthy node to send a request can the request receive a normal and timely response.

[0003] In existing technical solutions, the main method for checking upstream service nodes is for each worker in the gateway to directly initiate health check requests to the upstream nodes, such as... Figure 2 As shown, each worker in each gateway instance creates an asynchronous Timer to initiate periodic requests to the upstream service nodes. The advantage of this approach is its simplicity and directness, requiring no additional components.

[0004] However, this solution has the following shortcomings:

[0005] First, the gateway itself is responsible for maintenance and inspection tasks, which requires valuable Timer resources. Each worker maintains a long connection with the upstream, which requires additional network resources. As the number of upstream service nodes increases and the gateway pressure increases, this additional resource usage will reduce the overall performance of the gateway.

[0006] Secondly, each worker in the gateway will initiate a probe to the upstream. In order to maintain high availability, the gateway itself will adopt a cluster deployment. Therefore, the total number of workers is equal to the total number of workers in a single gateway instance multiplied by the total number of gateway instances. In addition to maintaining long connections with all workers, each node of the upstream service also needs to periodically send check requests to each node of the upstream service. However, the connection resources of the upstream service are usually more precious. The upstream service usually uses a web application server with weaker performance than OpenResty. If the upstream resources are forced to be used to maintain long connections with many workers, then the performance of the upstream service in processing requests will be severely squeezed. Summary of the Invention

[0007] The technical problem this invention aims to solve is: how to effectively obtain the health status of upstream service nodes when the OpenResty gateway does not use a Timer mechanism to check upstream nodes.

[0008] To address the aforementioned technical problems, the present invention provides a method for dynamically obtaining the health status of upstream service nodes for an OpenResty gateway, characterized by comprising the following steps:

[0009] Step 1: Each worker process of the OpenResty gateway obtains the node IPs of the upstream service nodes from the configuration center to initialize the health node set corresponding to each upstream service. Simultaneously, it listens for node health status change events for the upstream service in the configuration center, including the following steps:

[0010] Step 101: During the initialization phase, each worker process of the OpenResty gateway obtains the node IP data of each upstream service node in the configuration center and constructs a mapping table. The key of this mapping table is the unique ID number of the upstream service, and the value of this mapping table is the list of node IPs of the corresponding upstream service nodes. The obtained mapping table is the initial upstream service health node mapping table.

[0011] Step 102: Each worker process of the OpenResty gateway establishes a long connection with the configuration center and listens for changes to a specific key. This key consists of two parts: the upstream service ID and the node IP. It uniquely identifies the upstream service within the local area network, and the corresponding value is the health status value of the node IP. This value indicates whether the corresponding node is healthy.

[0012] Step 2: An independent inspection service performs periodic checks on upstream services and publishes the node health status change events of upstream services to the configuration center. The key of the node health status change event consists of two parts: the upstream service ID and the node IP. The value of the node health status change event is the health status value corresponding to the node IP. The health status value indicates whether the corresponding node is healthy or unhealthy.

[0013] Step 3: After receiving the node status change event from the upstream service, each worker process of the OpenResty gateway updates the healthy node list of the corresponding service, including the following steps:

[0014] Step 301: When each worker process receives a node health status change event from the configuration center, it parses the content of the node health status change event to obtain the key and value of the event. It then retrieves the upstream service ID from the key, queries the mapping table from step 101 to obtain the corresponding node IP list, and modifies this node IP list based on the value.

[0015] If the health status of the node corresponding to the node IP in the Key is healthy, then check whether the node IP list contains the current node: if it contains the current node, then do nothing; if it does not contain the current node, then append the current node to the node IP list. The action of appending the current node will update the upstream service health node mapping table maintained in step 101.

[0016] If the health status value of the node corresponding to the node IP in the Key is unhealthy, then check whether the node IP list contains the current node: if it does, remove the current node from the node IP list; if it does not, do nothing. The action of removing the current node will update the upstream service health node mapping table maintained in step 101.

[0017] Preferably, step 2 includes the following steps:

[0018] Step 201: The independent inspection service obtains the configuration information of all upstream services to be inspected from the configuration center;

[0019] Step 202: The independent inspection service traverses the configuration information of each upstream service and initializes the task information of the health check task according to the configuration information of the upstream service. The task information includes the task execution period, the list of nodes to be checked, and the health check URL.

[0020] Step 203: When the health check task is executed, parse the health check task content, obtain the list of nodes to be checked, traverse the node list, construct the final health check request URL based on the node IP and health check URL of each node in the node list, and send an asynchronous GET request to the corresponding node.

[0021] Step 204: Determine the health indicators of the current node based on the response status codes returned by each node after processing the GET request: If the request response status code is not 502, 503, or 504, then the current node's current check indicator is determined to be healthy; otherwise, the current node's current check indicator is determined to be unhealthy, and the node health indicator result is obtained.

[0022] Step 205: Based on the node health indicator results obtained in Step 204, create or update the node health indicator counter. The underlying data structure of this node health indicator counter is a mapping table. The key of this mapping table is the node IP of each node, and the value of this mapping table is the health indicator mapping table. The health indicator mapping table has two keys: key-healthy (representing health) and key-unhealthy (representing unhealthiness). The values ​​of key-healthy and key-unhealthy represent the cumulative values ​​of the corresponding health indicators. When the cumulative value of a node's health indicator reaches a preset value, proceed to Step 206; otherwise, return to Step 203.

[0023] Step 206: Change the node health status to healthy or unhealthy, and publish a node health status change event to the configuration center. The key and value of the node health status change event are the key and value listed in step 102, respectively. After successful publication, reset the value of key-healthy and key-unhealthy to 0.

[0024] Preferably, in step 205, if the current health check indicator of the current node is unhealthy as obtained through step 204, then the value of key-healthy in the health indicator mapping table is reset to 0, and the value of key-unhealthy is accumulated; if the current health check indicator of the current node is healthy as obtained through step 204, then the value of key-unhealthy in the health indicator mapping table is reset to 0, and the value of key-healthy is accumulated.

[0025] Preferably, in step 205, if the value of the key-healthy of the current node reaches 5, it indicates that the current node is healthy, and proceed to step 206, where the node's health status is changed to healthy; if the value of the key-unhealthy of the current node reaches 2, it indicates that the current node is unhealthy, and proceed to step 206, where the node's health status is changed to unhealthy; otherwise, return to step 203.

[0026] Compared with existing technical solutions, the present invention has the following advantages:

[0027] First, the gateway's worker processes free up the resources originally used for upstream node health checks to handle additional client requests, thereby increasing the upper limit of client requests that a machine with the same resources can handle.

[0028] Second, the number of upstream nodes that can be checked is no longer technically limited by the number of asynchronous timers, and the number of upstream applications that the gateway can access has greatly increased.

[0029] Third, the gateway worker has a more specialized function, which avoids the stability risks caused by the increase in worker complexity, while improving the maintainability of the gateway code.

[0030] Fourth, separating the health check service allows for more flexible modifications and configurations to adapt to potentially changing health check needs in the future.

[0031] Fifth, the resources required by upstream nodes to handle gateway health checks are reduced; connections that previously required multiple workers are now reduced to a single connection with the health check service. The saved resources can then be used to handle more client requests. Attached Figure Description

[0032] Figure 1 A diagram illustrating the selection of a healthy node for the gateway to handle HTTP requests;

[0033] Figure 2 The Timer mechanism is used to check the upstream architecture diagram for multiple gateways and multiple workers in the existing technology demonstration.

[0034] Figure 3 This illustrates the overall framework of the present invention;

[0035] Figure 4 This is a component diagram of the multi-gateway acquisition of upstream service health status according to the present invention;

[0036] Figure 5 This is an architecture diagram of the gateway obtaining the health status of upstream services in the embodiment.

[0037] Figure 6This is the initial health node mapping table for the service with ID 1 in the gateway worker in this embodiment;

[0038] Figure 7 This is a schematic diagram of the health index counting structure of the healthy nodes in the embodiment;

[0039] Figure 8 This is the health node mapping table for the service with ID 1 in the gateway worker in the embodiment. Detailed Implementation

[0040] The present invention will be further illustrated below with reference to specific embodiments. It should be understood that these embodiments are for illustrative purposes only and are not intended to limit the scope of the invention. Furthermore, it should be understood that after reading the teachings of this invention, those skilled in the art can make various alterations or modifications to the invention, and these equivalent forms also fall within the scope defined by the appended claims.

[0041] like Figure 5 As shown in the figure, this invention demonstrates the architecture of how the OpenResty gateway obtains the list of healthy upstream service nodes by listening to the etcd configuration center.

[0042] In this embodiment, the independent inspection service is a Spring Boot-based web service implemented in Java.

[0043] In this embodiment, the invention is further illustrated by taking the service configuration table shown in Table 1 below as an example to obtain the health node of the service from the OpenResty gateway.

[0044]

[0045] Table 1

[0046] The initialization of each worker process in the OpenResty gateway and the monitoring of health status changes of upstream service nodes include the following steps:

[0047] Step 1: Each worker process initializes a service health node mapping table, such as... Figure 6 As shown;

[0048] 1) Key field: Service ID is 1;

[0049] 2) Value field: List of healthy nodes [192.168.1.1, 192.168.1.2]

[0050] Step 1: Each worker process listens for changes in the etcd-key that uniquely identifies changes in the health status of the service node, specifically by listening for changes in the values ​​of the keys / 1 / 192.168.1.1 and / 1 / 192.168.1.2.

[0051] The Spring Boot web service performs periodic checks on the service with ID 1 and publishes service node health status change events to etcd, including the following steps:

[0052] Step 1: Query the configuration information of the published service with ID 1 in the etcd configuration center;

[0053] Step 2: Parse the service configuration information to obtain the row record with service ID 1 in Table 1. Its health check cycle is 5 seconds, and the health check URL is / health. Based on this, add a new task that executes once every 5 seconds, with task number T1;

[0054] Step 3: When task T1 is scheduled to be executed, parse the content of the task to obtain the node IPs of the service with ID 1, which are 192.168.1.1 and 192.168.1.2. Based on the health check URL, send two asynchronous HTTP requests with URLs 192.168.1.1 / health and 192.168.1.2 / health respectively.

[0055] Step 4: Update the health metrics of nodes 192.168.1.1 and 192.168.1.2 based on the HTTP request and response results. The structure of the metrics is as follows: Figure 7 As shown. Taking the inspection of node 192.168.1.1 as an example, node determination is divided into three scenarios: healthy, unhealthy, and in progress.

[0056] Health: Check the request response code of node 192.168.1.1. It is 200. The healthy health index value of the node is incremented by 1, the unhealthy health index value is set to 0, and the healthy health index value is accumulated to the preset value of 5. Proceed to step 5.

[0057] Unhealthy: Check the request response code of node 192.168.1.1. If it is 502 / 503 / 504, increment the node's unhealthy health index by 1, reset the healthy health index value to 0, and accumulate the unhealthy health index value to the preset value of 2, then proceed to step 5.

[0058] During the judgment: If both the healthy and unhealthy health indicators of node 192.168.1.1 fail to reach the preset values, return to step 3.

[0059] Step 5: When Step 4 determines whether the 192.168.1.1 node is healthy or unhealthy, an event will be published to the etcd configuration center with the key / 1 / 192.168.1.1 and the value healthy or unhealthy.

[0060] The OpenResty gateway updates the list of healthy service nodes for each worker process, specifically including the following steps:

[0061] Step 1: Each worker process in the OpenResty gateway receives an event notification from the etcd configuration center regarding key / 1 / 192.168.1.1. Parsing the event key as / 1 / 192.168.1.1 indicates that the service node with service ID 1 and IP address 192.168.1.1 has undergone a health status change. Based on the event value and the current list of healthy worker nodes, the following four scenarios exist:

[0062] Scenario 1) If the worker process's list of currently healthy nodes with service ID 1 includes 192.168.1.1 and the current check result is healthy, then no action is required. The list of healthy nodes at this time would look like this: Figure 6 As shown.

[0063] Scenario 2) If the worker process's list of currently healthy nodes for service ID 1 includes 192.168.1.1, and the current check result is unhealthy, then 192.168.1.1 will be removed from the upstream healthy node list. The healthy node list at this time would look like this: Figure 8 As shown.

[0064] Scenario 3) If the current healthy node list for service ID 1 in the worker process does not contain 192.168.1.1, and the current check result is healthy, then 192.168.1.1 will be added to the upstream healthy node list. The healthy node list at this time will look like this: Figure 6 As shown.

[0065] Scenario 4) If the current healthy node list for service ID 1 in the worker does not contain 192.168.1.1 and the current check result is unhealthy, then no action is required. The healthy node list at this time would look like this: Figure 8 As shown.

Claims

1. A method for dynamically obtaining the health of upstream service nodes for an OpenResty gateway, characterized in that, Includes the following steps: Step 1: Each worker process of the OpenResty gateway obtains the node IPs of the upstream service nodes from the configuration center to initialize the health node set corresponding to each upstream service. Simultaneously, it listens for node health status change events for the upstream service in the configuration center, including the following steps: Step 101: During the initialization phase, each worker process of the OpenResty gateway obtains the node IP data of each upstream service node in the configuration center and constructs a mapping table. The key of this mapping table is the unique ID number of the upstream service, and the value of this mapping table is the list of node IPs of the corresponding upstream service nodes. The obtained mapping table is the initial upstream service health node mapping table. Step 102: Each worker process of the OpenResty gateway establishes a long connection with the configuration center and listens for changes to a specific key. This key consists of two parts: the upstream service ID and the node IP. It uniquely identifies the upstream service within the local area network, and the corresponding value is the health status value of the node IP. This value indicates whether the corresponding node is healthy. Step 2: An independent inspection service performs periodic checks on upstream services and publishes the node health status change events of upstream services to the configuration center. The key of the node health status change event consists of two parts: the upstream service ID and the node IP. The value of the node health status change event is the health status value corresponding to the node IP. The health status value indicates whether the corresponding node is healthy or unhealthy. Step 3: After receiving the node status change event from the upstream service, each worker process of the OpenResty gateway updates the healthy node list of the corresponding service, including the following steps: Step 301: When each worker process receives a node health status change event from the configuration center, it parses the content of the node health status change event to obtain the key and value of the event. It then retrieves the upstream service ID from the key, queries the mapping table from step 101 to obtain the corresponding node IP list, and modifies this node IP list based on the value. If the health status of the node corresponding to the node IP in the Key is healthy, then check whether the node IP list contains the current node: if it contains the current node, then do nothing; if it does not contain the current node, then append the current node to the node IP list. The action of appending the current node will update the upstream service health node mapping table maintained in step 101. If the health status value of the node corresponding to the node IP in the Key is unhealthy, then check whether the node IP list contains the current node: if it does, remove the current node from the node IP list; if it does not, do nothing. The action of removing the current node will update the upstream service health node mapping table maintained in step 101.

2. The method for dynamically obtaining the health of upstream service nodes for an OpenResty gateway as described in claim 1, characterized in that, Step 2 includes the following steps: Step 201: The independent inspection service obtains the configuration information of all upstream services to be inspected from the configuration center; Step 202: The independent inspection service traverses the configuration information of each upstream service and initializes the task information of the health check task according to the configuration information of the upstream service. The task information includes the task execution period, the list of nodes to be checked, and the health check URL. Step 203: When the health check task is executed, parse the health check task content, obtain the list of nodes to be checked, traverse the node list, construct the final health check request URL based on the node IP and health check URL of each node in the node list, and send an asynchronous GET request to the corresponding node. Step 204: Determine the health indicators of the current node based on the response status codes returned by each node after processing the GET request: If the request response status code is not 502, 503, or 504, then the current node's current check indicator is determined to be healthy; otherwise, the current node's current check indicator is determined to be unhealthy, and the node health indicator result is obtained. Step 205: Based on the node health indicator results obtained in Step 204, create or update the node health indicator counter. The underlying data structure of this node health indicator counter is a mapping table. The key of this mapping table is the node IP of each node, and the value of this mapping table is the health indicator mapping table. The health indicator mapping table has two keys: key-healthy (representing health) and key-unhealthy (representing unhealthiness). The values ​​of key-healthy and key-unhealthy represent the cumulative values ​​of the corresponding health indicators. When the cumulative value of a node's health indicator reaches a preset value, proceed to Step 206; otherwise, return to Step 203. Step 206: Change the node health status to healthy or unhealthy, and publish a node health status change event to the configuration center. The key and value of the node health status change event are the key and value listed in step 102, respectively. After successful publication, reset the value of key-healthy and key-unhealthy to 0.

3. The method for dynamically obtaining the health of upstream service nodes for an OpenResty gateway as described in claim 2, characterized in that, In step 205, if the current health check indicates that the current node's current check indicator is unhealthy, then the value of key-healthy in the health indicator mapping table is reset to 0, and the value of key-unhealthy is accumulated. If the current health check indicates that the current node's current check indicator is healthy, then the value of key-unhealthy in the health indicator mapping table is reset to 0, and the value of key-healthy is accumulated.

4. The method for dynamically obtaining the health of upstream service nodes for an OpenResty gateway as described in claim 3, characterized in that, In step 205, if the value of the key-healthy of the current node reaches 5, it indicates that the current node is healthy, and proceed to step 206, where the node's health status is changed to healthy; if the value of the key-unhealthy of the current node reaches 2, it indicates that the current node is unhealthy, and proceed to step 206, where the node's health status is changed to unhealthy; otherwise, return to step 203.

Images