Elegant Release Method Based on Microservice Architecture, and Its Device, Equipment and Medium

Through the elegant release method, the interface unavailability and business interruption caused by forced release in the microservice architecture is solved, and the availability of the service release process and the continuity of business processing are achieved.

CN114371943BActive Publication Date: 2025-07-18SHANGHAI NAT GRP HEALTH TECH CO LTD
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
CN202111623832.5
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2021-12-28
Publication Date
2025-07-18
Estimated Expiration
2041-12-28

AI Technical Summary

Technical Problem

In the microservice architecture based on springcloud, traditional forced releases lead to unavailability of service interfaces and unprocessed interruptions in business, poor user experience and low availability.

Method used

Adopt the elegant publishing method, query the service process number through scripts and detect whether there is a service process. If it exists, set the service instance status to pause first, and then close the service process after the cycle detection status is changed to pause, and release the latest service.

Benefits of technology

It ensures the availability of interfaces during the release process, avoids program interruptions caused by forced closure, and ensures the normal completion of business processing.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN114371943B_ABST
    Figure CN114371943B_ABST
Patent Text Reader

Abstract

The present application provides an elegant release method based on a microservice architecture, as well as a device, equipment, and medium thereof. The method releases a new service by calling an elegant release script; queries the current service process number according to the script and detects whether there is a service process currently; if not, directly releases the latest service; if so, jumps to the next step; queries the IP of the current server through the script, calls the eureka service status change interface according to the service instance corresponding to the IP, and sets the status of the service instance to paused; calls the eureka service list interface to circularly detect whether the status of the service instance changes to paused. After the change to paused, closes the service process and releases the latest service. The present application ensures that the interface is still available during the packet sending process, avoiding the problem of the interface being unavailable during the packet sending process; for the existing service process, it enters the normal shutdown process, and the finalization operation can be completed during shutdown, avoiding the forced interruption of the program caused by forced shutdown.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the technical field of microservice release. In particular, it relates to an elegant release method, device, equipment, and medium based on a microservice architecture. Background Art

[0002] As Figure 1 shown, during the release process of the web background service based on the springcloud microservice architecture, eureka is usually used as the registration center and zuul as the gateway. User requests will first enter the gateway, where the ribbon component in the gateway caches the service list registered in eureka and selects and distributes it in the service list to the corresponding services. The logic of service calls between services is also similar to the distribution logic of the zuul gateway. When there is a new version of a service or a service bug is fixed, the original service needs to be redeployed. The existing approach is to use forced release to release the service, but it always leads to problems such as unavailable service interfaces and interrupted business processes that are not completed. During the release process, after forcibly closing the existing service or the current service first and then releasing the new service, it often results in the unavailability of interfaces and services and the forced interruption of business processing during the release process.

[0003] Application Content

[0004] In view of the above-mentioned disadvantages of the prior art, the purpose of this application is to provide an elegant release method, device, equipment, and medium based on a microservice architecture to solve the problems of poor user experience and low availability in the traditional forced release process of the prior art.

[0005] To achieve the above purpose and other related purposes, this application provides an elegant release method based on a microservice architecture. The method includes: calling an elegant release script to release a new service; querying the current service process ID according to the script and detecting whether there is a service process currently; if not, directly release the latest service; if so, jump to the next step; querying the IP of the current server through the script, calling the eureka service status change interface according to the service instance corresponding to the IP, and setting the status of the service instance to paused; calling the eureka service list interface to loop and detect whether the status of the service instance changes to paused. After the change to paused, close the service process and release the latest service.

[0006] In an embodiment of this application, the parameters of the script include: service name, jar package name, and the port occupied by the java service.

[0007] In an embodiment of this application, the service instance is required to register the instance ID to eureka as $ip + : + $port.

[0008] In one embodiment of the present application, the step of calling the Eureka service list interface to cyclically detect whether the status of the service instance has changed to suspended includes: calling the Eureka service list interface to cyclically detect whether the status of the service instance has changed to suspended; if it has not changed to suspended within the first preset time, interrupt the release; if it has changed to suspended, wait for the second preset time and then close the service process.

[0009] In one embodiment of the present application, the step of closing the service process includes: using kill - 15 pid to close the service process; cyclically checking whether the service process has exited normally; if it has not been closed within the third preset time, use kill - 9 pid to forcibly close the service process.

