A microservice hot restart method

Abstract

The present application provides a microservice hot restart method, which relates to the field of computer technology. The method includes: responding to the startup trigger event of a new container of the target service, obtaining the first lease of the new container from the database server; registering the first key-value pair of the new container according to the information of the target service, the information of the first lease and the configuration information of the new container; sending the first key-value pair of the new container to the database server, so that the database server triggers a key-value pair addition event for the new container, and after the gateway monitors the key-value pair addition event, it obtains the first key-value pair and updates it to the key-value pair list of the preset system application, and determines the target container for the received service access request according to the key-value pair list of the preset system application, so as to execute the business function of the service access request through the target container. The present application can ensure that the user's service access request is seamlessly transitioned when the microservice is upgraded, repaired or reconfigured, and realize the non-sensitive restart of the microservice.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a microservice hot restart method. Background Art

[0002] With the development of computer technology, the functions of system applications are becoming more and more complex. Based on this, the application of microservice architecture is becoming more and more extensive. With the continuous iteration and optimization of system applications, the hot restart of microservices becomes particularly important.

[0003] Hot restart of microservices refers to the process of hot restarting a running microservice instance without interrupting the service to provide external functions. This restart method aims to minimize the service interruption time and the impact on users. It is particularly used in systems that require high availability (HA) and continuous service. Summary of the invention

[0004] The purpose of the present invention is to provide a microservice hot restart method to address the deficiencies in the above-mentioned prior art, so as to ensure seamless transition of user service access requests and realize seamless restart of microservices when microservices are upgraded, repaired or reconfigured.

[0005] To achieve the above purpose, the technical solution adopted in the embodiment of the present application is as follows:

[0006] In a first aspect, an embodiment of the present application provides a microservice hot restart method, which is applied to a microserver, wherein the microserver is communicatively connected to a gateway, and the gateway is used to receive a service access request from a service client, and the microserver is deployed with: containers of multiple services of a preset system application, and the method includes:

[0007] In response to a start trigger event of a new container of a target service in the preset system application, obtaining a first lease of the new container from a database server;

[0008] Registering a first key-value pair of the new container according to the information of the target service, the information of the first lease, and the configuration information of the new container;

[0009] A first key-value pair of the new container is sent to the database server, so that the database server triggers a key-value pair addition event for the new container. After monitoring the key-value pair addition event, the gateway obtains the first key-value pair and updates it to the key-value pair list of the preset system application, and determines a target container for the received service access request according to the key-value pair list of the preset system application, so as to execute the business function of the service access request through the target container.

[0010] Optionally, registering a first key-value pair of the new container according to the information of the target service, the information of the first lease, and the configuration information of the new container includes:

[0011] Registering a first service information key-value pair of the new container according to the information of the target service, the information of the first lease, and the first service configuration information of the new container;

[0012] According to the routing information of the new container, the information of the first lease and the second service configuration information of the new container, a first routing information key-value pair of the new container is registered, where the first key-value pair includes: the first service information key-value pair and the first routing information key-value pair.

[0013] Optionally, registering the first service information key-value pair of the new container according to the information of the target service, the information of the first lease, and the first service configuration information of the new container includes:

[0014] Determine a service key in the first service information key-value pair according to the information of the target service and the information of the first lease;

[0015] The service value of the first service information key-value pair is determined according to the first service configuration information of the new container, where the first service information key-value pair includes: the service key and the service value.

[0016] Optionally, registering the first routing information key-value pair of the new container according to the routing information of the new container, the information of the first lease, and the second service configuration information of the new container includes:

[0017] Determine a routing key in the first routing information key-value pair according to the routing information of the new container and the information of the first lease;

[0018] According to the second service configuration information of the new container, a routing value in the first routing information key-value pair is determined, where the first routing information key-value pair includes: the routing key and the routing value.

[0019] Optionally, the method further comprises:

[0020] If it is monitored that the remaining effective time of the first lease meets a preset renewal trigger condition, the renewed first lease is obtained from the database service.

[0021] Optionally, the method further comprises:

[0022] In response to a trigger event that the old container of the target service stops running, a lease revocation request is sent to the database server, so that the database server marks the second lease of the old container as revoked, and deletes the second key-value pair of the old container after the marked second lease expires. After monitoring the key-value pair deletion event, the gateway deletes the second key-value pair from the key-value pair list of the preset system application.

[0023] In a second aspect, an embodiment of the present application further provides a microservice hot restart method, which is applied to a gateway, wherein the gateway is in communication connection with a microserver, and wherein the microserver is deployed with: containers of multiple services of a preset system application, and the method comprises:

[0024] Monitor the online key-value pair list of the preset system application in the database server;

[0025] If a key-value pair new event is monitored, obtain the first key-value pair of the new container of the target service from the key-value pair new event;

[0026] Updating the first key-value pair to the locally stored key-value pair list of the preset system application;

[0027] If a service access request sent by a service client is received, determining a target container for the received service access request according to the key-value pair list of the preset system application;

[0028] The service access request is sent to the target container, so that the target container executes the business function of the service access request.

[0029] Optionally, the first key-value pair includes: a first service information key-value pair and a first routing information key-value pair, and the monitoring of an online key-value pair list of a preset system application in the database server includes:

[0030] Create service listening threads and routing listening threads through the database client;

[0031] The online key-value pair list is monitored respectively by the service monitoring thread and the routing monitoring thread;

[0032] If a key-value pair newly added event is monitored, obtaining a first key-value pair of a new container of the target service from the key-value pair newly added event includes:

[0033] If the service monitoring thread monitors a new event of a service information key-value pair, obtaining the first service information key-value pair from the new event of the service information key-value pair;

[0034] If the routing monitoring thread monitors a new event of the routing information key-value pair, the first routing information key-value pair is obtained from the new event of the routing information key-value pair;

[0035] The updating of the first key-value pair to the locally stored key-value pair list of the preset system application includes:

[0036] Execute a predefined service information key-value pair adding operation method to update the first service information key-value pair to the key-value pair list of the preset system application stored locally;

[0037] A predefined routing information key-value pair adding operation method is executed to update the first routing information key-value pair to the locally stored key-value pair list of the preset system application.

[0038] Optionally, the method further comprises:

[0039] If a key-value pair deletion event is monitored, obtain the second key-value pair of the old container of the target service from the key-value pair deletion event;

[0040] A predefined key-value pair deletion operation method is executed to delete the second key-value pair from the locally stored key-value pair list of the preset system application.

[0041] Optionally, the service access request includes: a request method and a request path; and determining a target container for the received service access request according to the key-value pair list of the preset system application includes:

[0042] According to the request method and the request path, sequentially use multiple matching modes to perform routing matching on multiple routing information key-value pairs in the key-value pair list to determine at least one matching routing information key-value pair;

[0043] Determine, according to the at least one matching route information key-value pair, at least one corresponding matching service information key-value pair;

[0044] Determining at least one matching container from the multiple containers according to the at least one matching service information key-value pair;

[0045] According to a preset request allocation strategy, a target container is determined from the at least one matching container.

[0046] In a third aspect, an embodiment of the present application provides a microservice hot restart device, which is applied to a microserver, wherein the microserver is communicatively connected to a gateway, and the gateway is used to receive a service access request from a service client, and wherein the microserver is deployed with: containers for multiple services of a preset system application, and the device includes:

[0047] A lease module, configured to respond to a start trigger event of a new container of a target service in the preset system application and obtain a first lease of the new container from a database server;

[0048] A registration module, configured to register a first key-value pair of the new container according to information of the target service, information of the first lease, and configuration information of the new container;

[0049] a sending module, configured to send the first key-value pair of the new container to the database server, so that the database server triggers a key-value pair newly added event for the new container; after monitoring the key-value pair newly added event, the gateway obtains the first key-value pair and updates it to the key-value pair list of the preset system application; and determines a target container for the received service access request according to the key-value pair list of the preset system application, so as to execute the business function of the service access request through the target container.

