Service calling method, device, data center, storage medium and product

Abstract

This application provides a service invocation method, apparatus, data center, storage medium, and product, including: receiving a deployment request sent by a microservice deployment system, wherein the deployment request is generated by the microservice deployment system based on service requirement information in a pre-deployed service, and the deployment request includes a preset image address; obtaining a target image based on the preset image address; starting a microservice container based on the target image to register the pre-deployed service with a local registry center, so that the local registry center adds the pre-deployed service to the full microservice registration information table; when the pre-deployed service needs to initiate a cross-data center request, obtaining the full microservice registration information table from the local registry center; selecting a target instance in the full microservice registration information table according to a preset routing strategy, and sending a request to the target data center based on the target instance to realize cross-data center service invocation. This method reduces the complexity of cross-data center service deployment.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a service invocation method, apparatus, data center, storage medium and product. Background Technology

[0002] Microservice architecture, as a flexible and scalable system design methodology, divides a single application system into multiple independent service units, enabling the system to better cope with complex business needs and rapidly changing market environments. With the widespread adoption of cloud computing and microservice architecture, modern enterprises increasingly face the challenge of efficiently deploying and managing application systems across multiple geographically distributed data centers.

[0003] In existing technologies, deployment in a multi-datacenter environment is achieved by deploying services separately in each datacenter. However, the process of deploying services separately in each datacenter is cumbersome and time-consuming, making it difficult to meet the needs of rapid iteration and updates. Summary of the Invention

[0004] This application provides service invocation methods, devices, data centers, storage media, and products to reduce the complexity of cross-data center service deployment.

[0005] In a first aspect, embodiments of this application provide a service invocation method applied to various data centers, comprising: receiving a deployment request sent by a microservice deployment system, wherein the deployment request is generated by the microservice deployment system based on service requirement information in a pre-deployed service, and the deployment request includes a preset image address; obtaining a target image based on the preset image address; starting a microservice container based on the target image to register the pre-deployed service with a local registry center, so that the local registry center adds the pre-deployed service to the full microservice registration information table; when the pre-deployed service needs to initiate a cross-data center request, obtaining the full microservice registration information table from the local registry center; selecting a target instance in the full microservice registration information table according to a preset routing strategy, and sending a request to the target data center based on the target instance, so as to realize cross-data center service invocation.

[0006] In one possible implementation, sending a request to a target data center based on a target instance includes: obtaining information about the target instance, wherein the information about the target instance includes the network address and port of the target data center; compressing the information about the target instance using a preset compression algorithm to obtain compressed data; appending the compressed data to a Hypertext Transfer Protocol request and adding a compression identifier to the request header to generate a request body; and sending the request body to the target data center based on the network address and port of the target data center.

[0007] In one possible implementation, starting a microservice container based on a target image to register a pre-deployed service with a local registry center includes: starting the microservice container using the target image and setting configuration parameters for the microservice container; after the microservice container starts, starting the service according to the configuration file of the pre-deployed service to enable the pre-deployed service to connect to the local registry center; and sending a registration request to the local registry center to enable the local registry center to process the registration request.

[0008] In one possible implementation, after starting the microservice container according to the target image to register the pre-deployed service to the local registry center, the method further includes: sending a heartbeat signal to the local registry center after a preset time, so that the local registry center updates the registration status of the pre-deployed service after receiving the heartbeat signal.

[0009] In one possible implementation, after starting the microservice container based on the target image to register the pre-deployed service with the local registry center, the method further includes: controlling the local registry center to send a check request to the health check endpoint of the pre-deployed service after a preset time to obtain the status information of the pre-deployed service; if the status information of the pre-deployed service indicates an unhealthy state, then sending a deregistration request to the local registry center to remove the pre-deployed service.

[0010] Secondly, embodiments of this application provide a service invocation apparatus applied in a data center, comprising:

[0011] The request receiving module is used to receive deployment requests sent by the microservice deployment system. The deployment request is generated by the microservice deployment system based on the service requirement information in the pre-deployed services, and the deployment request includes a preset image address.

[0012] The target image acquisition module is used to obtain the target image based on the preset image address.

[0013] The container startup module is used to start microservice containers based on the target image to register the pre-deployed services with the local registry center, so that the local registry center can add the pre-deployed services to the full microservice registration information table.

[0014] The full microservice registration information table module is used to retrieve the full microservice registration information table from the local registry center when a pre-deployed service needs to initiate a cross-datacenter request.

