Service dynamic load access method and device, internet of things platform, and medium

Abstract

The present application relates to a service dynamic load access method and device, an Internet of Things platform, and a medium. The method comprises: constructing a Kubernetes cluster worker node by means of multi-availability zone host nodes; running a service on the Kubernetes cluster worker node, and registering information of a POD object to Zookeeper; deploying Nginx servers on the multi-availability zone host nodes in the Kubernetes cluster worker node; deploying an agent program on the Nginx servers in the multi-availability zone host nodes; and on the basis of the agent program, matching an availability zone to which the service currently belongs, so as to update a configuration file of a host Nginx server where the agent program is located. In the present application, the availability zone to which the service belongs can be identified, facilitating dynamic capacity expansion and contraction of the service, and improving the efficiency of service access.

Description

Service dynamic load access method, device, Internet of Things platform and medium Technical Field

[0001] The present application relates to the technical field of platform deployment architecture, and in particular to a method, device, Internet of Things platform and medium for accessing dynamic service load. Background Art

[0002] With the increasing adoption of multi-AZ disaster recovery cloud architectures, application systems will be deployed across multiple availability zones, achieving high availability and disaster recovery through technologies such as load balancing and auto-scaling. Multi-AZ disaster recovery cloud architectures offer greater reliability and resilience, ensuring that if a failure occurs in one availability zone, the system can quickly failover to another, avoiding service interruption or data loss. Architectures built with cloud-native technologies and management methods are becoming increasingly popular in application development models, and disaster recovery combinations based on multiple availability zones, Kubernetes, and microservices are becoming the preferred architectural choice for an increasing number of enterprises.

[0003] To ensure service access reliability and scalability, services are typically deployed directly on hosts or run on hosts using Docker. Services are then provided externally through a load balancer and virtual IP. Alternatively, services are deployed as pods on Kubernetes and provided externally through Ingress and virtual IP. These deployment methods have drawbacks: Dynamic service scaling is impossible with host-based or Docker-based deployments; additional hosts are required for capacity expansion. Furthermore, the Kubernetes-based Ingress access architecture results in lower request per second (RPS) efficiency compared to native Nginx.

[0004] Summary of the Invention

[0005] The purpose of the embodiments of the present application is to propose a method, device, Internet of Things platform and medium for dynamic load access to services, so as to identify the available zones of the services, realize dynamic expansion and contraction of the services, and improve the efficiency of service access.

[0006] In order to solve the above technical problems, an embodiment of the present application provides a method for accessing a service dynamic load, including:

[0007] Build Kubernetes cluster worker nodes through multi-availability zone host nodes;

[0008] Run the service on the Kubernetes cluster worker node and register the POD object information with Zookeeper;

[0009] Deploy the Nginx server to the multi-zone host node in the Kubernetes cluster worker node;

[0010] Deploy an agent program on the Nginx server in the multi-availability zone host node;

[0011] Based on the proxy program matching the current available zone of the service, the configuration file of the host Nginx server where the proxy program is located is updated.

[0012] Furthermore, the updating of the configuration file of the Nginx server on the host where the proxy program is located based on matching the current available zone of the service with the proxy program includes:

[0013] Monitoring the registration service in the Zookeeper based on the agent program;

[0014] Determine whether the current availability zone matches the host IP of the container service in the registration service, and obtain the judgment result;

[0015] Based on the judgment result, the configuration file of the host Nginx server where the agent program is located is updated.

[0016] Furthermore, the updating of the configuration file of the Nginx server on the host where the proxy program is located based on the judgment result includes:

[0017] If the judgment result is that the current availability zone matches the host IP of the container service in the registration service, then obtain the matched container service instance and dynamically write the matched container service instance into the upstream module of the configuration file to forward Nginx traffic to the nearest location;

[0018] If the judgment result is that the current availability zone does not match the host IP of the container service instance in the registration service, all container service instances are dynamically written into the upstream module of the configuration file to fully forward the Nginx traffic based on the load policy.

[0019] Furthermore, the process of running the service on the Kubernetes cluster worker node and registering the POD object information with Zookeeper includes:

[0020] Run the service on the Kubernetes cluster working node in a multi-instance POD manner;

[0021] After each service instance is started, the information of the POD object is registered with the Zookeeper, and the target information is injected into the POD object through the container ENV environment variable.

[0022] Furthermore, the target information includes the container IP, service port, and the host IP where the service is located.

[0023] Furthermore, the information in the configuration file includes the availability zone distribution configuration information and other public configuration information in the Kubernetes cluster working nodes; the other public configuration information includes the service registration Zookeeper address, the Nginx configuration file path and the Nginx configuration file template.

[0024] Furthermore, the construction of a Kubernetes cluster working node through multi-availability zone host nodes includes:

[0025] The Kubernetes cluster working nodes are constructed through the multi-availability zone host nodes interconnected by multiple networks, wherein each of the multi-availability zone host nodes includes multiple host IPs.

[0026] In order to solve the above technical problems, an embodiment of the present application provides a device for accessing a dynamic service load, including:

[0027] Worker node construction unit, used to build Kubernetes cluster worker nodes through multi-availability zone host nodes;

[0028] A POD object registration unit is used to run the service on the working node of the Kubernetes cluster and register the POD object information with Zookeeper;

[0029] An Nginx server deployment unit, configured to deploy the Nginx server to a multi-availability zone host node in the Kubernetes cluster worker node;

[0030] An agent program deployment unit, configured to deploy an agent program to the Nginx server in the multi-availability zone host node;

[0031] A configuration file updating unit is used to update the configuration file of the host Nginx server where the proxy program is located based on matching the current available zone of the service with the proxy program.

[0032] To solve the above technical problems, a technical solution adopted in this application is: to provide an Internet of Things platform, including one or more processors; a memory for storing one or more programs, so that one or more processors can implement any of the above-mentioned service dynamic load access methods.

[0033] To solve the above technical problems, a technical solution adopted in this application is: a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements any one of the above-mentioned service dynamic load access methods.

[0034] The embodiment of the present application provides a method, device, Internet of Things platform and medium for dynamic load access to services. The method includes: building a Kubernetes cluster working node through a multi-availability zone host node; running the service on the Kubernetes cluster working node, and registering the information of the POD object to Zookeeper; deploying the Nginx server to the multi-availability zone host node in the Kubernetes cluster working node; deploying an agent program to the Nginx server in the multi-availability zone host node; matching the current availability zone of the service based on the agent program to update the configuration file of the host Nginx server where the agent program is located. The embodiment of the present application constructs a Kubernetes cluster working node, runs the service on the Kubernetes cluster working node, and deploys the Nginx server to the multi-availability zone host node in the Kubernetes cluster working node. The agent program deployed on the Nginx server identifies the availability zone of the service, thereby realizing dynamic expansion and contraction of the service and improving the efficiency of service access. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] In order to more clearly illustrate the solutions in this application, a brief introduction will be given below to the drawings required for use in the description of the embodiments of this application. Obviously, the drawings described below are some embodiments of this application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0036] FIG1 is a flow chart of a method for accessing a dynamic service load according to an embodiment of the present invention;

[0037] FIG2 is a flowchart of a sub-process in a method for accessing a dynamic service load according to an embodiment of the present application;

[0038] FIG3 is a flowchart of a sub-process in a method for accessing a dynamic service load according to an embodiment of the present application;

[0039] FIG4 is a flowchart of a sub-process in a method for accessing a dynamic service load according to an embodiment of the present application;

[0040] FIG5 is a schematic diagram of load forwarding of a service instance in an available zone provided by an embodiment of the present application;

[0041] FIG6 is a first schematic diagram of load forwarding with a service instance in a non-availability zone provided by an embodiment of the present application;

[0042] FIG7 is a second schematic diagram of load forwarding with a service instance in a non-availability zone according to an embodiment of the present application;

[0043] FIG8 is a schematic diagram of a device for accessing dynamic service loads provided in an embodiment of the present application;