[0050] Optionally, the registration module is specifically used to register a first service information key-value pair of the new container according to information of the target service, information of the first lease, and first service configuration information of the new container; and to register a first routing information key-value pair of the new container according to routing information of the new container, information of the first lease, and second service configuration information of the new container, wherein the first key-value pair includes: the first service information key-value pair and the first routing information key-value pair.

[0051] Optionally, the registration module is specifically used to determine the service key in the first service information key-value pair based on the information of the target service and the information of the first lease; determine the service value of the first service information key-value pair based on the first service configuration information of the new container, and the first service information key-value pair includes: the service key and the service value.

[0052] Optionally, the registration module is specifically used to determine the routing key in the first routing information key-value pair according to the routing information of the new container and the information of the first lease; determine the routing value in the first routing information key-value pair according to the second service configuration information of the new container, and the first routing information key-value pair includes: the routing key and the routing value.

[0053] Optionally, the lease module is further configured to obtain the renewed first lease from the database service if it is monitored that the remaining effective time of the first lease meets a preset renewal trigger condition.

[0054] Optionally, the lease module is further used to respond to a trigger event of the old container of the target service stopping operation, send a lease revocation request to the database server, so that the database server marks the second lease of the old container as revoked, and deletes the second key-value pair of the old container after the marked second lease expires. After monitoring the key-value pair deletion event, the gateway deletes the second key-value pair from the key-value pair list of the preset system application.

[0055] In a fourth aspect, an embodiment of the present application further provides a microservice hot restart device, which is applied to a gateway, wherein the gateway is communicatively connected to a microserver, wherein the microserver is deployed with: containers of multiple services of a preset system application, wherein the device comprises:

[0056] A monitoring module, used to monitor the online key-value pair list of the preset system application in the database server;

[0057] An acquisition module, configured to acquire a first key-value pair of a new container of a target service from a key-value pair newly added event if a key-value pair newly added event is monitored;

[0058] A storage module, used for updating the first key-value pair to a locally stored key-value pair list of the preset system application;

[0059] A matching module, configured to determine a target container for the received service access request according to the key-value pair list of the preset system application if a service access request sent by the service client is received;

[0060] The forwarding module is configured to send the service access request to the target container so that the target container executes the business function of the service access request.

[0061] Optionally, the first key-value pair includes: a first service information key-value pair and a first routing information key-value pair, and the monitoring module is specifically used to create a service monitoring thread and a routing monitoring thread through a database client; and monitor the online key-value pair list through the service monitoring thread and the routing monitoring thread respectively;

[0062] The acquisition module is specifically used to acquire the first service information key-value pair from the newly added event of the service information key-value pair if the service monitoring thread monitors the newly added event of the service information key-value pair; if the routing monitoring thread monitors the newly added event of the routing information key-value pair, acquire the first routing information key-value pair from the newly added event of the routing information key-value pair;

[0063] The storage module is specifically used to execute a predefined service information key-value pair adding operation method, and update the first service information key-value pair to the key-value pair list of the preset system application stored locally; execute a predefined routing information key-value pair adding operation method, and update the first routing information key-value pair to the key-value pair list of the preset system application stored locally.

[0064] Optionally, the acquisition module is further configured to acquire the second key-value pair of the old container of the target service from the key-value pair deletion event if a key-value pair deletion event is monitored;

[0065] The deleting module is used to execute a predefined key-value pair deletion operation method to delete the second key-value pair from the locally stored key-value pair list of the preset system application.

[0066] Optionally, the service access request includes: a request method and a request path; the matching module is specifically used to perform routing matching on multiple routing information key-value pairs in the key-value pair list in turn using multiple matching methods according to the request method and the request path, and determine at least one matching routing information key-value pair; determine at least one corresponding matching service information key-value pair according to the at least one matching routing information key-value pair; determine at least one matching container from multiple containers according to the at least one matching service information key-value pair; and determine a target container from the at least one matching container according to a preset request allocation strategy.

[0067] In a fifth aspect, an embodiment of the present application also provides an electronic device, comprising: a processor, a storage medium and a bus, wherein the storage medium stores program instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium through the bus, and the processor executes the program instructions to perform the steps of the microservice hot restart method as described in either the first aspect or the second aspect.

[0068] In a sixth aspect, an embodiment of the present application further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the microservice hot restart method as described in any one of the first aspect or the second aspect are executed.

[0069] The beneficial effects of this application are:

[0070] The microservice hot restart method provided by the present application applies for a first lease for the new container when creating a new container for a target service in a microserver, and registers a first key-value pair for the new container based on information about the target service, information about the first lease, and configuration information of the new container, and stores the first key-value pair in a database server. The gateway can obtain the first key-value pair of the new container from the database server, so that when the gateway receives a service access request, it can route the service access request to an old container of the target service or to a new container of the target service. The new container and the old container of the target service run in parallel, and the deployment of the new container can be completed without shutting down the microserver. For users, a seamless restart of the microservice can be achieved, ensuring the continuity and availability of the service. BRIEF DESCRIPTION OF THE DRAWINGS

[0071] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for use in the embodiments are briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present invention and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without creative work.

[0072] Figure 1 An architectural diagram of a microservice hot restart system provided in an embodiment of the present application;

[0073] Figure 2 Schematic diagram of the process of microservice hot restart method provided in the embodiment of the present application Figure 1 ;

[0074] Figure 3 Schematic diagram of the process of microservice hot restart method provided in the embodiment of the present application Figure 2 ;

[0075] Figure 4 Schematic diagram of the process of microservice hot restart method provided in the embodiment of the present application Figure 3 ;

[0076] Figure 5 Schematic diagram of the process of microservice hot restart method provided in the embodiment of the present application Figure 4 ;

[0077] Figure 6 Schematic diagram of the process of microservice hot restart method provided in the embodiment of the present application Figure 5 ;

[0078] Figure 7 A schematic diagram of the process of gateway discovery service routing and microserver registration service routing provided in the embodiment of the present application;

[0079] Figure 8A schematic diagram of the service route matching process provided in the embodiment of the present application;

[0080] Fig. 9 A schematic diagram of the process of hot restarting a microservice provided in an embodiment of the present application;

[0081] Fig.10 A schematic diagram of the structure of the microservice hot restart device provided in the embodiment of the present application Figure 1 ;

[0082] Fig.11 A schematic diagram of the structure of the microservice hot restart device provided in the embodiment of the present application Figure 2 ;

[0083] Fig.12 A schematic diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0084] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments.

[0085] Therefore, the following detailed description of the embodiments of the present application provided in the accompanying drawings is not intended to limit the scope of the present application for which protection is sought, but merely represents selected embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without creative work are within the scope of protection of the present application.

[0086] In the description of the present application, it should be noted that if the terms "upper", "lower", etc. appear, the orientation or position relationship indicated is based on the orientation or position relationship shown in the drawings, or is the orientation or position relationship in which the product of the application is usually placed when used. It is only for the convenience of describing the present application and simplifying the description, and does not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as a limitation on the present application.

[0087] In addition, the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0088] It should be noted that, in the absence of conflict, the features in the embodiments of the present application may be combined with each other.

[0089] In order to better understand this solution, the microservice hot restart system used in this application is first introduced below.

[0090] Figure 1 The architecture diagram of the microservice hot restart system provided in the embodiment of the present application is as follows: Figure 1 As shown, the microservice hot restart system includes: multiple microservices Microservices, a gateway API Gateway, a service client, a database client and a database server.

[0091] Among them, the system application is divided into multiple microservices Microservices and a gateway API Gateway. Among them, the multiple microservices Microservices are multiple independently deployed services split from the system application. Each service focuses on realizing the business functions of a specified scenario. Each service can be independently developed, deployed and expanded. Multiple microservices Microservices can be deployed and run on the same server or on different servers. This embodiment does not limit this. The server used to execute microservices is also called a microserver.

[0092] The API Gateway is an intermediate layer between multiple microservices and service clients. The service client is a user-oriented client. Users access the microservice through the service client to obtain the business functions provided by the microservice.