[0015] The processing module is used to select a target instance from the full microservice registration information table according to a preset routing strategy, and send a request to the target data center based on the target instance to realize cross-data center service calls.

[0016] Thirdly, embodiments of this application provide a data center, including: a memory and a processor;

[0017] The memory stores computer-executed instructions;

[0018] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0019] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0020] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0021] The service invocation method, apparatus, data center, storage medium, and product provided in this application embodiment reduce the complexity of cross-data center service deployment and accelerate the efficiency of iteration and updates by uniformly sending service deployment requests to each data center. In addition, determining the target instance in the full microservice registration information table according to the preset routing strategy to realize cross-data center service invocation can reduce the impact of single point of failure. Attached Figure Description

[0022] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0023] Figure 1 This is a schematic diagram illustrating an application scenario of the service invocation method provided in the embodiments of this application;

[0024] Figure 2 A flowchart illustrating the service invocation method provided in this application;

[0025] Figure 3 A schematic diagram of the structure of the service invocation device provided in the embodiments of this application;

[0026] Figure 4 A schematic diagram of the data center structure provided in this application.

[0027] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0028] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0029] First, let me explain the terms used in this application:

[0030] A data center is a facility specifically designed for the centralized storage, processing, and management of large amounts of data. It typically includes computer servers, storage devices, network equipment, and other related hardware and software infrastructure. The primary function of a data center is to provide reliable, efficient, and secure computing and storage resources to support a wide range of applications and services.

[0031] Image: A read-only template that contains everything needed to run an application, including code, runtime, libraries, and settings.

[0032] Containers are a virtualization technology used to package an application and all its dependencies into a single, portable unit. Containers provide a lightweight way to ensure that applications run consistently across different computing environments.

[0033] To clearly understand the technical solution of this application, the existing technical solutions are first described in detail. Microservice architecture is a design method that divides a single application system into multiple independent service units. Each service unit is independently developed, deployed, and run, and can be independently expanded and updated. Microservice architecture improves system flexibility and scalability through loose coupling and independent deployment between services, better addressing complex business needs and rapidly changing market environments. With the popularization of cloud computing technology, more and more enterprises are deploying their application systems in cloud environments. Cloud computing provides elastic computing resources and flexible deployment methods, allowing the advantages of microservice architecture to be fully realized. However, in practical applications, modern enterprises often need to deploy and manage microservice systems in data centers distributed across multiple geographical locations to improve system reliability and availability. This brings new challenges to multi-data center deployment methods. In existing technologies, deployment in a multi-data center environment is typically achieved by deploying services separately in each data center. While this approach can achieve multi-data center deployment, the lack of unified management and automation tools makes the deployment process cumbersome and time-consuming, failing to meet the needs of modern enterprises for rapid iteration and updates.

[0034] To address the aforementioned technical problems, the inventors conceived of designing a centralized microservice deployment system for unified management of microservice deployment, updates, and scaling across multiple data centers. The microservice deployment system generates deployment requests based on service requirement information in pre-deployed services and sends these requests to each target data center. Each data center receives the unified deployment request, pulls the target image from the repository according to the preset image address in the deployment request, and starts a microservice container based on the target image to register the pre-deployed service with its local registry center. Registries synchronize their service registration information tables to obtain full microservice registration information from multiple data centers. When a pre-deployed service needs to initiate a cross-datacenter request, it retrieves the full microservice registration information table from the local registry center, selects a target instance based on a preset routing strategy, and sends a request to the target data center based on that instance to achieve cross-datacenter service invocation. By uniformly sending service deployment requests to each data center, the complexity of cross-datacenter service deployment is reduced, and the efficiency of iteration and updates is accelerated. Furthermore, determining the target instance in the full microservice registration information table based on the preset routing strategy to achieve cross-datacenter service invocation reduces the impact of single points of failure.

[0035] Based on the above-mentioned inventive discovery, the inventor has proposed the technical solution of this application.

[0036] Figure 1 This is a schematic diagram illustrating an application scenario for the service invocation method provided in an embodiment of this application. For example... Figure 1 As shown, it includes: a microservice deployment system 101 and various data centers 102.

[0037] Specifically, the microservice deployment system 101 generates a deployment request based on the pre-deployment service requirement information and sends the deployment request to each data center 102. The deployment request includes a preset image address. Each data center 102 obtains the target image based on the preset image address and starts a microservice container based on the target image to register the pre-deployment service with the local registry center. This allows the local registry center to add the pre-deployment service to the full microservice registration information table. When the pre-deployment service needs to initiate a cross-data center request, it obtains the full microservice registration information table from the local registry center. In the full microservice registration information table, it selects a target instance according to a preset routing strategy and sends a request to the target data center based on the target instance, thereby realizing cross-data center service calls.