[0010] In one embodiment of the present application, the method further includes: after the latest service is released, calling the Eureka service list interface to cyclically detect whether the service instance has been registered in the service list; if it has been registered in the service list, calling the Eureka service status change interface to set the status of the service instance to started; if it has not been detected as registered in the service list within the fourth preset time, interrupt the release; calling the Eureka service list interface to detect whether the status of the service instance has changed to started; if it has not changed to started, determine whether the fifth preset time has been reached; if it has not been reached, jump to the step of calling the Eureka service status change interface to set the status of the service instance to started; if it has been reached, interrupt the release; if it has changed to started, determine that the latest service release is successful for releasing the next one or more servers.

[0011] To achieve the above - mentioned purpose and other related purposes, the present application provides an elegant release device based on a microservice architecture. The device includes: an acquisition module for calling an elegant release script to release a new service; a processing module for querying the current service process ID according to the script and detecting whether there is a service process currently; if not, directly release the latest service; if so, jump to the next step; query the IP of the current server through the script, call the Eureka service status change interface according to the service instance corresponding to the IP and set the status of the service instance to suspended; call the Eureka service list interface to cyclically detect whether the status of the service instance has changed to suspended, and after it has changed to suspended, close the service process and release the latest service.

[0012] To achieve the above - mentioned purpose and other related purposes, the present application provides a computer device. The device includes: a memory, a processor, and a communicator; the memory stores a data transmission program, the processor executes the data transmission program to implement the method as described above; the communicator is communicatively connected to an external device.

[0013] To achieve the above and other related objectives, the present application provides a computer-readable storage medium with a computer program stored thereon. When the data transmission program is executed by a processor, the above-described method is implemented.

[0014] As described above, an elegant release method, apparatus, device, and medium based on a microservices architecture in the present application call an elegant release script to release a new service; query the current service process ID according to the script and detect whether there is a service process currently; if not, directly release the latest service; if so, jump to the next step; query the IP of the current server through the script, call the eureka service status change interface according to the service instance corresponding to the IP, and set the status of the service instance to suspended; call the eureka service list interface to repeatedly detect whether the status of the service instance changes to suspended. After the change to suspended, close the service process and release the latest service.

[0015] It has the following beneficial effects:

[0016] The present application ensures that the interface remains available during the packet sending process, avoiding the problem of the interface being unavailable during the packet sending process; for the currently existing service process, it enters the normal shutdown process, and the finalization operation can be completed during shutdown, avoiding the forced interruption of the program caused by forced shutdown. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 It shows a schematic diagram of a scenario of a microservices architecture based on springcloud in an embodiment of the present application.

[0018] Figure 2 It shows a schematic diagram of a scenario of traditional forced release of a microservices architecture based on springcloud in an embodiment of the present application.

[0019] Figure 3 It shows a schematic diagram of the process of an elegant release method based on a microservices architecture in an embodiment of the present application.

[0020] Figure 4 It shows a schematic diagram of the modules of an elegant release apparatus based on a microservices architecture in an embodiment of the present application.

[0021] Figure 5 It shows a schematic diagram of the structure of a computer device in an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0022] The following describes the implementation manners of the present application through specific specific examples. Those skilled in the art can easily understand other advantages and effects of the present application from the content disclosed in this specification. The present application can also be implemented or applied through other different specific implementation manners. Various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present application. It should be noted that, without conflict, the following embodiments and the features in the embodiments can be combined with each other.

[0023] It should be noted that the diagrams provided in the following embodiments only illustrate the basic concept of the present application in a schematic manner. Therefore, only the components related to the present application are shown in the diagrams, rather than being drawn according to the number, shape, and size of the components in actual implementation. The types, quantities, and proportions of the components in actual implementation can be arbitrarily changed, and the component layout type may also be more complex.

[0024] Eureka is a service discovery framework developed by Netflix. It is itself a REST-based service, mainly used to locate the middle-tier services running in the AWS domain for the purpose of load balancing and middle-tier service failover. Spring Cloud integrates it in its sub-project spring-cloud-netflix to implement the service discovery function of Spring Cloud.