[0093] The database client is a key-value database client, which provides an API (etcd.client) for the gateway API Gateway. etcd.client is a client application connected to the database server, responsible for interacting with the database server ETCD and processing key-value events. The database client provides an interface API for the gateway API Gateway so that the gateway API Gateway client can obtain key-value information from the database server. The database server is a key-value database server ETCD. etcd.server is an etcd instance running on the database server, responsible for storing and managing distributed key-value information.

[0094] For each microservice of the system application, one or more containers can be created for each microservice, and the business functions corresponding to the microservice can be executed through the container to provide corresponding services to users.

[0095] The following first introduces the normal startup and application process of microservices.

[0096] When a microservice is started, a fixed number of containers have been deployed on the corresponding microserver. In order to distinguish them from the containers in the hot restart process, the containers deployed when the microservice is started are called old containers PodsOld. The microserver sends a lease request to the instance of the key-value database server etcd.server through etcd.client, requesting to establish a new lease lease, and specifying the expiration time TTL of the lease in the request. After receiving the lease request, etcd.server processes it and generates a unique lease identifier (lease_id) for each old container PodsOld, and returns the generated lease_id to etcd.client. Each old container PodsOld corresponds to a unique lease_id, thereby ensuring the uniqueness of the container. Once the lease is created, it will start timing in etcd.server until it expires and automatically becomes invalid.

[0097] After creating the lease, the microserver associates the lease with the key of the old container PodsOld. When the lease expires, the associated key is automatically deleted by ETCD, thereby achieving the effect of automatic deregistration of the old container PodsOld.

[0098] When the old container PodsOld is started, the service information key-value pair kv.service is registered and associated with the created lease_id. The key-value prefix is ​​service. The key in the key-value pair contains the service name (service_name) and the lease ID (lease_id), and the value contains the service address (address), version number (version) and current limiter (limiter) and other information. etcd.client sends the key-value pair Put instruction. After etcd.server receives the key-value pair Put instruction and stores the kv.service information, it notifies etcd.client that listens to the service prefix to receive the Put event.

[0099] When the old container PodsOld is started, the route information key-value pair kv.route is registered and associated with the created lease_id. The key-value prefix is ​​route. The key in the key-value pair contains route (route) and lease ID (lease_id), and the value Value contains information such as service name (service_name), version number (version) and current limiter. etcd.client sends a Put key-value pair instruction. After etcd.server receives the Put instruction and stores the kv.route information, it notifies etcd.client that listens to the route prefix to receive the Put event.

[0100] When the gateway API Gateway starts, it establishes the service discovery process Service.client and the route discovery process Route.client through etcd.client. The gateway API Gateway starts the service discovery process Service.client, discovers the key-value pair list of the service prefix through etcd.client, and initializes the key-value pair kv.services for storage. Microservices need to deploy multiple container Pods at the same time. Since lease_id is unique, the uniqueness of the microservice can be ensured through the Key = service_name + lease_id.

[0101] The gateway API Gateway starts the route discovery process Service.client, discovers the key-value pair list of the route prefix through etcd.client, and initializes the key-value pair kv.routes for storage. Microservices need to deploy multiple container Pods at the same time, and the uniqueness of microservice routes can be ensured through Key = route + lease_id.

[0102] When the gateway API Gateway receives the service access request from the service client, it matches the target old container PodsOld for the service client, and the target old container PodsOld processes the service access request to provide the user with the business functions of the microservice corresponding to the target old container PodsOld.

[0103] The following describes a micro server hot restart method applied to a micro server provided by the present application in conjunction with an embodiment.

[0104] Figure 2 Schematic diagram of the process of microservice hot restart method provided in the embodiment of the present application Figure 1 ,like Figure 2 As shown, the method may include:

[0105] S101: Responding to a startup trigger event of a new container of a target service in a preset system application, obtaining a first lease of the new container from a database server.

[0106] In this embodiment, the preset system application can be split into multiple independently deployed services, each service focuses on implementing the business functions of a specified scenario, and each service can serve as a microservice of the preset system application. The multiple services split from the preset system application can be deployed on the same server or on different servers. The server used to deploy the services split from the system application can also be called a microserver.

[0107] At least one container for each microservice is created on the microserver, and each container is used to execute the business function corresponding to the microservice. Multiple containers can execute the business functions corresponding to the microservice in the same way or in different ways. For example, the login function of the system application is implemented through a microservice, and the system application provides two login methods, including account password login and verification code login. Then the two containers on the microservice can be used to execute account password login and verification code login respectively. If the system application only provides one login method, all containers on the microservice are used to execute the same login method.

[0108] After the microservices of the system application are upgraded, repaired, or reconfigured, a new container needs to be created for the updated microservice to execute the business functions of the updated microservice through the new container.

[0109] After creating a new container for the target service on the microserver, the new container is started, and the microserver applies for a lease for the new container based on the start trigger event for the new container.

[0110] Specifically, the microserver sends a lease request to the instance etcd.server of the key-value database server through etcd.client, requesting to establish a new lease lease, and specifying the expiration time TTL of the lease in the request. After receiving the lease request, etcd.server processes it and generates the first lease for the new container PodsNew. The first lease has a unique lease identifier (lease_id), and returns the lease identifier lease_id of the first lease to etcd.client, which sends the lease identifier lease_id of the first lease to the microserver.

[0111] S102: Register a first key-value pair of the new container according to the information of the target service, the information of the first lease, and the configuration information of the new container.

[0112] In this embodiment, the information of the target service includes the service name (service_name) of the target service, the information of the first lease includes the lease identifier (lease_id) of the first lease, the configuration information of the new container may at least include: routing information of the new container, address information of the new container, and may also include version information of the new container and current limiting control information of the new container. According to the above information, a first key-value pair of the new container is registered and generated, and the first key-value pair includes a key Key and a value Value.

[0113] S103: Sending the first key-value pair of the new container to the database server, so that the database server triggers a key-value pair addition event for the new container. After monitoring the key-value pair addition event, the gateway obtains the first key-value pair and updates it to the key-value pair list of the preset system application, and determines the target container for the received service access request according to the key-value pair list of the preset system application, so as to execute the business function of the service access request through the target container.

[0114] In this embodiment, after the microserver registers and generates the first key-value pair of a new container, it needs to store the first key-value pair in the database server. Specifically, a key-value pair addition instruction is sent to etcd.server through etcd.client. The key-value pair addition instruction includes: the first key-value pair. After etcd.server receives the key-value pair addition instruction, it executes the key-value pair addition event.

[0115] The gateway establishes a listening thread through the key-value pair client to listen to the key-value pair related events executed by the key-value pair server. etcd.server executes the key-value pair new event and notifies etcd.client to receive the key-value pair new event. After listening to the key-value pair new event, the gateway listening thread takes out the first key-value pair etcd.kv contained in the key-value pair new event, executes the predefined operation method, and adds the first key-value pair etcd.kv to the key-value pair list of the preset system application stored locally. The key-value pair list of the preset system application stored locally also stores the key-value pair of the old container obtained from etcd.server when the microservice is started.

[0116] When the gateway receives a service access request sent by the user through the service client, it matches the service information from multiple key-value pairs in the key-value pair list according to the service information carried in the service access request, and determines the target container corresponding to the matching key-value pair. The target container can be the old container PodsOld or the new container PodsNew. The gateway sends the service access request to the target container, so that the target container can provide the user with corresponding business functions based on the corresponding microservices.

[0117] In a possible implementation, the above S102 registers the first key-value pair of the new container according to the information of the target service, the information of the first lease, and the configuration information of the new container, including:

[0118] According to the information of the target service, the information of the first lease and the first service configuration information of the new container, register the first service information key-value pair of the new container; according to the routing information of the new container, the information of the first lease and the second service configuration information of the new container, register the first routing information key-value pair of the new container, the first key-value pair including: the first service information key-value pair and the first routing information key-value pair.