[0038] The following specific embodiments describe in detail the technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0039] Figure 2 A flowchart illustrating the service invocation method provided in this application is shown below. Figure 2 As shown, the method includes:

[0040] S201: Receive a deployment request sent by the microservice deployment system. The deployment request is generated by the microservice deployment system based on the service requirement information in the pre-deployed services. The deployment request includes a preset image address.

[0041] The default image address points to the repository where microservice container images are stored.

[0042] Specifically, the microservice deployment system generates a deployment request based on the service requirement information in the pre-deployed services and sends the deployment request to each data center.

[0043] S202: Obtain the target image based on the preset image address.

[0044] Specifically, after receiving a deployment request, each data center pulls the corresponding microservice container image from a preset image address.

[0045] S203: Start the microservice container based on the target image to register the pre-deployed service with the local registry center, so that the local registry center adds the pre-deployed service to the full microservice registration information table.

[0046] Specifically, it includes Sa1 to Sa3:

[0047] Sa1: Start the microservice container using the target image and set configuration parameters for the microservice container.

[0048] Specifically, each data center configures the runtime environment of the pre-deployed service according to the configuration parameters in the deployment request, including environment variables, network configuration, and storage volume mounting.

[0049] Sa2: After the microservice container starts, the service is started according to the configuration file of the pre-deployed service to enable the pre-deployed service to connect to the local registry center.

[0050] Sa3: Sends a registration request to the local registry center so that the local registry center can process the registration request.

[0051] Specifically, after configuration, the pre-deployment service is started and registered with the local registry center. The local registry centers in each data center are synchronized through the global service registry center, ensuring that service instances in all data centers can discover and communicate with each other. Configuration files are dynamically updated to ensure that service instances in each data center can automatically synchronize with the latest configuration.

[0052] Specifically, after registering the pre-deployed service to the local registry center, it also includes Sb1:

[0053] Sb1: Sends a heartbeat signal to the local registry center after a preset time, so that the local registry center updates the registration status of the pre-deployed service upon receiving the heartbeat signal.

[0054] The heartbeat signal typically includes health status information for each microservice.

[0055] Specifically, the system reads a preset time interval from the configuration file or environment variables. When the preset time interval is reached, it triggers a heartbeat sender to generate a heartbeat signal, which is then sent to the local registry center via Hypertext Transfer Protocol or other communication protocols. Upon receiving the heartbeat signal, the local registry updates the last heartbeat time of the pre-deployed service to maintain its registration status.

[0056] S204: When a pre-deployed service needs to initiate a cross-datacenter request, retrieve the full microservice registration information table from the local registry center.

[0057] The full microservice registration information table includes microservice instance information for all data centers, including service name, instance address, and port number.

[0058] S205: In the full microservice registration information table, select the target instance according to the preset routing strategy, and send a request to the target data center according to the target instance to realize cross-data center service calls.

[0059] In a microservice architecture, the default routing strategy refers to the rules and methods that determine how to allocate requests to target instances.

[0060] The preset routing strategies can be: Round Robin, which distributes requests sequentially to each available target instance, ensuring each instance receives approximately the same number of requests; Random, which randomly distributes requests to available target instances; Least Connections, which distributes requests to the target instance with the fewest current connections; Fastest Response Time, which distributes requests to the target instance with the shortest response time; Weighted, which assigns a weight to each target instance and distributes requests accordingly, with weights set based on target instance performance, resource configuration, and other factors; Geographic Location, which selects the nearest target instance based on the request's geographic location; Session Persistence, which consistently distributes requests from the same user to the same target instance; Failover, which transfers requests to other available instances when a target instance becomes unavailable; and Multi-Level Routing, which combines multiple routing strategies to select the appropriate target instance based on different conditions.

[0061] Specifically, the pre-deployment service selects a target instance based on the full microservice registration information table and initiates a cross-datacenter request, including steps Sc1~Sc4:

[0062] Sc1: Obtain information about the target instance, including the network address and port of the target data center.

[0063] Specifically, the network address and port of the target data center are read from a pre-configured file, and the information of the target instance is obtained through a service discovery mechanism.

[0064] Sc2: Compresses the information of the target instance using a preset compression algorithm to obtain compressed data.