[0025] Spring Cloud Ribbon is a client-side load balancing tool based on Http and TCP. It is implemented based on Netflix Ribbon. Client-side load balancing means that when the browser sends a request to the background, the client will read the list of available service information registered with the server from the Eureka Server, and select which server to send the request to according to the set load balancing strategy (using the default if not set).

[0026] Zuul is a microservice gateway in spring cloud. Gateway: It is the front-door entrance in an overall network system. The request first passes through the gateway for path routing to locate the specific service node. Zuul is a microservice gateway. First, it is a microservice. It will also register and discover services in the Eureka registration center. It is also a gateway, and requests should be routed through Zuul.

[0027] Such as Figure 1As shown, in a microservices architecture usually based on Spring Cloud, Eureka is used as the registration center and Zuul is used as the gateway. User requests will first enter the gateway, where the Ribbon component in the gateway caches the service list registered in Eureka and selects and distributes among the service list to the corresponding services. The logic of service calls between services is also similar to the distribution logic of the Zuul gateway. When a service has a new version or a service bug is fixed, the original service needs to be redeployed. In the past, traditional forced releases were used to release services. During the traditional release process, when it detects the existence of a service process, it will forcibly shut down the service process through kill - 9 to release the new service.

[0028] As Figure 2 shown, assume that Service A is being released. Since kill - 9 pid of Service A is not notified to Eureka during the release, Service A that has been killed will temporarily still exist in the Eureka service list. The current Service A is unavailable. Then, when a user request is distributed to this service, it will be unavailable, resulting in a failed user request. And when the service process is ended by kill - 9 pid, there may be ongoing business or functions being processed, and the forced termination will cause problems such as abnormal interruption and dirty data.

[0029] Therefore, the traditional forced release process seriously reduces the availability of services, and the experience for users during service release in the production environment is extremely poor and unacceptable. Thus, this application designs an elegant release method based on the microservices architecture.

[0030] As Figure 3 shown, it shows a schematic flowchart of the elegant release method based on the microservices architecture in an embodiment of this application. As shown in the figure, the method includes:

[0031] Step S1: Call the elegant release script to release the new service.

[0032] In an embodiment of this application, the parameters of the script include: service name (appID), jar package name, and the port ($port) occupied by the Java service.

[0033] Preferably, before releasing the new service, ensure that two or more services are running and registered in the service center, and release them one by one.

[0034] Step S2: Query the current service process ID according to the script and detect whether there is a current service process; if not, directly release the latest service; if so, jump to the next step.

[0035] For example, use the script (ps) to query the current service process ID through the jar package name.

[0036] Step S3: Query the IP (ip addr) of the current server through the script, call the eureka service status change interface according to the service instance corresponding to the IP, and set the status of the service instance to suspended.

[0037] For example, through the service name, service instance id = $ip:$port, where it is required that the instance id registered with eureka is $ip+:+$port, call the eureka service status change interface to set the service instance status to suspended (OUT_OF_SERVICE). Here, OUT_OF_SERVICE means setting a certain instance to suspended service, which is different from deleting the service (DOWN). If deleted manually, but if the client is still alive, the timing task will still register the instance. However, when changing to this status, the timing task cannot update this status.

[0038] It should be noted that this step is mainly to inform eureka that the current service instance needs to suspend providing services. However, due to the caching mechanism of ribbon, the service list cache between services will not be refreshed in time, and there may still be unprocessed requests within this service instance. Therefore, the operation of shutting down the service (kill - 15) cannot be performed immediately.

[0039] Step S4: Call the eureka service list interface to loop - detect whether the status of the service instance has changed to suspended. After the change to suspended, shut down the service process and publish the latest service.

[0040] Step S41: Call the eureka service list interface to loop - detect whether the status of the service instance has changed to suspended within the first preset time;

[0041] Step S42: If it has not changed to suspended, interrupt the publishing; if it has changed to suspended, wait for the second preset time and then shut down the service process.

[0042] Preferably, the first preset time is preferably 420 seconds. The above process is a check process to ensure that the interface for changing the service status to suspended is called successfully. Therefore, a maximum check time, that is, 420s, needs to be set here to avoid infinite loop.

[0043] Preferably, the second preset time is 70 seconds, which is used to ensure that the remaining web requests are processed.