[0119] In this embodiment, the first key-value pair includes: a first service information key-value pair and a first routing information key-value pair, the first routing information key-value pair is used to indicate the routing information of the new container, the first service information key-value pair is used to indicate the service information of the new container, the information of the target service includes the service name (service_name) of the target service, the information of the first lease includes the lease identifier (lease_id) of the first lease, the first service configuration information of the new container may at least include: the address information (Address) of the new container, and may also include the version information (Version) of the new container and the current limiting control information (Limiter) of the new container, and the first service information key-value pair may be generated according to the service name (service_name) of the target service, the lease identifier (lease_id) of the first lease, the address information (Address) of the new container, the version information (Version) of the new container and the current limiting control information (Limiter) of the new container.

[0120] The second service configuration information of the new container may include at least: the service name of the target service (service_name), and may also include version information (Version) of the new container and current limiting control information (Limiter) of the new container. The first routing information key-value pair may be generated according to the routing information (route) of the target service, the lease identifier (lease_id) of the first lease, the service name (service_name) of the target service, the version information (Version) of the new container, and the current limiting control information (Limiter) of the new container.

[0121] In a possible implementation, registering the first service information key-value pair of the new container according to the target service information, the first lease information, and the first service configuration information of the new container includes:

[0122] Determine a service key in a first service information key-value pair according to information of the target service and information of the first lease; determine a service value of the first service information key-value pair according to first service configuration information of the new container, wherein the first service information key-value pair includes: a service key and a service value.

[0123] In this embodiment, the first service information key-value pair includes: a service key serviceKey and a service value serviceValue. The service key serviceKey in the first service information key-value pair can be formed according to the service name (service_name) of the target service and the lease identifier (lease_id) of the first lease, and the service value serviceValue of the first service information key-value pair can be formed according to the address information (Address) of the new container, the version information (Version) of the new container and the current limiting control information (Limiter) of the new container, wherein the service value serviceValue can also include other service information about the new container.

[0124] In a possible implementation, registering the first routing information key-value pair of the new container according to the routing information of the new container, the information of the first lease, and the second service configuration information of the new container includes:

[0125] According to the routing information of the new container and the information of the first lease, a routing key in the first routing information key-value pair is determined; according to the second service configuration information of the new container, a routing value in the first routing information key-value pair is determined, and the first routing information key-value pair includes: a routing key and a routing value.

[0126] In this embodiment, the first routing information key-value pair includes: a routing key routeKey and a routing value routeValue. The routing key routeKey in the first routing information key-value pair can be formed according to the routing information (route) of the target service and the lease identifier (lease_id) of the first lease. The routing value routeValue in the first routing information key-value pair is generated according to the service name (service_name) of the target service, the version information (Version) of the new container, and the current limiting control information (Limiter) of the new container. The routing value routeValue can also include other service information about the new container.

[0127] The microservice hot restart method provided in the above embodiment applies for a first lease for the new container when creating a new container for the target service in the microserver, and registers a first key-value pair for the new container based on the information of the target service, the information of the first lease, and the configuration information of the new container, and stores the first key-value pair in the database server. The gateway can obtain the first key-value pair of the new container from the database server, so that when the gateway receives a service access request, it can route the service access request to the old container of the target service or to the new container of the target service. The new container and the old container of the target service run in parallel, and the deployment of the new container can be completed without shutting down the microserver. For users, a seamless restart of the microservice can be achieved, ensuring the continuity and availability of the service.

[0128] In a possible implementation, the method may further include:

[0129] If it is monitored that the remaining effective time of the first lease meets the preset renewal trigger condition, the renewed first lease is obtained from the database service.

[0130] In this embodiment, when the micro server applies for a lease from the database server, it will specify the expiration time TTL of the lease in the request. After the lease is created, the database server will start counting until the lease expires.

[0131] Since the database server will delete the key-value pair associated with the lease after the lease expires to achieve the effect of automatic deregistration of the container, the microserver needs to listen to the first lease. Specifically, the microserver performs heartbeat detection and listens to ListenLease on the first lease. Before determining that the first lease is about to expire, the microserver applies to the database server to extend the validity period of the lease to ensure that the first lease can maintain consistency with the service status of the new container.

[0132] Among them, the microserver can initiate a renewal request to etcd.server when the remaining validity time of the first lease meets the preset renewal trigger condition. After receiving the renewal request, etcd.server updates the expiration time of the first lease and extends the validity period of the first lease. For example, the preset renewal trigger condition can be a preset time before the expiration time TTL of the lease, for example, it can be 1 / 3TTL.

[0133] The microservice hot restart method provided in the above embodiment monitors the remaining valid time of the first lease and renews the first lease when the preset renewal trigger condition is met, thereby ensuring that the validity period of the first lease can be maintained consistent with the service status of the new container, so that when the new container can provide services, the service access request is routed to the new container through the valid first key-value pair to ensure the normal operation of the business function.

[0134] In a possible implementation, the method may further include:

[0135] In response to a trigger event that the old container of the target service stops running, a lease revocation request is sent to the database server, so that the database server marks the second lease of the old container as revoked, and deletes the second key-value pair of the old container after the marked second lease expires. After listening to the key-value pair deletion event, the gateway deletes the second key-value pair from the key-value pair list of the preset system application.

[0136] In this embodiment, after the microservice of the system application is upgraded, repaired or reconfigured, a new container is created for the updated microservice. To this end, the old container corresponding to the microservice before the update needs to be stopped. After the old container stops running, in order to avoid routing the newly received service access request to the old container, the key-value pair of the old container needs to be deleted.

[0137] Specifically, the microserver initiates a lease revocation request to etcd.server through etcd.client. The lease revocation request includes the lease_id of the second lease of the old container PodsOld. After etcd.server receives the lease revocation request, it marks the second lease as revoked. The purpose of marking it as revoked is that when the microserver initiates a lease renewal request to etcd.server again, the second lease will no longer be renewed.

[0138] After the second lease expires, the old container detects the expiration of the second lease through the heartbeat detection listener ListenLease and stops running the old container. etcd.server will delete the second key-value pair of the old container PodsOld. etcd.server notifies etcd.client to receive the key-value pair deletion event. At this time, after listening to the key-value pair deletion event, the gateway's listening thread takes out the second key-value pair etcd.kv contained in the key-value pair deletion event, executes the predefined operation method, and deletes the second key-value pair etcd.kv from the key-value pair list of the preset system application stored locally.

[0139] Therefore, between the time when the second lease of the old container PodsOld is marked as revoked and the time when the second lease expires, the second key-value pair of the old container PodsOld is still stored in the key-value pair list of the preset system application. At this time, the gateway can still route the service access request to the old container PodsOld. When the second lease expires and the second key-value pair is deleted, since the key-value pair list of the preset system application no longer contains the second key-value pair, after receiving the service access request, the gateway can only route the service access request to the new container PodsNew.

[0140] In the microservice hot restart method provided in the above embodiment, when the old container of the target service is to stop running, a lease revocation request can be first sent to the database server to revoke the second lease of the old container, and the second key-value pair of the old container can be deleted after the second lease expires. The gateway synchronously deletes the second key-value pair in the key-value pair list, thereby enabling the gateway to route only to the old container, to the new container, or to the old container, until only to the new container, thereby realizing the hot restart of the microservice and ensuring the stability of the microservice. The microservice hot restart process determines that the service is not interrupted, so as to realize the hot restart without user perception.

[0141] The following describes a microservice hot restart method for a gateway provided in the present application in conjunction with an embodiment.

[0142] Figure 3 Schematic diagram of the process of microservice hot restart method provided in the embodiment of the present application Figure 2 ,like Figure 3 As shown, the method may include:

[0143] S201: monitoring an online key-value pair list of a preset system application in a database server.

[0144] In this embodiment, the database server stores an online key-value pair list of preset system applications, and the online key-value pair list is used to store the key-value pairs registered by the micro-server to the container corresponding to each service.

[0145] The gateway establishes a listening thread through the database client, monitors the online key-value pair list of the preset system application in the database server, and determines whether the online key-value pair list has changed. When the online key-value pair list changes, the database server will notify the database client of the change event, so that the listening thread can monitor the change event of the online key-value pair list.