[0044] FIG9 is a schematic diagram of an Internet of Things platform provided in an embodiment of the present application. DETAILED DESCRIPTION

[0045] Unless otherwise defined, all technical and scientific terms used herein have the same meanings as commonly understood by those skilled in the art to which this application belongs. The terms used in the specification of the application are for the purpose of describing specific embodiments only and are not intended to limit this application. The terms "including" and "having" and any variations thereof in the specification and claims of this application and the above-mentioned drawings are intended to cover non-exclusive inclusions. The terms "first", "second", etc. in the specification and claims of this application or the above-mentioned drawings are used to distinguish different objects, not to describe a specific order.

[0046] References herein to "embodiments" mean that a particular feature, structure, or characteristic described in connection with the embodiments may be included in at least one embodiment of the present application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it constitute an independent or alternative embodiment that is mutually exclusive of other embodiments. It is understood, both explicitly and implicitly, by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0047] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the accompanying drawings.

[0048] The present application is described in detail below with reference to the accompanying drawings and implementation methods.

[0049] It should be noted that the service dynamic load access method provided in the embodiment of the present application is generally executed on an Internet of Things platform, and accordingly, the service dynamic load access device is generally configured in the Internet of Things platform.

[0050] Please refer to FIG1 , which shows a specific implementation of a method for accessing dynamic service load.

[0051] It should be noted that the method of the present application is not limited to the process sequence shown in FIG1 if substantially the same result is achieved. The method includes the following steps:

[0052] S1: Build cluster worker nodes using multi-zone host nodes.

[0053] Specifically, the Kubernetes cluster working node is constructed through the multi-availability zone host nodes interconnected by multiple networks, wherein each of the multi-availability zone host nodes includes multiple host IPs.

[0054] In a specific embodiment, the K8S cluster working nodes are composed of multiple AZ host nodes ["AZ1":"IP11,IP12,…","AZ2":"IP21,IP22,…","AZ3":"IP31,IP32,…"] that are interconnected over the network.

[0055] Among them, multi-AZ (Multiple Availability Zones) refers to the multi-AZ storage architecture launched by Tencent Cloud Object Storage, which can provide data center-level disaster recovery capabilities for user data. Kubernetes, abbreviated as K8s, is an abbreviation formed by replacing the 8 characters "ubernete" in the middle of the name with 8. Kubernetes is an open source container orchestration engine from Google, which supports automated deployment, large-scale scalability, and application container management. When deploying an application in a production environment, it is usually necessary to deploy multiple instances of the application in order to load balance application requests. In an embodiment of the present application, the Kubernetes cluster working nodes are composed of multi-AZ host nodes, which is conducive to the subsequent identification of which multi-availability zones are the host IPs to which the services belong, thereby identifying the current availability zone to which it belongs, and facilitating load access to the service.

[0056] S2: Run the service on the Kubernetes cluster worker node and register the POD object information with Zookeeper.

[0057] Specifically, the service is run on the Kubernetes cluster worker node in a multi-instance POD manner, and after each service instance is started, the POD object information is registered with Zookeeper, and the target information is injected into the POD object through the container ENV environment variable.

[0058] ZooKeeper is a distributed, open-source service for coordinating distributed applications. It's an open-source implementation of Google's Chubby and a key component of Hadoop and HBase. A Pod object is the smallest and simplest Kubernetes object; a Pod encapsulates a container (or multiple containers), and the containers within a Pod share storage, networking, and other resources. In other words, the entire Pod can be considered a virtual machine, with each container acting as a process running within that virtual machine.

[0059] Please refer to FIG2 , which shows a specific implementation of step S2, which is described in detail as follows:

[0060] S21: Run the service on the Kubernetes cluster working node in a multi-instance POD manner.

[0061] S22: After each service instance is started, the POD object information is registered with Zookeeper, and target information is injected into the POD object through the container ENV environment variable. The target information includes the container IP, service port, and the host IP where the service is located.