[0065] The preset compression algorithm can be a lossless compression algorithm or a lossy compression algorithm. The target instance's information, such as network address and port, is used as input to perform the compression operation and obtain the compressed data.

[0066] Sc3: Appends the compressed data to the Hypertext Transfer Protocol request and adds a compression flag to the request header to generate the request body.

[0067] Specifically, create a Hypertext Transfer Protocol Request object, attach the compressed data as the request body to the Hypertext Transfer Protocol Request, add an identifier to the Hypertext Transfer Protocol Request header indicating that the data in the request body is compressed, and specify the compression algorithm used.

[0068] Sc4: Send the request body to the target data center based on the target data center's network address and port.

[0069] Specifically, a target URL is constructed based on the network address and port of the target data center, and a Hypertext Transfer Protocol (HTTP) request is sent to the target data center using an HTTP client library.

[0070] In summary, by uniformly sending service deployment requests to each data center, the complexity of cross-data center service deployment is reduced, and the efficiency of iteration and updates is accelerated. In addition, determining the target instance in the full microservice registration information table according to the preset routing strategy to realize cross-data center service calls can reduce the impact of single point of failure.

[0071] In another embodiment of this application, after the microservice container is started according to the target image and the pre-deployed service has been registered with the local registry center, if the pre-deployed service is successfully deployed, it is necessary to continuously monitor the registration status of the pre-deployed service, specifically including S301~S302:

[0072] S301: Controls the local registry center to send a check request to the health check endpoint of the pre-deployed service after a preset time to obtain the status information of the pre-deployed service.

[0073] Specifically, each data center controls the local registry center to send check requests to the health check endpoint of the pre-deployed service according to the preset time interval in the configuration file in order to obtain the status information of the pre-deployed service. The health check endpoint usually returns a status code and possible status description information.

[0074] S302: If the status information of the pre-deployed service indicates an unhealthy state, send a deregistration request to the local registry center to remove the pre-deployed service.

[0075] Specifically, after receiving the health check response from the pre-deployed service, each data center parses the response content. If the response status code indicates that the service is in a healthy state, the local registry records this status and waits for the next check cycle. If the response status code indicates an unhealthy state, a deregistration request is sent to the local registry to remove the pre-deployed service's information. The local registry processes the deregistration request, updates its internal registry, and removes the pre-deployed service's information.

[0076] In summary, by effectively monitoring the health status of pre-deployed services and deregistering them when they are in an unhealthy state, the local registry center can ensure the stability and reliability of each data center.

[0077] Figure 3 This is a schematic diagram of the structure of the service invocation device provided in an embodiment of this application. Figure 3 As shown, the service invocation device includes: a request receiving module 301, a target image acquisition module 302, a container startup module 303, a full microservice registration information table module 304, and a processing module 305.

[0078] The request receiving module 301 is used to receive deployment requests sent by the microservice deployment system. The deployment request is generated by the microservice deployment system based on the service requirement information in the pre-deployed services, and the deployment request includes a preset image address.

[0079] The target image acquisition module 302 is used to acquire the target image according to the preset image address.

[0080] The container startup module 303 is used to start a microservice container based on the target image to register the pre-deployed service with the local registry center, so that the local registry center adds the pre-deployed service to the full microservice registration information table.

[0081] The full microservice registration information table module 304 is used to obtain the full microservice registration information table from the local registry center when a pre-deployed service needs to initiate a cross-datacenter request.

[0082] The processing module 305 is used to select a target instance from the full microservice registration information table according to a preset routing strategy, and send a request to the target data center according to the target instance to realize cross-data center service calls.

[0083] In one possible implementation, the processing module 305 is specifically used to obtain information about the target instance, including the network address and port of the target data center; compress the information about the target instance using a preset compression algorithm to obtain compressed data; append the compressed data to a Hypertext Transfer Protocol request and add a compression identifier to the request header to generate a request body; and send the request body to the target data center according to the network address and port of the target data center.

[0084] In one possible implementation, the full microservice registration information table module 304 is specifically used to start a microservice container using the target image and set configuration parameters for the microservice container; after the microservice container starts, it starts the service according to the configuration file of the pre-deployed service to enable the pre-deployed service to connect to the local registry center; and sends a registration request to the local registry center so that the local registry center can process the registration request.

[0085] In one possible implementation, the service invocation device further includes a registration status update module, which is used to send a heartbeat signal to the local registry center after a preset time, so that the local registry center updates the registration status of the pre-deployed service after receiving the heartbeat signal.