[0146] S202: If a key-value pair added event is monitored, obtain the first key-value pair of the new container of the target service from the key-value pair added event.

[0147] In this embodiment, after monitoring the key-value pair newly added event, the gateway monitoring thread retrieves the first key-value pair included in the key-value pair newly added event.

[0148] S203: Update the first key-value pair to the locally stored key-value pair list of preset system applications.

[0149] In this embodiment, the gateway executes a predefined operation method to add a first key-value pair to a locally stored key-value pair list of preset system applications, and the locally stored key-value pair list of preset system applications also stores the key-value pair of the old container obtained from etcd.server when the microservice is started.

[0150] S204: If a service access request sent by a service client is received, a target container is determined for the received service access request according to a preset system application key-value pair list.

[0151] In this embodiment, when the gateway receives a service access request sent by the user through the service client, it matches the service information from multiple key-value pairs in the key-value pair list according to the service information carried in the service access request, and determines the target container corresponding to the matching key-value pair. The target container can be an old container PodsOld or a new container PodsNew.

[0152] S205: Send a service access request to the target container, so that the target container executes the business function of the service access request.

[0153] In this embodiment, the gateway sends the service access request to the target container, so that the target container can provide the user with corresponding business functions based on the microservices corresponding to the target container.

[0154] In a possible implementation manner, the first key-value pair includes: a first service information key-value pair and a first routing information key-value pair. Figure 4 Schematic diagram of the process of microservice hot restart method provided in the embodiment of the present application Figure 3 ,like Figure 4 As shown, the process of monitoring the online key-value pair list of the preset system application in the database server in S201 may include:

[0155] S211: Create a service listening thread and a routing listening thread through the database client.

[0156] In this embodiment, when the gateway API Gateway is started, the service discovery process Service.client and the route discovery process Route.client are established through the etcd.client provided by the database client.

[0157] The service process Service.client is discovered. On the one hand, when the gateway API Gateway is started, it discovers the key-value pair list of the service prefix through etcd.client and stores the service information key-value pair kv.services locally. On the other hand, it is discovered that the service process Service.client establishes a service monitoring thread service.Watcher through etcd.client.

[0158] It is found that the routing process Route.client discovers the key-value pair list of the route prefix through etcd.client when the gateway API Gateway is started, and stores the routing information key-value pair kv.routes locally. On the other hand, it is found that the routing process Route.client establishes the routing listening thread route.Watcher through etcd.client.

[0159] S212: Monitor the online key-value pair list through the service monitoring thread and the routing monitoring thread respectively.

[0160] In this embodiment, the service monitoring thread service.Watcher is used to monitor the service information key-value pairs prefixed with service contained in the key-value pair newly added event Put received by etcd.server, and the routing monitoring thread route.Watcher is used to monitor the routing information key-value pairs prefixed with route contained in the key-value pair newly added event Put received by etcd.server.

[0161] If a key-value pair newly added event is monitored in the above S202, the process of obtaining the first key-value pair of the new container of the target service from the key-value pair newly added event may include:

[0162] S221: If the service monitoring thread monitors a new event of a service information key-value pair, obtain a first service information key-value pair from the new event of the service information key-value pair.

[0163] In this embodiment, when etcd.server receives a Put operation with a prefix of service sent by the microserver, it writes the first service information key-value pair into the database server for storage. The Put operation is used to add or update the key-value pair. etcd.server will notify the etcd.client that listens to the prefix of service of the occurrence of the Put event. After the service monitoring thread service.Watcher monitors the Put event through etcd.client, it can take out the first service information key-value pair contained in the Put event.

[0164] S222: If the routing monitoring thread monitors a new event of the routing information key-value pair, obtain a first routing information key-value pair from the new event of the routing information key-value pair.

[0165] In this embodiment, when etcd.server receives a Put operation with a prefix of route sent by the microserver, it writes the first routing information key-value pair into the database server for storage. The Put operation is used to add or update the key-value pair. etcd.server will notify the etcd.client that listens to the prefix of route of the occurrence of the Put event. After the routing monitoring thread route.Watcher monitors the Put event through etcd.client, it can take out the first routing information key-value pair contained in the Put event.

[0166] The process of updating the first key-value pair to the locally stored key-value pair list of the preset system application in S203 may include:

[0167] S231: Execute a predefined service information key-value pair adding operation method to update the first service information key-value pair to a locally stored preset system application key-value pair list.

[0168] In this embodiment, a new operation method kv.service.update for service information key-value pairs is pre-defined in the gateway API Gateway. After the service monitoring thread service.Watcher monitors the Put event through etcd.client, it takes out the first service information key-value pair contained in the Put event, and the new operation method kv.service.update for the service information key-value pair is used to update the key-value pair list of the preset system application stored locally, and the service key serviceKey in the first service information key-value pair, that is, the service name (service_name) of the target service and the lease identifier (lease_id) of the first lease, the service value serviceValue, that is, the address information (Address) of the new container, the version information (Version) of the new container and the current limiting control information (Limiter) of the new container are stored in the key-value pair list.

[0169] S232: Execute a predefined routing information key-value pair adding operation method to update the first routing information key-value pair to a locally stored preset system application key-value pair list.

[0170] In this embodiment, a new operation method kv.route.update for routing information key-value pairs is pre-defined in the gateway API Gateway. After the routing listening thread route.Watcher listens to the Put event through etcd.client, it takes out the first routing information key-value pair contained in the Put event, and the new operation method kv.route.update for routing information key-value pairs is used to update the key-value pair list of the preset system application stored locally, and the routing key routeKey in the first routing information key-value pair, that is, the routing information (route) of the target service and the lease identifier (lease_id) of the first lease, the routing value routeValue, that is, the service name (service_name) of the target service, the version information (Version) of the new container, and the current limiting control information (Limiter) of the new container are stored in the key-value pair list.

[0171] In the microservice hot restart method provided by the above embodiment, the gateway monitors the database server, and after monitoring the key-value pair addition event, the gateway stores the first key-value pair of the newly added new container in the local key-value pair list. When the gateway receives a service access request sent by the service client, it can match the key-value pair of the new container or the old container from the key-value pair list, thereby routing the service access request to the new container or the old container, so that the new container and the old container run in parallel to provide services. When the microservice is updated, the deployment of the new container can be completed without shutting down the microserver. For users, the microservice can be restarted seamlessly to ensure the continuity and availability of the service.

[0172] In one possible implementation, Figure 5 Schematic diagram of the process of microservice hot restart method provided in the embodiment of the present application Figure 4 ,like Figure 5 As shown, the method may include:

[0173] S301: If a key-value pair deletion event is monitored, obtain a second key-value pair of an old container of a target service from the key-value pair deletion event.

[0174] S302: Execute a predefined key-value pair deletion operation method to delete the second key-value pair from a locally stored list of preset system applications.

[0175] In this embodiment, after listening to the key-value pair deletion event, the gateway listening thread retrieves the second key-value pair contained in the key-value pair deletion event, and the gateway executes a predefined key-value pair deletion operation method to delete the second key-value pair from the key-value pair list of the preset system application stored locally.

[0176] When the gateway receives a service access request sent by the user through the service client, it matches the service information from multiple key-value pairs in the key-value pair list according to the service information carried in the service access request, and determines the target container corresponding to the matching key-value pair. The target container is no longer the old container PodsOld corresponding to the second key-value pair.

[0177] In some embodiments, the service monitoring thread service.Watcher is used to monitor the service information key-value pairs prefixed with service contained in the key-value pair deletion event Delete received by etcd.server.

[0178] When etcd.server receives the Delete operation with the prefix service sent by the microserver, it will delete the second service information key value from the database server. The Delete operation is used to delete the key-value pair. etcd.server will notify the etcd.client that listens to the prefix service of the occurrence of the Delete event. The service monitoring thread service.Watcher can listen to the Delete event through etcd.client and then take out the second service information key-value pair contained in the Delete event.