[0044] It should be noted that the 70s here mainly takes into account the cache refresh time of the ribbon service list and the maximum processing time for the last request to arrive. Therefore, this time is greater than or equal to the cache refresh time of the ribbon service list (the ribbon.ServerListRefreshInterval is defaulted to 30 seconds) + the maximum processing time of the request (the default value of ribbon.ReadTimeout is 5 seconds, and the service of this application is set to 30 seconds). Generally, the time spent by ribbon to obtain the list from eureka also needs to be considered, so an additional 10 seconds is added, and thus it is finally set to 70 seconds.

[0045] In an embodiment of the present application, the closing of the service process includes:

[0046] Step S431: Use kill - 15 pid to close the service process.

[0047] It should be noted that using kill - 15 pid can make the program enter the normal shutdown process, ensure the normal operation of the shutdown hook in Java, and the program performs the finalization operation, avoiding the forced interruption of the program caused by forced shutdown.

[0048] Step S432: Loop to check whether the service process exits normally;

[0049] Step S433: If it is still not closed within the third preset time, use kill - 9 pid to forcibly close the service process.

[0050] It should be noted that since kill - 15 pid can be blocked and processed, requiring the program to exit normally by itself, there is a possibility of blockage in the program exit logic. Therefore, a check mechanism needs to be added, setting a maximum waiting time for the program to normally process the remaining tasks. Here, a timeout of 120 seconds is set. If this time is exceeded, then finally kill - 9 pid is used to ensure that the program is definitely closed.

[0051] The difference between kill - 9 and kill - 15 is that: kill - 9) SIGKILL is used to immediately end the running of the program. This signal cannot be blocked, processed, or ignored. If the administrator finds that a certain process cannot be terminated, this signal can be tried to be sent; 15) SIGTERM, the program end (terminate) signal. Different from SIGKILL, this signal can be blocked and processed. It is usually used to require the program to exit normally by itself. The shell command kill defaults to generating this signal. If the process cannot be terminated, then SIGKILL will be tried.

[0052] In an embodiment of the present application, the method further includes:

[0053] Step S51: After the latest service is released, call the eureka service list interface to loop and detect whether the service instance has been registered in the service list;

[0054] Step S52: If it has been registered in the service list, call the eureka service status change interface to set the status of the service instance to started; if it is not detected that it has been registered in the service list within the fourth preset time, the release is interrupted.

[0055] For example, the fourth preset time can be set to 200 seconds.

[0056] Step S53: Call the eureka service list interface to detect whether the status of the service instance has changed to started (UP);

[0057] Step S54: If it has not changed to started, determine whether the fifth preset time has been reached; if not, jump to Step S52 to call the eureka service status change interface to set the status of the service instance to started; if it has been reached, the release is interrupted.

[0058] Briefly speaking, after the service is started, it is also necessary to loop and call the eureka service list interface to determine whether the service instance has been registered in the service list. Only when it is truly registered in the eureka service list can it be proved that the service is truly started and can be obtained by the ribbon of each service. Since there is a situation where the registration fails due to an internal error in the service, it is also necessary to set a maximum timeout here. Preferably, it is set to 420 seconds here to avoid the problem of infinite loop detection.

[0059] Among them, the number of loops can be set within the maximum attempt time - the fifth preset time, that is, the number of times to jump to Step S52, to attempt to set the start status multiple times. For example, a detection frequency will be set, and this maximum attempt time / frequency = the number of times. For example, set it once every 2 seconds, 420 / 2 = at most 210 times.

[0060] Step S55: If it has changed to started, it is determined that the latest service release is successful, so as to release the next one or more servers.

[0061] It should be noted that here it is mainly considered that the status of the service instance was previously set to suspended (OUT_OF_SERVICE), and sometimes eureka will leave this status. To avoid this problem, it is possible to actively call a status change to UP once.

[0062] Briefly speaking, this step is used to ensure that the latest service release is successful and then release the latest services of other servers (released simultaneously).

[0063] Such as Figure 4As shown, it is a schematic diagram of the modules of the graceful release device based on the microservice architecture in an embodiment of the present application. As shown in the figure, the graceful release device 400 based on the microservice architecture includes:

[0064] An acquisition module 401, configured to call a graceful release script to release a new service;

[0065] A processing module 402, configured to query the current service process number according to the script and detect whether there is a service process currently; if not, directly release the latest service; if so, jump to the next step; query the IP of the current server through the script, call the eureka service status change interface according to the service instance corresponding to the IP and set the status of the service instance to suspended; call the eureka service list interface to loop-detect whether the status of the service instance changes to suspended, and when it changes to suspended, close the service process and release the latest service.