[0062] Specifically, after each service instance is started, the POD object information is registered to Zookeeper in the form of {"ServiceName":"application name","IP":"container IP","PORT":"service port","MachineIP":"service host IP"}, and the container IP, service port, service host IP and other information are automatically injected into the POD object through the container ENV environment variables.

[0063] Among them, ENV is an external command, program file / bin / env, which lists all environment variables and their assignments. In the embodiment of the present application, the target information is injected into the POD object through the container ENV environment variable.

[0064] S3: Deploy the Nginx server to the multi-availability zone host node in the Kubernetes cluster worker node.

[0065] Specifically, the service's front-end load balancing uses the native Nginx server and deploys it on the multi-availability zone host nodes in the Kubernetes cluster worker nodes.

[0066] Among them, the Nginx server is a high-performance HTTP and reverse proxy web server, and also provides IMAP / POP3 / SMTP services.

[0067] S4: Deploy an agent program on the Nginx server in the multi-availability zone host node.

[0068] In an embodiment of the present application, an agent program (AGENT program) is deployed on the Nginx server in the multi-availability zone host node to identify the availability zone to which the service belongs and to provide the ability to dynamically load the configuration file of the Nginx server.

[0069] Furthermore, the information in the configuration file includes the availability zone distribution configuration information and other public configuration information in the Kubernetes cluster working nodes. Among them, the availability zone distribution configuration information in the Kubernetes cluster working nodes is: the AGENT program configuration in AZ1 describes the distribution of the Kubernetes cluster working nodes in availability zone 1 {"AZ1":"IP11,IP12,..."}, the AGENT program configuration in AZ2 describes the distribution of the Kubernetes cluster working nodes in availability zone 2 {"AZ2":"IP21,IP22,..."}, the AGENT program configuration in AZ3 describes the distribution of the Kubernetes cluster working nodes in availability zone 3 {"AZ3":"IP31,IP32,..."}, etc. Other public configuration information includes information such as the service registration Zookeeper address, the Nginx configuration file path, and the Nginx configuration file template.

[0070] S5: Based on the proxy program matching the current available zone of the service, a configuration file of the Nginx server on the host where the proxy program is located is updated.

[0071] Please refer to FIG3 , which shows a specific implementation of step S5, which is described in detail as follows:

[0072] S51: Monitoring the registration service in the Zookeeper based on the agent program.

[0073] S52: Determine whether the current available zone matches the host IP of the container service in the registration service, and obtain a determination result.

[0074] Specifically, after the agent program is started, it monitors the registration service in Zookeeper and determines whether the current availability zone matches the host IP of the container service in the registration service, thereby sensing the availability zone to which the service currently belongs, and using this to hot update the configuration file of the Nginx server on the host where the agent program is located.

[0075] S53: Based on the judgment result, the configuration file of the Nginx server on the host where the agent program is located is updated.

[0076] Please refer to Figures 4 to 7. Figure 4 shows a specific implementation of step S53. Figure 5 is a schematic diagram of load forwarding in an availability zone with a service instance provided in an embodiment of the present application. Figure 6 is a first schematic diagram of load forwarding in an availability zone with a service instance provided in an embodiment of the present application. Figure 7 is a second schematic diagram of load forwarding in an availability zone with a service instance provided in an embodiment of the present application. The details are as follows:

[0077] S531: If the judgment result is that the current availability zone matches the host IP of the container service in the registration service, the matched container service instance is obtained and the matched container service instance is dynamically written into the upstream module of the configuration file to forward the Nginx traffic to the nearest location.

[0078] As shown in Figure 5, the result of this determination is that the current availability zone matches the host IP address of the container service in the registration service. Therefore, in this embodiment of the application, a matching container service instance is obtained and dynamically written to the upstream module of the configuration file to forward Nginx traffic to the nearest service. Nginx traffic is only forwarded to services in the same availability zone, not across availability zones, which helps improve access performance.

[0079] S531: If the judgment result is that the current availability zone does not match the host IP of the container service instance in the registration service, all container service instances are dynamically written into the upstream module of the configuration file to fully forward the Nginx traffic based on the load policy.