[0179] The gateway API Gateway pre-defines a service information key-value pair deletion operation method kv.service.delete. After the service monitoring thread service.Watcher monitors the Delete event through etcd.client, it takes out the second service information key-value pair contained in the Delete event, and uses the service information key-value pair deletion operation method kv.service.delete to delete the key-value pair list of the preset system application stored locally, and deletes the second service information key-value pair from the key-value pair list.

[0180] After the second service information key-value pair is deleted, the information of the old container is removed from the gateway. When there are still remaining containers of the microservice, the service client can still request the microservice. When all containers of the microservice are removed, the service client will no longer request the microservice, thereby ensuring the consistency of the microservice status.

[0181] In other embodiments, the routing monitoring thread route.Watcher is used to monitor the routing information key-value pairs prefixed with route contained in the key-value pair deletion event Delete received by etcd.server.

[0182] When etcd.server receives the Delete operation with the prefix route sent by the microserver, it will delete the second routing information key value from the database server. The Delete operation is used to delete the key-value pair. etcd.server will notify the etcd.client that listens to the prefix route of the occurrence of the Delete event. The route listening thread route.Watcher can listen to the Delete event through etcd.client and then take out the second routing information key-value pair contained in the Delete event.

[0183] The gateway API Gateway pre-defines a route information key-value pair deletion operation method kv.service.route. After the route monitoring thread route.Watcher listens to the Delete event through etcd.client, it takes out the second route information key-value pair contained in the Delete event, and uses the route information key-value pair deletion operation method kv.service.route to delete the key-value pair list of the preset system application stored locally, and deletes the second route information key-value pair from the key-value pair list.

[0184] After the second routing information key-value pair is deleted, the routing information of the old container is removed from the gateway, and the service access request of the service client no longer accesses the route through the old container. If there are still other containers on the microservice that can access the route, the service client still accesses the route. When all containers corresponding to the route are removed, the service client no longer requests the route, thereby ensuring the consistency of the microservice routing status.

[0185] It should be noted that each container has a service information key-value pair and a routing information key-value pair. Each container provides corresponding services by accessing the corresponding routes. If the service information key-value pair is deleted, the corresponding container cannot be requested to provide the corresponding service. If the routing information key-value pair is deleted, the corresponding container cannot be requested to access the corresponding route.

[0186] In the microservice hot restart method provided in the above embodiment, after the old container stops running, the key-value pair of the old container is deleted from the database server, and the gateway synchronously deletes the key-value pair of the old container stored in the key-value pair list, so that the gateway can no longer route the service access request of the service client to the old container, but routes the service access request to the new container, thereby realizing the hot restart of the microservice and ensuring the stability of the microservice. The microservice hot restart process determines that the service is not interrupted, so as to achieve a hot restart without user perception.

[0187] In a possible implementation, the service access request includes: a request method and a request path; Figure 6Schematic diagram of the process of microservice hot restart method provided in the embodiment of the present application Figure 5 ,like Figure 6 As shown, the process of determining the target container for the received service access request according to the key-value pair list of the preset system application in S204 may include:

[0188] S401: According to the request method and the request path, multiple matching modes are used in turn to perform routing matching on multiple routing information key-value pairs in the key-value pair list to determine at least one matching routing information key-value pair.

[0189] In this embodiment, the service client sends a service access request to the gateway, which is an HTTP request. The gateway parses the HTTP request and determines the request method method and request path path in the HTTP request, where the request method method includes: GET, POST, PUT, DELETE, etc.

[0190] By assembling the request method method and the request path path, the request route route (method+path) is obtained. The gateway uses the preset route matching method route.match through route.client to perform route matching, and matches at least one matching route information key-value pair route.kvs from multiple route information key-value pairs in the key-value pair list.

[0191] In some embodiments, multiple matching methods with matching priorities are provided, and different matching methods are used in turn according to the matching priorities for route matching until the corresponding matching route information key-value pair route.kvs is matched, and the subsequent matching methods will no longer be executed. If the matching route information key-value pair route.kvs is still not matched after all matching methods are executed, the gateway returns a response exception to the service client.

[0192] Among them, multiple matching methods with matching priorities are: complete route matching, parameter route matching, and route prefix matching.

[0193] Specifically, the complete route matching is to perform a complete match on the route information (route) in the route information key-value pair according to the method+path. Only when the request method method and the request path path in the route information (route) are consistent with the request method method and the request path path in the HTTP request, the corresponding route information key-value pair is determined to be a matching route information key-value pair.

[0194] Parameter route matching is to determine the length of the parameter information carried in the request path by segmenting the request path under the premise of matching the request method, and compare the length of the parameter information with the parameter length specified in the route information (route). If the two are consistent, the corresponding route information key-value pair is determined to be a matching route information key-value pair. For example, when the service access request is a login request, the account information will be carried in the account password login, and the account length can be compared with the parameter length specified in the route information (route). If the two are consistent, the route is determined to be used for account login.

[0195] Route prefix matching is to match only the request method method when the parameter route does not match. For example, the request method method of the login request is login.

[0196] S402: Determine at least one corresponding matching service information key-value pair according to at least one matching routing information key-value pair.

[0197] In this embodiment, the service name (service_name) and the lease identifier (lease_id) in the matching routing information key-value pair route.kvs constitute the service key serviceKey of the service information key-value pair. The gateway determines the matching service information key-value pair service.kvs corresponding to the matching routing information key-value pair based on the service name (service_name) and the lease identifier (lease_id) in at least one matching routing information key-value pair route.kvs.

[0198] S403: Determine at least one matching container from multiple containers according to at least one matching service information key-value pair.

[0199] In this embodiment, at least one matching container is determined from multiple containers according to the address information (Address) of the container in at least one matching service information key-value pair service.kvs.

[0200] S404: Determine a target container from at least one matching container according to a preset request allocation strategy.

[0201] In this embodiment, after the gateway obtains at least one matching container through matching, a preset request allocation strategy is adopted according to version information, current limiting control information, etc. of the matching container to determine a matching container that satisfies the request allocation strategy from the at least one matching container as the target container.

[0202] In some embodiments, the request allocation strategy may be a load balancing strategy, and the load of at least one matching container may be calculated to determine the matching container with the smallest load as the target container.

[0203] For example, the load balancing strategy may be: a polling strategy, a weighted polling strategy, a minimum connection strategy, a fault detection and automatic elimination strategy, etc., which is not limited in this embodiment.

[0204] In other embodiments, the request allocation strategy may be a version control strategy, which may allocate the target service request to a container of a specified version based on the version information of at least one matching container, may maintain the coexistence of multiple versions of containers, and may smoothly switch the versions of containers by testing the stability of the version containers.

[0205] The microservice hot restart method provided in the above embodiment performs route matching and service matching according to the service access request, and then determines the target container in combination with the request allocation strategy, so as to ensure that the microservice can provide corresponding business functions to the user through the target container, thereby ensuring the continuity and availability of the service.

[0206] For example, Figure 7 A schematic diagram of the process of gateway discovery service routing and micro-server registration service routing provided in the embodiment of the present application, such as Figure 7 As shown, the process may include:

[0207] The gateway API Gateway establishes the discovery service process Service.client and the discovery route process Route.client through the database client. The discovery service process Service.client initializes the service information key-value pair through the initialization function GetPrefix(service) when the gateway API Gateway starts, and then traverses the key-value pair list Kvs in the database server and stores the service information key-value pair kv.services locally. On the other hand, the gateway APIGateway monitors the key-value pair event ETCD.Event through the service monitoring thread service.Watcher. When monitoring the new event Event.Put of the service key-value pair, it stores the new service information key-value pair. When monitoring the deletion event Event.Delete of the service key-value pair, it deletes the corresponding service information key-value pair.

[0208] It is found that the routing process Route.client initializes the routing information key-value pairs through the initialization function GetPrefix(route) when the gateway API Gateway starts, and then traverses the key-value pair list Kvs in the database server and stores the routing information key-value pairs kv.routes locally. On the other hand, the gateway API Gateway listens to the key-value pair event ETCD.Event through the routing monitoring thread route.Watcher. When listening to the new event Event.Put of the routing key-value pair, it stores the new routing information key-value pair. When listening to the deletion event Event.Delete of the routing key-value pair, it deletes the corresponding routing information key-value pair.