[0066] It can be understood that through the operation of each module of the graceful release device 400 based on the microservice architecture, it can achieve as Figure 3 the graceful release method based on the microservice architecture described above.

[0067] It should be noted that it should be understood that the division of each module of the above device is only a logical function division. In actual implementation, it can be fully or partially integrated into a physical entity, or physically separated. And these modules can all be implemented in the form of software called by a processing element; they can also all be implemented in the form of hardware; or some modules can be implemented in the form of software called by a processing element, and some modules can be implemented in the form of hardware. For example, the processing module 402 can be a separately established processing element, or can be integrated in a certain chip of the above device. In addition, it can also be stored in the memory of the above device in the form of program code, and called and executed by a certain processing element of the above device to perform the functions of the above processing module 402. The implementation of other modules is similar. In addition, these modules can be fully or partially integrated together, or independently implemented. The processing element here can be an integrated circuit with signal processing capabilities. In the implementation process, each step of the above method or each of the above modules can be completed through the integrated logic circuit in the processor element or the instructions in software form.

[0068] For example, the above-mentioned modules can 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 digital signal processors (DSPs), or, one or more Field Programmable Gate Arrays (FPGAs), etc. Again, when a certain module above is implemented in the form of a processing element scheduling program code, the processing element can be a general-purpose processor, such as a Central Processing Unit (CPU) or other processors that can call program code. Again, these modules can be integrated together and implemented in the form of a system-on-a-chip (SOC).

[0069] As Figure 5 shown, the structural schematic diagram of a computer device in an embodiment of the present application is shown. As shown, the computer device 500 includes: a memory 501, a processor 502, and a communicator 503. The memory 501 stores a data transmission program, and the processor 502 executes the data transmission program to implement as Figure 3 the elegant release method based on the microservice architecture described above; the communicator 503 is communicatively connected to an external device. The external device can be a server or a client.

[0070] The memory 501 may include a Random Access Memory (RAM), and may also include non-volatile memory, such as at least one disk memory.

[0071] The processor 502 can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0072] The communicator 503 is used to implement communication connections between other devices (such as clients, controllers, read-write libraries, and read-only libraries). It may include one or more groups of modules with different communication methods. The communication connection can be one or more wired / wireless communication methods and their combinations. The communication methods include: the Internet, CAN, intranet, wide area network (WAN), local area network (LAN), wireless network, digital subscriber line (DSL) network, frame relay network, asynchronous transfer mode (ATM) network, virtual private network (VPN), and / or any one or more of any other suitable communication networks. For example: any one or more combinations of WIFI, Bluetooth, NFC, GPRS, GSM, and Ethernet.

[0073] In an embodiment of the present application, a computer-readable storage medium stores a data transmission program, and when the data transmission program is executed by a processor, it implements as Figure 3 the elegant release method based on the microservice architecture as described above.

[0074] For the computer-readable storage medium, those of ordinary skill in the art can understand that all or part of the steps of implementing the above method embodiments can be completed by hardware related to computer programs. The foregoing image processing program can be stored in a computer-readable storage medium. When this program is executed, it executes the steps including the above method embodiments; and the foregoing storage medium includes: ROM, RAM, magnetic disk, or optical disc and other media that can store program codes.

[0075] These computer programs can also be loaded onto a computer or other programmable data processing devices, so that a series of operation steps are executed on the computer or other programmable devices to generate computer-implemented processing, and thus the instructions executed on the computer or other programmable devices provide for implementing the steps for the functions specified in Figure 1 one process or multiple processes and / or Figure 1 one block or multiple blocks.

[0076] A computer-readable medium includes both permanent and non-permanent, removable and non-removable media and can implement information storage by any method or technology. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices, or any other non-transitory medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer-readable medium does not include transitory computer-readable media, such as modulated data signals and carrier waves.

[0077] In summary, the present application provides an elegant release method, apparatus, device, and medium based on a microservices architecture, effectively overcoming various drawbacks in the prior art and having high industrial utilization value.