[0080] As shown in Figures 6 and 7, the result is that the current availability zone does not match the host IP address of the container service instance in the registered service. Therefore, all container service instances are dynamically written to the upstream module of the configuration file to forward all Nginx traffic based on the load policy. If there are no service instances in an availability zone, Nginx traffic to the availability zone without service instances is forwarded to instances in other availability zones.

[0081] In an embodiment of the present application, a Kubernetes cluster working node is constructed through a multi-availability zone host node; a service is run on the Kubernetes cluster working node, and the information of the POD object is registered with Zookeeper; an Nginx server is deployed on the multi-availability zone host node in the Kubernetes cluster working node; an agent is deployed on the Nginx server in the multi-availability zone host node; and the configuration file of the host Nginx server where the agent is located is updated based on the agent matching the current availability zone of the service. In an embodiment of the present application, a Kubernetes cluster working node is constructed, a service is run on the Kubernetes cluster working node, and an Nginx server is deployed on the multi-availability zone host node in the Kubernetes cluster working node. The agent deployed on the Nginx server identifies the availability zone of the service, thereby realizing dynamic expansion and contraction of the service and improving the efficiency of service access.

[0082] In terms of multi-zone and multi-active capabilities, the embodiments of the present application achieve availability zone awareness, avoid cross-zone ingress traffic, shorten RTT (round-trip time), and improve access efficiency; compared with Ingress, the configurability is more flexible and convenient, and through NGINX direct communication with POD, the IP packet unpacking and service-based load forwarding of communication messages between containers are reduced, thereby reducing the loss of communication time.

[0083] Please refer to Figure 8. As an implementation of the method shown in Figure 1 above, the present application provides an embodiment of a service dynamic load access device. The device embodiment corresponds to the method embodiment shown in Figure 1, and the device can be specifically applied to the Internet of Things platform.

[0084] As shown in FIG8 , the service dynamic load access device of this embodiment includes: a working node construction unit 61, a POD object registration unit 62, an Nginx server deployment unit 63, an agent deployment unit 64, and a configuration file update unit 65, wherein:

[0085] A worker node construction unit 61 is used to construct a Kubernetes cluster worker node using multi-availability zone host nodes;

[0086] The POD object registration unit 62 is used to run the service on the Kubernetes cluster working node and register the POD object information in Zookeeper;

[0087] Nginx server deployment unit 63, used to deploy the Nginx server to the multi-availability zone host node in the Kubernetes cluster working node;

[0088] An agent program deployment unit 64 is configured to deploy an agent program to the Nginx server in the multi-availability zone host node;

[0089] The configuration file updating unit 65 is configured to update the configuration file of the Nginx server on the host where the proxy program is located based on matching the current available zone of the service with the proxy program.

[0090] Furthermore, the configuration file updating unit 65 includes:

[0091] A registration service monitoring unit, configured to monitor the registration service in the Zookeeper based on the agent program;

[0092] A judgment result generating unit is used to determine whether the current available zone matches the host IP of the container service in the registration service, and obtain a judgment result;

[0093] The file updating unit is used to update the configuration file of the Nginx server on the host where the agent program is located based on the judgment result.

[0094] Furthermore, the file updating unit includes:

[0095] A first updating unit is configured to, if the judgment result is that the current availability zone matches the host IP address of the container service in the registration service, obtain the matched container service instance, and dynamically write the matched container service instance into the upstream module of the configuration file to forward Nginx traffic to the nearest location;

[0096] The second update unit is used to dynamically write all container service instances into the upstream module of the configuration file if the judgment result is that the current availability zone does not match the host IP of the container service instance in the registration service, so as to fully forward the Nginx traffic based on the load policy.

[0097] Furthermore, the POD object registration unit 62 includes:

[0098] A service running unit, configured to run the service on the working node of the Kubernetes cluster in a multi-instance POD manner;

[0099] The information registration unit is used to register the information of the POD object with the Zookeeper after each service instance is started, and inject the target information into the POD object through the container ENV environment variable.

[0100] Furthermore, the target information includes the container IP, service port, and the host IP where the service is located.