[0209] In addition, the microserver applies for a lease from the database server's lease service ETCD lease, and stores the registered service information key-value pairs in the database server by registering the service prefix.service, triggering a new event Event.Put for the service key-value pairs, and stores the registered route information key-value pairs in the database server by registering the route prefix.route, triggering a new event Event.Put for the route key-value pairs.

[0210] The microserver uses the heartbeat detection ListenLease to apply to the database server to extend the lease validity period at intervals of 1 / 3TTL. When the microserver wants to end the container service, it can request to revoke the lease. After the lease expires, the database server will automatically delete the relevant key-value pairs and trigger the deletion event Event.Delete of the service key-value pair and the deletion event Event.Delete of the routing key-value pair.

[0211] Figure 8 A flow chart of the service route matching provided in the embodiment of the present application is as follows: Figure 8 The process shown may include:

[0212] The service client sends a service access request to the gateway. The gateway performs route matching by discovering the routing process route.client. The matching process includes: complete route matching, parameter route matching, and route prefix matching. After any matching method matches multiple routing information key-value pairs, the matching service information key-value pairs are determined by discovering the service process service.client, and then the address of the target container is determined according to the load balancing strategy and version control strategy.

[0213] The gateway acts as a reverse proxy for the microservice container. After selecting the address of the target container according to the strategy, the gateway establishes a connection with the target container and forwards the received service access request to the target container. After receiving the service access request, the target container executes the corresponding business logic and returns the response result to the gateway. The gateway receives the response data from the target container, performs log processing, performance statistics and other processing on the response, and returns the response data to the service client after processing. After the service access request is processed, the gateway closes the connection with the target container after a certain period of idle time according to the connection strategy to release resources.

[0214] Fig. 9 A schematic diagram of the hot restart process of a microservice provided in an embodiment of the present application is shown in FIG. Fig. 9 As shown, the process may include:

[0215] Start the gateway. After the gateway is started, it will discover all running microservice containers through the database server and store the service and routing information key-value pairs. Start the old container PodsOld of the microservice. After the microservice is started, it will register its corresponding service and routing information key-value pairs through the database server. The gateway will store them after discovering them through the database server.

[0216] The service client requests a matching routing service through the gateway discovery, obtains the old container PodsOld of one or more microservices, and routes to the specified target old container PodsOld through load balancing strategy or other strategies.

[0217] After the new container PodsNew of the microservice is started, its corresponding service and routing information key-value pairs are registered through the database server, and the gateway is discovered and stored through the database server.

[0218] After receiving the request from the service client again, the old container PodsOld and the new container PodsNew of one or more microservices can be obtained, and then they are distributed to the new and old microservice containers according to the load balancing strategy; a large number of requests can also be distributed to the new container PodsNew through the version control strategy, gradually reducing the access to the old container PodsOld.

[0219] Before the old container PodsOld stops running, the lease is revoked through the database server. After the gateway receives the Delete event through the database server, it clears the service and routing information key-value pairs related to the old container PodsOld. When the service client requests again, the gateway will no longer find and match the old container PodsOld, but will route all requests to the new container PodsNew.

[0220] As a result, the service client will not be aware of the replacement of the old microservice with the new one and can still make normal requests, thus achieving a smooth transition.

[0221] In addition, after the old container PodsOld detects that the lease has expired, it ensures that new requests no longer enter the old container and then stops the operation of the old container, thereby ensuring the stability and high availability of the service.

[0222] The service client requests again to discover a matching routing service through the gateway and obtains one or more new containers PodsNew. At this time, the old container PodsOld is no longer matched, and only the new container PodsNew can be matched, thereby completing the hot restart process. During the entire hot restart process, there is no need to stop the running business services, thereby ensuring the continuity and availability of the service.

[0223] Based on the above method embodiments, an embodiment of the present application provides a microservice hot restart device, which is applied to a microserver. The microserver is communicated with a gateway, and the gateway is used to receive service access requests from service clients. The microserver is deployed with: containers for multiple services of preset system applications. Fig.10 A schematic diagram of the structure of the microservice hot restart device provided in the embodiment of the present application Figure 1 ,like Fig.10 As shown, the device may include:

[0224] The lease module 501 is used to respond to a startup trigger event of a new container of a target service in a preset system application and obtain a first lease of the new container from a database server;

[0225] A registration module 502, configured to register a first key-value pair of the new container according to information of the target service, information of the first lease, and configuration information of the new container;

[0226] The sending module 503 is used to send the first key-value pair of the new container to the database server, so that the database server triggers a key-value pair addition event for the new container. After monitoring the key-value pair addition event, the gateway obtains the first key-value pair and updates it to the key-value pair list of the preset system application, and determines the target container for the received service access request according to the key-value pair list of the preset system application, so as to execute the business function of the service access request through the target container.

[0227] Optionally, the registration module 502 is specifically used to register a first service information key-value pair of the new container according to the information of the target service, the information of the first lease, and the first service configuration information of the new container; and to register a first routing information key-value pair of the new container according to the routing information of the new container, the information of the first lease, and the second service configuration information of the new container, wherein the first key-value pair includes: a first service information key-value pair and a first routing information key-value pair.

[0228] Optionally, the registration module 502 is specifically used to determine the service key in the first service information key-value pair according to the information of the target service and the information of the first lease; determine the service value of the first service information key-value pair according to the first service configuration information of the new container, and the first service information key-value pair includes: a service key and a service value.

[0229] Optionally, the registration module 502 is specifically used to determine the routing key in the first routing information key-value pair according to the routing information of the new container and the information of the first lease; determine the routing value in the first routing information key-value pair according to the second service configuration information of the new container, and the first routing information key-value pair includes: a routing key and a routing value.

[0230] Optionally, the lease module 501 is further configured to obtain the renewed first lease from the database service if it is monitored that the remaining effective time of the first lease meets a preset renewal trigger condition.

[0231] Optionally, the lease module 501 is also used to respond to the stop-running trigger event of the old container of the target service, send a lease revocation request to the database server, so that the database server marks the second lease of the old container as revoked, and deletes the second key-value pair of the old container after the marked second lease expires. After monitoring the key-value pair deletion event, the gateway deletes the second key-value pair from the key-value pair list of the preset system application.

[0232] Based on the above method embodiment, the embodiment of the present application also provides a microservice hot restart device, which is applied to a gateway, the gateway is communicatively connected with a microserver, and the microserver is deployed with: containers of multiple services of preset system applications. Fig.11 A schematic diagram of the structure of the microservice hot restart device provided in the embodiment of the present application Figure 2 ,like Fig.11 As shown, the device may include:

[0233] A monitoring module 601 is used to monitor an online key-value pair list of a preset system application in a database server;

[0234] The acquisition module 602 is configured to acquire the first key-value pair of the new container of the target service from the key-value pair added event if a key-value pair added event is monitored;

[0235] The storage module 603 is used to update the first key-value pair to the key-value pair list of the preset system application stored locally;

[0236] A matching module 604 is configured to determine a target container for the received service access request according to a preset system application key-value pair list if a service access request sent by a service client is received;

[0237] The forwarding module 605 is used to send a service access request to a target container so that the target container executes a business function of the service access request.

[0238] Optionally, the first key-value pair includes: a first service information key-value pair and a first routing information key-value pair, and the monitoring module 601 is specifically used to create a service monitoring thread and a routing monitoring thread through a database client; and monitor the online key-value pair list through the service monitoring thread and the routing monitoring thread respectively;

[0239] The acquisition module 602 is specifically used to acquire the first service information key-value pair from the newly added event of the service information key-value pair if the service monitoring thread monitors the newly added event of the service information key-value pair; if the routing monitoring thread monitors the newly added event of the routing information key-value pair, acquire the first routing information key-value pair from the newly added event of the routing information key-value pair;