[0078] The above embodiments are merely illustrative of the principles and effects of the present application and are not intended to limit the present application. Any person familiar with this technology can modify or change the above embodiments without departing from the spirit and scope of the present application. Therefore, all equivalent modifications or changes made by those with ordinary knowledge in the relevant technical field without departing from the spirit and technical ideas disclosed in the present application should still be covered by the claims of the present application.

Claims

1. An elegant release method based on a microservices architecture, characterized in that, The method includes: Invoking an elegant release script to release a new service; Querying the current service process ID according to the script and detecting whether there is a service process currently; if not, directly release the latest service; if so, jump to the next step; Querying the IP of the current server through the script, invoking the eureka service status change interface according to the service instance corresponding to the IP, and setting the status of the service instance to suspended; Invoking the eureka service list interface to circularly detect whether the status of the service instance changes to suspended. After it changes to suspended, close the service process and release the latest service; The invoking the eureka service list interface to circularly detect whether the status of the service instance changes to suspended includes: invoking the eureka service list interface to circularly detect whether the status of the service instance changes to suspended; if it does not change to suspended within the first preset time, interrupt the release; if it changes to suspended, wait for the second preset time and then close the service process; After the latest service is released, invoking the eureka service list interface to circularly detect whether the service instance has been registered in the service list; if it has been registered in the service list, invoking the eureka service status change interface to set the status of the service instance to started; if it is not detected that it has been registered in the service list within the fourth preset time, interrupt the release; invoking the eureka service list interface to detect whether the status of the service instance changes to started; if it does not change to started, determine whether the fifth preset time is reached; if not, jump to the step of invoking the eureka service status change interface to set the status of the service instance to started; if so, interrupt the release; if it changes to started, determine that the latest service is successfully released for releasing the next server or multiple servers.

2. The elegant release method based on the microservice architecture according to claim 1, wherein The parameters of the script include: service name, jar package name, and port occupied by the Java service.

3. The elegant release method based on the microservice architecture according to claim 1, characterized in that, The service instance is required to register in eureka with the instance ID of $ip + : + $port.

4. The graceful release method based on the microservice architecture according to claim 1, characterized in that, The closing of the service process includes: Using kill - 15 pid to close the service process; Circularly checking whether the service process exits normally; If it is still not closed within the third preset time, use kill - 9 pid to forcibly close the service process.

5. An elegant release device based on a microservices architecture, characterized in that, The device includes: An acquisition module for invoking an elegant release script to release a new service; A processing module is used to query the current service process number according to the script and detect whether there is a service process currently; if not, directly publish the latest service; if so, jump to the next step; query the IP of the current server through the script, call the eureka service status change interface according to the service instance corresponding to the IP and set the status of the service instance to suspended; call the eureka service list interface to repeatedly detect whether the status of the service instance changes to suspended. When it changes to suspended, close the service process and publish the latest service; the step of calling the eureka service list interface to repeatedly detect whether the status of the service instance changes to suspended includes: calling the eureka service list interface to repeatedly detect whether the status of the service instance changes to suspended; if it does not change to suspended within the first preset time, interrupt the publishing; if it changes to suspended, wait for the second preset time and then close the service process; after the latest service is published, call the eureka service list interface to repeatedly detect whether the service instance has been registered in the service list; if it has been registered in the service list, call the eureka service status change interface to set the status of the service instance to started; if it is not detected that it has been registered in the service list within the fourth preset time, interrupt the publishing; call the eureka service list interface to detect whether the status of the service instance changes to started; if it does not change to started, determine whether the fifth preset time is reached; if not, jump to the step of calling the eureka service status change interface to set the status of the service instance to started; if so, interrupt the publishing; if it changes to started, determine that the latest service is successfully published for publishing the next one or more servers.

6. A computer device, characterized in that, The device includes: a memory, a processor, and a communicator; The memory stores a data transmission program, and the processor executes the data transmission program to implement the method according to any one of claims 1-4; the communicator is communicatively connected to an external device.

7. A computer-readable storage medium, characterized in that, A computer program is stored thereon, and when the computer program is executed by the processor, the method according to any one of claims 1-4 is implemented.

Citation Information

Patent Citations

  • Offline method based on Eureka-Server project

    CN110297706A

  • Micro-service instance exit method and device, equipment and storage medium

    CN112799786A

  • Service unit offline method based on micro-service unit architecture and related device

    CN112948098A