[0101] Furthermore, the information in the configuration file includes the availability zone distribution configuration information and other public configuration information in the Kubernetes cluster working nodes; the other public configuration information includes the service registration Zookeeper address, the Nginx configuration file path and the Nginx configuration file template.

[0102] Furthermore, the working node construction unit 61 includes:

[0103] A Kubernetes cluster worker node generation unit is used to build the Kubernetes cluster worker node through the multi-availability zone host nodes interconnected by multiple networks, wherein each of the multi-availability zone host nodes includes multiple host IP addresses.

[0104] In an embodiment of the present application, a Kubernetes cluster working node is constructed through a multi-availability zone host node; a service is run on the Kubernetes cluster working node, and the information of the POD object is registered with Zookeeper; an Nginx server is deployed on the multi-availability zone host node in the Kubernetes cluster working node; an agent is deployed on the Nginx server in the multi-availability zone host node; and the configuration file of the host Nginx server where the agent is located is updated based on the agent matching the current availability zone of the service. In an embodiment of the present application, a Kubernetes cluster working node is constructed, a service is run on the Kubernetes cluster working node, and an Nginx server is deployed on the multi-availability zone host node in the Kubernetes cluster working node. The agent deployed on the Nginx server identifies the availability zone of the service, thereby realizing dynamic expansion and contraction of the service and improving the efficiency of service access.

[0105] In terms of multi-zone and multi-active capabilities, the embodiments of the present application achieve availability zone awareness, avoid cross-availability zone ingress traffic, shorten RTT (round-trip time), and improve access efficiency; compared with Ingress, the configurability is more flexible and convenient, and through NGINX direct communication with POD, the IP packet unpacking and service-based load forwarding of communication messages between containers are reduced, thereby reducing the loss of communication time.

[0106] To solve the above technical problems, the present application also provides an Internet of Things platform. Specifically, please refer to Figure 9, which is a basic structural block diagram of the Internet of Things platform of this embodiment.

[0107] The Internet of Things platform 7 includes a memory 71, a processor 72, and a network interface 73 that are interconnected through a system bus. It should be noted that the figure only shows an Internet of Things platform 7 with three components: a memory 71, a processor 72, and a network interface 73. However, it should be understood that it is not required to implement all the components shown, and more or fewer components can be implemented instead. Among them, those skilled in the art can understand that the Internet of Things platform here is a device that can automatically perform numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes but is not limited to microprocessors, application specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0108] The memory 71 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic storage, magnetic disk, optical disk, etc. In some embodiments, the memory 71 may be an internal storage unit of the IoT platform 7, such as the hard disk or memory of the IoT platform 7. In other embodiments, the memory 71 may also be an external storage device of the IoT platform 7, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash memory card, etc. equipped on the IoT platform 7. Of course, the memory 71 may also include both the internal storage unit of the IoT platform 7 and its external storage devices. In this embodiment, the memory 71 is generally used to store the operating system and various application software installed on the IoT platform 7, such as the program code of the service dynamic load access method. In addition, the memory 71 may also be used to temporarily store various types of data that have been output or are about to be output.

[0109] In some embodiments, the processor 72 may be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chip. The processor 72 is generally used to control the overall operation of the IoT platform 7. In this embodiment, the processor 72 is used to execute program code stored in the memory 71 or process data, such as executing the program code of the above-mentioned service dynamic load access method to implement various embodiments of the service dynamic load access method.

[0110] The network interface 73 may include a wireless network interface or a wired network interface. The network interface 73 is generally used to establish a communication connection between the Internet of Things platform 7 and other electronic devices.

[0111] The present application also provides another embodiment, namely, providing a computer-readable storage medium, which stores a computer program. The computer program can be executed by at least one processor to enable the at least one processor to perform the steps of a service dynamic load access method as described above.