[0240] The storage module 603 is specifically used to execute a predefined service information key-value pair adding operation method to update the first service information key-value pair to the key-value pair list of the preset system application stored locally; execute a predefined routing information key-value pair adding operation method to update the first routing information key-value pair to the key-value pair list of the preset system application stored locally.

[0241] Optionally, the acquisition module 602 is further configured to acquire the second key-value pair of the old container of the target service from the key-value pair deletion event if a key-value pair deletion event is monitored;

[0242] The deleting module is used to execute a predefined key-value pair deletion operation method to delete the second key-value pair from the key-value pair list of the preset system application stored locally.

[0243] Optionally, the service access request includes: a request method and a request path; a matching module 604, which is specifically used to perform routing matching on multiple routing information key-value pairs in the key-value pair list in turn using multiple matching methods according to the request method and the request path, and determine at least one matching routing information key-value pair; determine at least one corresponding matching service information key-value pair according to the at least one matching routing information key-value pair; determine at least one matching container from multiple containers according to the at least one matching service information key-value pair; and determine a target container from the at least one matching container according to a preset request allocation strategy.

[0244] The above-mentioned device is used to execute the method provided by the aforementioned embodiment, and its implementation principle and technical effect are similar, which will not be repeated here.

[0245] The above modules may be one or more integrated circuits configured to implement the above methods, such as one or more application specific integrated circuits (ASICs), or one or more microprocessors, or one or more field programmable gate arrays (FPGAs). For another example, when a module is implemented in the form of a processing element scheduling program code, the processing element may be a general-purpose processor, such as a central processing unit (CPU) or other processor that can call program code. For another example, these modules may be integrated together and implemented in the form of a system-on-a-chip (SOC).

[0246] Fig.12 A schematic diagram of an electronic device provided in an embodiment of the present application, such as Fig.12 As shown, the electronic device 700 may include: a processor 701, a storage medium 702 and a bus, the storage medium 702 stores program instructions executable by the processor 701, when the electronic device 700 is running, the processor 701 and the storage medium 702 communicate through the bus, and the processor 701 executes the program instructions to execute the above method embodiment. The specific implementation method and technical effect are similar and will not be repeated here.

[0247] Optionally, the present invention further provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the above method embodiment is executed.

[0248] In the several embodiments provided by the present invention, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0249] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0250] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of hardware plus software functional units.

[0251] The above-mentioned integrated unit implemented in the form of a software functional unit can be stored in a computer-readable storage medium. The above-mentioned software functional unit is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor (English: processor) to perform some steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (English: Read-Only Memory, abbreviated: ROM), random access memory (English: Random Access Memory, abbreviated: RAM), disk or optical disk and other media that can store program codes.

[0252] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art who is familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed by the present invention, which should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention should be based on the protection scope of the claims.

Claims

1. A microservice hot restart method, characterized in that: Applied to a micro server, the micro server is connected to a gateway for communication, the gateway is used to receive a service access request from a service client, the micro server is deployed with: containers of multiple services of a preset system application, the method includes: In response to a start trigger event of a new container of a target service in the preset system application, obtaining a first lease of the new container from a database server; Registering a first key-value pair of the new container according to the information of the target service, the information of the first lease, and the configuration information of the new container; A first key-value pair of the new container is sent to the database server, so that the database server triggers a key-value pair addition event for the new container. After monitoring the key-value pair addition event, the gateway obtains the first key-value pair and updates it to the key-value pair list of the preset system application, and determines a target container for the received service access request according to the key-value pair list of the preset system application, so as to execute the business function of the service access request through the target container.

2. The method according to claim 1, characterized in that The registering the first key-value pair of the new container according to the information of the target service, the information of the first lease, and the configuration information of the new container includes: Registering a first service information key-value pair of the new container according to the information of the target service, the information of the first lease, and the first service configuration information of the new container; According to the routing information of the new container, the information of the first lease and the second service configuration information of the new container, a first routing information key-value pair of the new container is registered, where the first key-value pair includes: the first service information key-value pair and the first routing information key-value pair.

3. The method according to claim 2, characterized in that The registering the first service information key-value pair of the new container according to the information of the target service, the information of the first lease, and the first service configuration information of the new container includes: Determine a service key in the first service information key-value pair according to the information of the target service and the information of the first lease; The service value of the first service information key-value pair is determined according to the first service configuration information of the new container, where the first service information key-value pair includes: the service key and the service value.

4. The method according to claim 2, characterized in that: The registering the first routing information key-value pair of the new container according to the routing information of the new container, the information of the first lease, and the second service configuration information of the new container includes: Determine a routing key in the first routing information key-value pair according to the routing information of the new container and the information of the first lease; According to the second service configuration information of the new container, a routing value in the first routing information key-value pair is determined, where the first routing information key-value pair includes: the routing key and the routing value.

5. The method according to claim 1, characterized in that: The method further comprises: If it is monitored that the remaining effective time of the first lease meets a preset renewal trigger condition, the renewed first lease is obtained from the database service.

6. The method according to claim 1, characterized in that The method further comprises: In response to a trigger event that the old container of the target service stops running, a lease revocation request is sent to the database server, so that the database server marks the second lease of the old container as revoked, and deletes the second key-value pair of the old container after the marked second lease expires. After monitoring the key-value pair deletion event, the gateway deletes the second key-value pair from the key-value pair list of the preset system application.

7. A microservice hot restart method, characterized in that: Applied to a gateway, the gateway is in communication connection with a micro server, the micro server is deployed with: containers of multiple services of a preset system application, the method includes: Monitor the online key-value pair list of the preset system application in the database server; If a key-value pair addition event is monitored, a first key-value pair of a new container of the target service is obtained from the key-value pair addition event, where the first key-value pair is a key-value pair registered for the new container by the microserver according to information of the target service, information of the first lease, and configuration information of the new container, and the first lease is a lease obtained from a database server for the new container in response to a startup trigger event of a new container of the target service in the preset system application; Updating the first key-value pair to the locally stored key-value pair list of the preset system application; If a service access request sent by a service client is received, determining a target container for the received service access request according to the key-value pair list of the preset system application; The service access request is sent to the target container, so that the target container executes the business function of the service access request.

8. The method according to claim 7, characterized in that The first key-value pair includes: a first service information key-value pair and a first routing information key-value pair, and the monitoring of the online key-value pair list of the preset system application in the database server includes: Create service listening threads and routing listening threads through the database client; The online key-value pair list is monitored respectively by the service monitoring thread and the routing monitoring thread; If a key-value pair newly added event is monitored, obtaining a first key-value pair of a new container of the target service from the key-value pair newly added event includes: If the service monitoring thread monitors a new event of a service information key-value pair, obtaining the first service information key-value pair from the new event of the service information key-value pair; If the routing monitoring thread monitors a new event of the routing information key-value pair, the first routing information key-value pair is obtained from the new event of the routing information key-value pair; The updating of the first key-value pair to the locally stored key-value pair list of the preset system application includes: Execute a predefined service information key-value pair adding operation method to update the first service information key-value pair to the key-value pair list of the preset system application stored locally; A predefined routing information key-value pair adding operation method is executed to update the first routing information key-value pair to the locally stored key-value pair list of the preset system application.

9. The method according to claim 7, characterized in that: The method further comprises: If a key-value pair deletion event is monitored, obtain the second key-value pair of the old container of the target service from the key-value pair deletion event; A predefined key-value pair deletion operation method is executed to delete the second key-value pair from the locally stored key-value pair list of the preset system application.

10. The method according to claim 7, characterized in that The service access request includes: a request method and a request path; and determining a target container for the received service access request according to the key-value pair list of the preset system application includes: According to the request method and the request path, sequentially use multiple matching modes to perform routing matching on multiple routing information key-value pairs in the key-value pair list to determine at least one matching routing information key-value pair; Determine, according to the at least one matching route information key-value pair, at least one corresponding matching service information key-value pair; Determine at least one matching container from a plurality of containers according to the at least one matching service information key-value pair; According to a preset request allocation strategy, a target container is determined from the at least one matching container.

Images