[0086] In one possible implementation, the service invocation device further includes a status check module, which controls the local registry center to send a check request to the health check endpoint of the pre-deployed service after a preset time to obtain the status information of the pre-deployed service; if the status information of the pre-deployed service indicates an unhealthy state, a deregistration request is sent to the local registry center to remove the pre-deployed service.

[0087] The service invocation device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0088] Figure 4 This is a schematic diagram of the data center structure provided in this application. Figure 4As shown, the data center provided in this embodiment includes at least one processor 401 and a memory 402. Optionally, the data center also includes a communication component 403. The processor 401, memory 402, and communication component 403 are connected via a bus 404.

[0089] In a specific implementation, at least one processor 401 executes computer execution instructions stored in memory 402, causing at least one processor 401 to perform the above-described method.

[0090] The specific implementation process of processor 401 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0091] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0092] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0093] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0094] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0095] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0096] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0097] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0098] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

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

[0100] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0101] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0102] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0103] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A service invocation method, characterized in that, Applied to various data centers, including: Receive a deployment request sent by a microservice deployment system, wherein the deployment request is generated by the microservice deployment system based on the service requirement information in the pre-deployed service, and the deployment request includes a preset image address; Obtain the target image according to the preset image address; Start a microservice container based on the target image to register the pre-deployed service with the local registry center, so that the local registry center adds the pre-deployed service to the full microservice registration information table; When the pre-deployed service needs to initiate a cross-datacenter request, it obtains the full microservice registration information table from the local registry center; In the full microservice registration information table, a target instance is selected according to a preset routing strategy, and a request is sent to the target data center according to the target instance to realize cross-data center service calls.

2. The method according to claim 1, characterized in that, Sending a request to the target data center based on the target instance includes: Obtain information about the target instance, wherein the information about the target instance includes the network address and port of the target data center; The information of the target instance is compressed using a preset compression algorithm to obtain compressed data; The compressed data is appended to the Hypertext Transfer Protocol request, and a compression identifier is added to the request header to generate the request body; The request body is sent to the target data center based on the network address and port of the target data center.

3. The method according to claim 1, characterized in that, The step of starting a microservice container based on the target image to register the pre-deployed service with the local registry center includes: Start the microservice container using the target image and set configuration parameters for the microservice container; After the microservice container starts, the service is started according to the configuration file startup script of the pre-deployed service, so that the pre-deployed service connects to the local registry center. A registration request is sent to the local registry center so that the local registry center can process the registration request.

4. The method according to claim 3, characterized in that, After starting the microservice container based on the target image to register the pre-deployed service with the local registry center, the method further includes: A heartbeat signal is sent to the local registry center after a preset time, so that the local registry center updates the registration status of the pre-deployed service upon receiving the heartbeat signal.

5. The method according to claim 1, characterized in that, After starting the microservice container based on the target image to register the pre-deployed service with the local registry center, the method further includes: The local registry center is controlled to send a check request to the health check endpoint of the pre-deployed service after a preset time to obtain the status information of the pre-deployed service. If the status information of the pre-deployed service indicates an unhealthy state, a deregistration request is sent to the local registry center to remove the pre-deployed service.

6. A service invocation device, characterized in that, Applied to various data centers, including: The request receiving module is used to receive deployment requests sent by the microservice deployment system, wherein the deployment request is generated by the microservice deployment system based on the service requirement information in the pre-deployed service, and the deployment request includes a preset image address; The target image acquisition module is used to acquire the target image according to the preset image address; The container startup module is used to start a microservice container based on the target image to register the pre-deployed service with the local registry center, so that the local registry center adds the pre-deployed service to the full microservice registration information table; The full microservice registration information table module is used to obtain the full microservice registration information table from the local registration center when the pre-deployed service needs to initiate a cross-datacenter request; The processing module is used to select a target instance according to a preset routing strategy in the full microservice registration information table, and send a request to the target data center according to the target instance to realize cross-data center service calls.

7. The apparatus according to claim 6, characterized in that, The processing module is specifically used to obtain information about the target instance, wherein the information about the target instance includes the network address and port of the target data center; compress the information about the target instance using a preset compression algorithm to obtain compressed data; append the compressed data to a Hypertext Transfer Protocol request and add a compression identifier to the request header to generate a request body; and send the request body to the target data center according to the network address and port of the target data center.

8. A data center, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-5.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-5.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-5.

Images