[0112] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus the necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a number of instructions for enabling a terminal device (which can be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods of each embodiment of the present application.

[0113] Obviously, the embodiments described above are only some of the embodiments of the present application, rather than all of the embodiments. The preferred embodiments of the present application are given in the accompanying drawings, but they do not limit the patent scope of the present application. The present application can be implemented in many different forms. On the contrary, the purpose of providing these embodiments is to make the understanding of the disclosure of the present application more thorough and comprehensive. Although the present application has been described in detail with reference to the aforementioned embodiments, for those skilled in the art, it is still possible to modify the technical solutions described in the aforementioned specific embodiments, or to make equivalent replacements for some of the technical features therein. Any equivalent structure made using the contents of the present application specification and the accompanying drawings, directly or indirectly used in other related technical fields, is also within the scope of patent protection of the present application.

Claims

1. A method for accessing a service dynamic load, characterized in that: include: Build Kubernetes cluster worker nodes through multi-availability zone host nodes; Run the service on the working node of the Kubernetes cluster and register the POD object information to Zookeeper; Deploy the Nginx server to the multi-zone host node in the Kubernetes cluster worker node; Deploy an agent program on the Nginx server in the multi-availability zone host node; Based on the proxy program matching the current available zone of the service, the configuration file of the host Nginx server where the proxy program is located is updated.

2. The service dynamic load access method according to claim 1, characterized in that: The updating of the configuration file of the Nginx server of the host where the proxy program is located based on matching the current available zone of the service with the proxy program includes: Based on the agent program, the registration service in the Zookeeper is monitored; Determine whether the current available zone matches the host IP of the container service in the registration service, and obtain a determination result; Based on the judgment result, the configuration file of the host Nginx server where the proxy program is located is updated.

3. The service dynamic load access method according to claim 2, characterized in that: The updating of the configuration file of the host Nginx server where the proxy program is located based on the judgment result includes: If the judgment result is that the current availability zone matches the host IP of the container service in the registration service, the matched container service instance is obtained, and the matched container service instance is dynamically written into the upstream module of the configuration file to forward the Nginx traffic nearby; If the judgment result is that the current availability zone does not match the host IP where the container service instance in the registration service is located, all container service instances are dynamically written into the upstream module of the configuration file to fully forward the Nginx traffic based on the load strategy.

4. The service dynamic load access method according to claim 1, characterized in that: The process of running the service on the working node of the Kubernetes cluster and registering the information of the POD object to Zookeeper includes: Run the service on the working node of the Kubernetes cluster in a multi-instance POD manner; After each service instance is started, the information of the POD object is registered with the Zookeeper, and the target information is injected into the POD object through the container ENV environment variable.

5. The service dynamic load access method according to claim 4, characterized in that: The target information includes the container IP, service port, and the host IP where the service is located.

6. The service dynamic load access method according to any one of claims 1 to 5, characterized in that: The information in the configuration file includes the available zone distribution configuration information and other public configuration information in the working nodes of the Kubernetes cluster; the other public configuration information includes the service registration Zookeeper address, the Nginx configuration file path and the Nginx configuration file template.

7. The service dynamic load access method according to any one of claims 1 to 5, characterized in that: The method of building a Kubernetes cluster working node through multi-zone host nodes includes: The Kubernetes cluster working node is constructed through the multi-availability zone host nodes interconnected by multiple networks, wherein each of the multi-availability zone host nodes includes multiple host IPs.

8. A service dynamic load access device, characterized in that: include: Worker node construction unit, used to build Kubernetes cluster worker nodes through multi-availability zone host nodes; A POD object registration unit is used to run the service on the working node of the Kubernetes cluster and register the information of the POD object to Zookeeper; An Nginx server deployment unit, used to deploy the Nginx server to a multi-availability zone host node in the Kubernetes cluster working node; An agent program deployment unit, configured to deploy an agent program to the Nginx server in the multi-availability zone host node; The configuration file updating unit is used to update the configuration file of the host Nginx server where the proxy program is located based on matching the current available zone of the service with the proxy program.

9. An Internet of Things platform, characterized in that: The method comprises a memory and a processor, wherein the memory stores a computer program, and the processor implements the service dynamic load access method as claimed in any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the service dynamic load access method according to any one of claims 1 to 7 is implemented.

Images