Microservice debugging method, device and medium
By obtaining and judging online services through the service registration center in the microservice architecture, online services are called first, which solves the problems of long debugging time and errors in the microservice system, realizes efficient service calling and reduces system coupling.
Patent Information
- Application Number
- CN202210622809.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-06-02
- Publication Date
- 2025-09-05
- Estimated Expiration
- 2042-06-02
AI Technical Summary
In existing microservice systems, the replacement or upgrade of a single service requires re-debugging the entire system, which is time-consuming and prone to debugging errors, affecting the accuracy and cost of system calls.
Adopting a microservice architecture, the system obtains the current service and its downstream services through the service registration center, determines whether the target service is online, and gives priority to calling online services, abandoning faulty services, reducing system coupling, improving call accuracy, and saving debugging time.
It reduces the impact of faults on the system, automatically restores services, improves call accuracy, saves debugging time and costs, avoids debugging errors, and reduces system coupling.
Smart Images

Figure CN114942888B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of microservice technology, and in particular to a microservice debugging method, device, and medium. Background Art
[0002] The increasing pace of industrialization is driving the use of intelligent robots across various industries, replacing repetitive tasks previously performed by humans and operating in conjunction with other intelligent technology devices. With the increasing number of diverse scenarios and the widespread adoption of robots, customization and differentiation are gradually increasing. To better adapt to different scenarios, the need for optional accessories and the need for repair and replacement parts are increasing.
[0003] When a functional module for a specific purpose is replaced or upgraded, the entire system needs to be re-debugged. This means that when replacing or upgrading the multiple services corresponding to the functional module, not only the multiple services need to be debugged, but also the services of the entire system to which the functional module belongs need to be debugged. Existing component solutions mostly use a fixed architecture. For example, in a robotic arm robot, when the camera functional module is upgraded or replaced, current debugging requires adapting and re-debugging the other functional modules of the entire robotic arm system. This not only takes up a lot of debugging time, but because the relevant debugging personnel are familiar with the debugging of the camera functional module but lack relevant experience in debugging the entire robotic arm system, errors may occur during the debugging process, making the entire system unworkable.
[0004] Therefore, how to reduce the system coupling degree, reduce the impact of a single service on the system, improve the accuracy of service calls, and save the time and cost of service debugging are urgently needed to be solved by those skilled in the art. Summary of the Invention
[0005] The purpose of the present invention is to provide a microservice calling method, device and medium to reduce system coupling, improve service calling accuracy and save time cost of service debugging.
[0006] To solve the above technical problems, the present invention provides a microservice calling method, comprising:
[0007] Get the current service and the downstream services called by the current service;
[0008] When the current service receives a call instruction or an execution instruction, it determines whether there is a target service in the downstream service, where the target service is the service preset for processing by the current service;
[0009] If the target service exists, the downstream service corresponding to the target service is selected as the target downstream service, and whether the target downstream service is online is determined;
[0010] If the target downstream service is online, the target downstream service is treated as the service to be called and called;
[0011] When the service to be called is completed, the downstream services other than the target service are treated as additional services to determine whether the additional services are online.
[0012] If the additional service is online, the additional service is treated as a pending service and called;
[0013] If the target service does not exist, the downstream task is used as an additional service, and the process returns to the step of determining whether the additional service is online.
[0014] Preferably, obtaining the current service and the downstream services called by the current service includes:
[0015] Start the current service;
[0016] Send the current service to the service registry to register its own service and discover other services for calling;
[0017] Other services that are called are considered downstream services.
[0018] Preferably, when the target downstream service is offline, the method further includes:
[0019] When the target downstream service is offline, the call to the target downstream service is abandoned and the call result is output.
[0020] Preferably, when the additional service is not online, the method further includes:
[0021] When the additional service is not online, the calling of the additional service is abandoned and the calling result is output.
[0022] Preferably, it also includes:
[0023] When the target downstream service is called as the service to be called, the call result is output;
[0024] When the additional service is called as a service to be called, the calling result is output.
[0025] Preferably, it also includes:
[0026] Get the upstream service of the current service;
[0027] Send the obtained call results to the upstream service.
[0028] Preferably, after sending the current service to the service registration center, the method further includes:
[0029] Send heartbeat packets to the service registration center at time intervals to view the service status information of the current service.
[0030] To solve the above technical problems, the present invention further provides a microservice calling device, comprising:
[0031] The acquisition module is used to obtain the current service and the downstream services called by the current service;
[0032] The first judgment module is used to determine whether there is a target service in the downstream service when the current service receives a call instruction or an execution instruction, where the target service is a service preset for the current service. If the target service exists, the second judgment module is triggered; if the target service does not exist, the return module is triggered;
[0033] The second judgment module is used to select the downstream service corresponding to the target service as the target downstream service, determine whether the target downstream service is online, and trigger the first calling module if the target downstream service is online;
[0034] The first calling module is used to call the target downstream service as the service to be called;
[0035] The third judgment module is used to, when the call of the to-be-called service is completed, use the downstream service other than the target service as an additional service, determine whether the additional service is online, and trigger the second calling module if the additional service is online;
[0036] The second calling module is used to call the additional service as a service to be called;
[0037] The return module is used to treat the downstream task as an additional service and return to the step of determining whether the additional service is online.
[0038] To solve the above technical problems, the present invention further provides a microservice calling device, comprising:
[0039] memory for storing computer programs;
[0040] A processor is configured to implement the steps of the above-mentioned microservice calling method when executing a computer program.
[0041] To solve the above technical problems, the present invention also 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 above-mentioned microservice calling method are implemented.
[0042] The present invention provides a microservice debugging method, comprising obtaining a current service and downstream services called by the current service; when the current service receives a call instruction or an execution instruction, determining whether a target service exists in the downstream service, wherein the target service is a service preset for the current service; if the target service exists, selecting a downstream service corresponding to the target service as the target downstream service, and determining whether the target downstream service is online; if the target downstream service is online, calling the target downstream service as a to-be-called service; when the to-be-called service is called, determining whether the downstream service other than the target service is online as an additional service; if the additional service is online, calling the additional service as a to-be-called service; if the target service does not exist, treating the downstream task as an additional service and returning to the step of determining whether the additional service is online. This method reduces the impact of a failure on the entire system, shortens debugging time, and automatically recovers. The method selects the call content of the method and calls an available, i.e., online, target downstream service. When the target downstream service is called, to ensure the system availability while ensuring core functionality, it continues to determine whether the additional service is online, calls the additional service as a to-be-called service, and then debugs the downstream service that cannot be called, thereby reducing the number of services to be debugged. Avoid direct debugging of existing debugging services, while waiting for offline services, which increases debugging time costs, and debugging errors caused by the lack of relevant debugging experience of relevant debugging personnel during the entire debugging system process. Further reduce the system coupling degree, reduce the impact of a single service on the system, improve the accuracy of service calls, and save service debugging time costs by calling services.
[0043] In addition, the present invention also provides a microservice calling device and medium, which have the same beneficial effects as the above-mentioned microservice calling method. BRIEF DESCRIPTION OF THE DRAWINGS
[0044] In order to more clearly illustrate the embodiments of the present invention, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.
[0045] Figure 1 A flowchart of a microservice calling method provided by an embodiment of the present invention;
[0046] Figure 2 A schematic diagram of registering the registration service and proxy service provided in an embodiment of the present invention with a service center;
[0047] Figure 3 A schematic diagram of the service provider and service consumer provided by the present invention;
[0048] Figure 4 A structural diagram of a microservice calling device provided by an embodiment of the present invention;
[0049] Figure 5 A structural diagram of another microservice calling device provided by an embodiment of the present invention;
[0050] Figure 6 A structural diagram of a microservice calling device provided in another embodiment of the present invention. DETAILED DESCRIPTION
[0051] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making any creative efforts shall fall within the scope of protection of the present invention.
[0052] The core of the present invention is to provide a microservice calling method, device and medium, which saves the time cost of service calling and improves the accuracy of service calling.
[0053] In order to enable those skilled in the art to better understand the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific implementation methods.
[0054] It should be noted that the microservice invocation method provided by the present invention does not require debugging for in-process services in real-world scenarios, but requires debugging and maintenance for services that are abnormal or undergoing maintenance. This method is based on reducing the impact of a failure on the entire system and shortening debugging time, thereby providing a calling method that calls available services, abandons the failed service, and then resumes the call after the failure is repaired and the unavailable service is restored. The failure mentioned here refers to a temporary unavailability in a general sense, not specifically damage. Planned upgrades, replacements, maintenance, etc. are also applicable. This method can be applied to the robotics field and complex customized and differentiated scenarios. Without specific limitations, it can be applied to any scenario involving a microservice architecture. The microservice architecture is a new technology for deploying applications and services in the cloud or on specific devices. Instead of being an independent function or independent resource like ordinary services, microservices can run in their own programs and communicate through a lightweight device and Hypertext Transfer Protocol (HTTP)-based Application Programming Interface (API). In a microservice architecture, required functionality only needs to be added to a specific service without affecting the overall process architecture.
[0055] Figure 1 A flowchart of a microservice calling method provided by an embodiment of the present invention is as follows: Figure 1 As shown, the method includes:
[0056] S11: Get the current service and the downstream services called by the current service;
[0057] Specifically, the present invention is applicable to the microservice architecture and provides a unified interface for software and hardware modules applicable to different technology stacks. Modules with network access functions register their own services with the service center through service registration, and modules without network access functions register services with the service center through proxy services. After receiving a new registration request, the service center records the service status and refreshes the service status at regular intervals. Each registered service can query the service status from the service center to realize calls between services.
[0058] Get the current service. The current service can be a service that needs to be adapted to the entire system after a new addition or upgrade, or a service corresponding to a functional module described in a single specific purpose. Since the service corresponding to a functional module can be one or more, the current service obtained can also be one or more, and the present invention does not make specific limitations. Get the downstream service called by the current service. For the setting relationship between the current service and the downstream service, you can set which is the current service and which is the downstream service according to the actual scenario. For example, the action of the robotic arm and the camera correspond to different services. After the camera captures the image for recognition, the action of the robotic arm is executed. At this time, the camera service is the current service and the robotic arm service is the downstream service. When the robotic arm action is performed first and then the camera captures the image, the robotic arm service is the current service and the camera service is the downstream service.
[0059] S12: When the current service receives a call instruction or an execution instruction, it determines whether there is a target service in the downstream service, where the target service is the service preset for the current service. If the target service exists, the process proceeds to step S13; if not, the process proceeds to step S14;
[0060] When the current service is called by other services or automatically executed to complete a task, its calling instruction may be to call other services, which may be upstream service calls or downstream service calls. The execution instruction is to execute after the call or to execute the service itself. At this time, it is necessary to determine whether its downstream service has a target service. For services whose target service is preset for the current service, it is a service that must exist for the current service. The existence of a target service in a downstream service does not necessarily mean that all of them are target services. For example, if the current service has a total of 5 downstream services, and there is a target service in the downstream service, then it is determined that the target service exists.
[0061] S13: Select a downstream service corresponding to the target service as the target downstream service, and determine whether the target downstream service is online. If the target downstream service is online, proceed to step S15;
[0062] When it is determined that the target service exists in the downstream service, the downstream service corresponding to the target service is selected as the target downstream service. It is necessary to further determine whether the target downstream service is online. If it is online, enter step S15 to call it. If it is not online, give up the call.
[0063] S15: The target downstream service is taken as the service to be called and is called; in the above embodiment, when the target downstream service is online, the target downstream service is taken as the service to be called and is called.
[0064] S16: When the service to be called is completed, the downstream service other than the target service is used as an additional service to determine whether the additional service is online. If the additional service is online, proceed to step S17; if not, abandon the call.
[0065] It's important to note that additional services are optional and non-critical downstream services for upstream services. These additional services are specified by the upstream task, and the downstream task itself is unaware of whether or not it is an additional service. Furthermore, additional services are non-essential but can generate some revenue. They provide a minimal system paradigm, allowing the system to remain usable while retaining only core functionality, making it easier to scale down or expand the system. Therefore, when the service being called completes, downstream services other than the target service are considered additional services and are determined to be online.
[0066] S17: The additional service is taken as a service to be called and called.
[0067] Likewise, the online additional services are called as services to be called.
[0068] S14: The downstream task is treated as an additional service, and the process returns to the step of determining whether the additional service is online.
[0069] Specifically, when the target service does not exist, the downstream service is directly used as the additional service, and it is determined whether the additional service is online, that is, the process returns to step S16.
[0070] Understandably, when a system failure occurs or adjustments are needed, the faulty service is taken offline to prevent the entire system from being unavailable due to a partial service failure. Subsequent debugging and troubleshooting only needs to be performed on the faulty service, leaving other services unaffected. Once the faulty service is back online, the original system can be quickly restored, saving debugging costs.
[0071] The present invention provides a microservice debugging method, comprising obtaining a current service and downstream services called by the current service; when the current service receives a call instruction or an execution instruction, determining whether a target service exists in the downstream service, wherein the target service is a service preset for the current service; if the target service exists, selecting a downstream service corresponding to the target service as the target downstream service, and determining whether the target downstream service is online; if the target downstream service is online, calling the target downstream service as a to-be-called service; when the to-be-called service is called, determining whether the downstream service other than the target service is online as an additional service; if the additional service is online, calling the additional service as a to-be-called service; if the target service does not exist, treating the downstream task as an additional service and returning to the step of determining whether the additional service is online. This method reduces the impact of a failure on the entire system, shortens debugging time, and automatically recovers. The method selects the call content of the method and calls an available, i.e., online, target downstream service. When the target downstream service is called, to ensure the system availability while ensuring core functionality, it continues to determine whether the additional service is online, calls the additional service as a to-be-called service, and then debugs the downstream service that cannot be called, thereby reducing the number of services to be debugged. Avoid direct debugging of existing debugging services, while waiting for offline services, which increases debugging time costs, and debugging errors caused by the lack of relevant debugging experience of relevant debugging personnel during the entire debugging system process. Further reduce the system coupling degree, reduce the impact of a single service on the system, improve the accuracy of service calls, and save service debugging time costs by calling services.
[0072] Based on the above embodiment, obtaining the current service and the downstream services called by the current service in step S11 includes:
[0073] Start the current service;
[0074] Send the current service to the service registry to register its own service and discover other services for calling;
[0075] Other services that are called are considered downstream services.
[0076] Specifically, Figure 2 A schematic diagram of the registration service and proxy service provided in the embodiment of the present invention registering with the service center, as shown in FIG. Figure 2As shown, each registration service 4 or proxy service 2 registers its own service with the service registry 1 and obtains discovery services from the service registry 1. Non-intelligent devices / network-less devices, or other devices 3 that require a proxy and lack access to the service center, can be included through the proxy service 2. Discovery services allow clients to access available services by reading the registry of the service registry 1. Clients can use this information to connect to the server. Server discovery methods include client-side service discovery and server-side service discovery.
[0077] Figure 3 A schematic diagram of the service provider and service consumer provided by the present invention, such as Figure 3 As shown, the registration service and proxy service can simultaneously serve as two modules: service provider 5 and service consumer 6. As a service provider 5, after its service goes online, it registers its own service with the service registration center 1 and periodically sends heartbeat data to the service registration center 1 to indicate that its service is online, allowing other services to discover and call it. As a service consumer 6, after its service goes online, it can discover other service information from the service registration center 1, receive instructions when other service status changes, and call other services based on the obtained service status information.
[0078] To obtain the current service, you need to start the current service, send the current service to the service registration center 1 to register its own service and discover other services to call. Then, the other services it calls are regarded as downstream services. Specifically, other services can be the content called by the current service, and also include services that are not called by the current service.
[0079] The acquisition of the current service and the downstream service called by the current service provided in the embodiment of the present invention needs to be sent to the service registration center for registration in advance so that subsequent calling work can continue.
[0080] Based on the above embodiment, the method further includes: when the target downstream service selected in step S13 is not online, abandoning the call to the target downstream service and outputting the call result.
[0081] It is understood that if the target downstream service is abandoned, the call result needs to be reported to the upstream service, that is, the current service, the upstream service of the current service, or the service registration center. The call result can be reported actively or passively. Active reporting is the embodiment described above. Passive reporting can be the registration center checking the call status of the downstream service according to a preset time. If the downstream service does not call the service, the registration center actively obtains the call result, and the downstream service then sends the call result.
[0082] The present invention does not make any specific limitation on the content of the call result, which can be the call time, call result, call object, call execution task, etc., and is set according to actual conditions.
[0083] The embodiment of the present invention provides a method for abandoning the call to the target downstream service and outputting the call result when the target downstream service is offline. Abandoning the call to the offline service saves the call cost, and outputting the result makes it easier for users to view and improves the user experience.
[0084] Based on the above embodiment, the method further includes: when the additional service in step S14 is not online, giving up calling the additional service and outputting the calling result.
[0085] It is understandable that if the additional service is abandoned, the calling result needs to be reported to the upstream service, that is, the current service, the upstream service of the current service, or the service registration center. As for the sending method of the calling result, the content of the calling result has been described in detail in the above embodiment and will not be described again here.
[0086] The embodiment of the present invention provides a method for abandoning the call of the additional service and outputting the call result when the additional service is offline. Abandoning the call of the offline service saves the call cost, and outputting the result makes it convenient for the user to view and improves the user experience.
[0087] Based on the above embodiment, the method further includes: outputting the call result when the target downstream service is called as the service to be called in step S15, and outputting the call result when the additional service is called as the service to be called in step S17.
[0088] It is understood that whether a call is made or abandoned, the call result needs to be output and reported to the upstream service, that is, the current service, the upstream service of the current service, or the service registration center. As for the method of sending the call result, the content of the call result has been detailed in the above embodiment and will not be described again here.
[0089] The embodiment of the present invention provides a method for outputting the call result when the target downstream service is called as a to-be-called service, and outputting the call result when the additional service is called as a to-be-called service, which facilitates user viewing and improves user experience.
[0090] Based on the above embodiment, for the output call result, the method further includes:
[0091] Get the upstream service of the current service;
[0092] Send the obtained call results to the upstream service.
[0093] Specifically, the call result is sent to the upstream service through active sending, and the final upstream service is the service registration center. The call result does not send the call results of the different situations mentioned in the present invention at the same time, but only one call result is sent for each situation, so the content of the call result is different.
[0094] The present invention does not make any specific limitation on the content of the call result, which can be the call time, call result, call object, call execution task, etc., and is set according to actual conditions.
[0095] The embodiment of the present invention provides a method for actively sending the call result to the upstream service, which facilitates viewing the call status of the upstream service calling the downstream service.
[0096] Based on the above embodiment, after sending the current service to the service registration center, the method further includes:
[0097] Send heartbeat packets to the service registration center at time intervals to view the service status information of the current service.
[0098] Specifically, a heartbeat packet is a self-defined command word that the client and server devices use to periodically notify each other of their status. It is sent at regular intervals. The receiving and sending of data in the network are implemented using a socket network. The code simply sends a fixed message to the server every few minutes, and the server replies with a fixed message after receiving it. If the server does not receive the client's message within a few minutes, the client is considered disconnected. For example, if some communication software is not used for a long time, to know whether it is online or offline, a heartbeat packet is needed, and packets are sent and received regularly. The sender can be either the client or the server, whichever is more convenient and reasonable. Generally, it is the client. The server can also periodically poll and send heartbeats. The current service status is whether it is online or offline.
[0099] This embodiment provides for sending heartbeat packets to the service registration center according to time intervals so as to view the service status information of the current service, which facilitates the subsequent service to call and invoke.
[0100] The above describes in detail various embodiments corresponding to the microservice calling method. On this basis, the present invention also discloses a microservice calling device corresponding to the above method. Figure 4 This is a structural diagram of a microservice calling device provided by an embodiment of the present invention. Figure 4 As shown, the calling device of the microservice includes:
[0101] Acquisition module 11, used to obtain the current service and the downstream services called by the current service;
[0102] The first judgment module 12 is used to determine whether there is a target service in the downstream service when the current service receives a call instruction or an execution instruction, where the target service is a service preset for the current service. If the target service exists, the second judgment module 13 is triggered; if the target service does not exist, the return module 14 is triggered;
[0103] The second judgment module 13 is used to select a downstream service corresponding to the target service as the target downstream service, and determine whether the target downstream service is online. If the target downstream service is online, the first calling module 15 is triggered;
[0104] A first calling module 15 is used to call the target downstream service as a service to be called;
[0105] The third judgment module 16 is used to, when the call of the to-be-called service is completed, use the downstream service other than the target service as an additional service, determine whether the additional service is online, and trigger the second calling module 17 if the additional service is online;
[0106] The second calling module 17 is used to call the additional service as a service to be called;
[0107] The return module 14 is configured to take the downstream task as an additional service and return to the step of determining whether the additional service is online.
[0108] Since the embodiments of the device part correspond to the above embodiments, the embodiments of the device part please refer to the description of the embodiments of the method part, and will not be repeated here.
[0109] The present invention provides a microservice debugging device, comprising obtaining a current service and downstream services called by the current service; when the current service receives a call instruction or an execution instruction, determining whether a target service exists in the downstream service, where the target service is a service pre-set for the current service; if the target service exists, selecting a downstream service corresponding to the target service as the target downstream service and determining whether the target downstream service is online; if the target downstream service is online, invoking the target downstream service as a pending service; when the pending service is called, determining whether the downstream service other than the target service is online as an additional service; if the additional service is online, invoking the additional service as a pending service; if the target service does not exist, invoking the downstream task as an additional service and returning to the step of determining whether the additional service is online. The device reduces the impact of a failure on the entire system, shortens debugging time, and automatically recovers. The device selects the call content and calls the available, i.e., online, target downstream service. When the target downstream service is called, determining whether the additional service is online and invoking the additional service as a pending service to ensure system availability while maintaining core functionality is maintained. The device then debugs the unavailable downstream service, thereby reducing the number of services to be debugged. Avoid direct debugging of existing debugging services, while waiting for offline services, which increases debugging time costs, and debugging errors caused by the lack of relevant debugging experience of relevant debugging personnel during the entire debugging system process. Further reduce the system coupling degree, reduce the impact of a single service on the system, improve the accuracy of service calls, and save service debugging time costs by calling services.
[0110] Figure 5 A structural diagram of another microservice calling device provided by an embodiment of the present invention, such as Figure 5 As shown, the device includes:
[0111] Memory 21, for storing computer programs;
[0112] The processor 22 is configured to implement the steps of the microservice calling method when executing a computer program.
[0113] The invoking device of the microservice provided in this embodiment may include but is not limited to a smart phone, a tablet computer, a laptop computer, or a desktop computer.
[0114] Among them, the processor 22 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 22 can be implemented in at least one hardware form of a digital signal processor (DSP), a field programmable gate array (FPGA), and a programmable logic array (PLA). The processor 22 may also include a main processor and a coprocessor. The main processor is a processor for processing data in the awake state, also known as a central processing unit (CPU); the coprocessor is a low-power processor for processing data in the standby state. In some embodiments, the processor 22 may be integrated with a graphics processing unit (GPU), which is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 22 may also include an artificial intelligence (AI) processor, which is used to process computing operations related to machine learning.
[0115] The memory 21 may include one or more computer-readable storage media, which may be non-transitory. The memory 21 may also include a high-speed random access memory, and a non-volatile memory, such as one or more disk storage devices, flash memory storage devices. In this embodiment, the memory 21 is at least used to store the following computer program 211, wherein, after the computer program is loaded and executed by the processor 22, it can implement the relevant steps of the microservice calling method disclosed in any of the aforementioned embodiments. In addition, the resources stored in the memory 21 may also include an operating system 212 and data 213, etc., and the storage method may be temporary storage or permanent storage. Among them, the operating system 212 may include Windows, Unix, Linux, etc. The data 213 may include but is not limited to data involved in the microservice calling method, etc.
[0116] In some embodiments, the microservice calling device may further include a display screen 23 , an input / output interface 24 , a communication interface 25 , a power supply 26 , and a communication bus 27 .
[0117] Those skilled in the art will understand that Figure 5 The structure shown in does not constitute a limitation on the calling device of the microservice and may include more or fewer components than shown in the figure.
[0118] The processor 22 implements the microservice calling method provided by any of the above embodiments by calling instructions stored in the memory 21.
[0119] The present invention provides a microservice debugging device, comprising obtaining a current service and downstream services called by the current service; when the current service receives a call instruction or an execution instruction, determining whether a target service exists in the downstream service, where the target service is a service pre-set for the current service; if the target service exists, selecting a downstream service corresponding to the target service as the target downstream service and determining whether the target downstream service is online; if the target downstream service is online, invoking the target downstream service as a pending service; when the pending service is called, determining whether the downstream service other than the target service is online as an additional service; if the additional service is online, invoking the additional service as a pending service; if the target service does not exist, invoking the downstream task as an additional service and returning to the step of determining whether the additional service is online. The device reduces the impact of a failure on the entire system, shortens debugging time, and automatically recovers. The device selects the call content and calls the available, i.e., online, target downstream service. When the target downstream service is called, determining whether the additional service is online and invoking the additional service as a pending service to ensure system availability while maintaining core functionality is maintained. The device then debugs the unavailable downstream service, thereby reducing the number of services to be debugged. Avoid direct debugging of existing debugging services, while waiting for offline services, which increases debugging time costs, and debugging errors caused by the lack of relevant debugging experience of relevant debugging personnel during the entire debugging system process. Further reduce the system coupling degree, reduce the impact of a single service on the system, improve the accuracy of service calls, and save service debugging time costs by calling services.
[0120] Furthermore, the present invention also provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by the processor 22, the steps of the above-mentioned microservice calling method are implemented.
[0121] It is understandable that if the method in the above embodiment is implemented in the form of 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 the present invention, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and executes all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes various media that can store program code, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.
[0122] For an introduction to a computer-readable storage medium provided by the present invention, please refer to the above method embodiment, which will not be described in detail herein. It has the same beneficial effects as the above microservice calling method.
[0123] Figure 6 A structural diagram of a microservice calling device provided in another embodiment of the present invention is shown as follows: Figure 6 As shown, the device is a robotic arm that uses image recognition to perform mechanical grasping operations. Each task analysis service in the figure can be connected to the service registration center. Solid arrows represent target services, and dashed arrows represent non-target services. Task publishing service 33 accepts external calls to set tasks, that is, it considers setting task 31. Task analysis service 32 determines whether robotic arm service 34 and task publishing service 33 are online. If task publishing service 33 or robotic arm service 34 are not online, the call is abandoned; otherwise, subsequent calls are executed. Task analysis service 32 calls task publishing service 33 to obtain the task to be executed. Task analysis service 32 calls robotic arm service 34. Task analysis service 32 calls temperature sensing proxy service 35, which includes temperature sensor 38. After receiving the task analysis service 32, robotic arm service 34 determines whether all target services of downstream services are online. Robotic arm service 34 calls camera service 36 to obtain images. Robotic arm service 34 calls image recognition service 37 to analyze the images. The robotic arm completes the action.
[0124] The above describes a structural diagram of a microservice calling device provided by another embodiment of the present invention, which has the same beneficial effects as the microservice calling method mentioned above.
[0125] As a preferred embodiment, it can be analyzed in different situations. In the system used, A is the current system, B is the target service, and C is the additional service;
[0126] When both B and C are online and invoking each other, A obtains its downstream service information (A knows in advance that its downstream services are B and C, and that they are key and additional services, respectively). A then determines whether the target service exists. If so, it further determines whether the target service is online. If so, it sets the target service's corresponding downstream service, B, as the service to be called. After B completes the call, A determines whether the additional service exists. If so, it further determines whether it is online. If so, it calls the additional service as the service to be called.
[0127] When B is online and C is offline, the calling process is as follows: Based on the above content, after B completes the call, A determines whether it has additional services. If so, it further determines whether it is online. If not, it gives up calling the additional service.
[0128] When B is offline and C is online, the calling process is as follows: Combined with the above content, when the target service is offline, the calling content of the current service is directly abandoned.
[0129] When B is not online and C is not online, the calling process is as follows: Combined with the above content, when the target service is not online, the calling content of the current service is directly abandoned.
[0130] When B is online, the calling process is as follows: Based on the above content, the downstream service B corresponding to the target service is used as the service to be called. After B completes the call, A checks whether it has additional services. If not, the process ends.
[0131] When B is not online, the calling process is as follows: Combined with the above content, the call is directly abandoned.
[0132] When C is online, the calling process is as follows: Based on the above content, if the target service does not exist, it is determined whether the additional service is online. If it is online, C is used as the service to be called.
[0133] The calling process when C is not online is as follows: Based on the above content, if the target service does not exist, it is determined whether the additional service is online. If not, the calling of the additional service is abandoned.
[0134] The above describes an analysis of a microservice calling method provided by another embodiment of the present invention, which has the same beneficial effects as the microservice calling method mentioned above.
[0135] The above is a detailed introduction to a microservice calling method, a microservice calling device and a medium provided by the present invention. The various embodiments in the specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same and similar parts between the various embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part description. It should be pointed out that for ordinary technicians in this technical field, without departing from the principle of the present invention, the present invention can also be improved and modified in several ways, and these improvements and modifications also fall within the scope of protection of the claims of the present invention.
[0136] It should also be noted that, in this specification, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus comprising the element.
Claims
1. A method for calling a microservice, characterized in that: include: Obtain the current service and the downstream services called by the current service; specifically, the following steps are performed: starting the current service; sending the current service to the service registration center to register its own service and discover other services to call; using the other called services as the downstream services; other services are the content called in the current service and services not called by the current service; modules with network access function register their own services with the service center through service registration, while modules without network access function register services with the service center through proxy service; When the current service receives a call instruction or an execution instruction, determining whether the downstream service has a target service, wherein the target service is a service preset for processing by the current service; If the target service exists, then select the downstream service corresponding to the target service as the target downstream service, and determine whether the target downstream service is online; wherein the target service exists in the downstream services, and not all of them are target services; If the target downstream service is online, the target downstream service is used as the service to be called and called; When the call of the to-be-called service is completed, the downstream service other than the target service is used as an additional service, and whether the additional service is online is determined; If the additional service is online, the additional service is used as the service to be called and is called; the additional service is a minimum paradigm for the system; the additional service is a downstream service that is optional and non-critical to the upstream service, and the additional service is specified by the upstream task; If the target service does not exist, the downstream task is used as an additional service, and the process returns to the step of determining whether the additional service is online. Correspondingly, when the target downstream service or the additional service is not online, the calling of the corresponding service is abandoned and the corresponding calling result is output.
2. The microservice calling method according to claim 1, characterized in that: Also includes: When calling the target downstream service as the service to be called, outputting a calling result; When the additional service is called as the service to be called, a calling result is output.
3. The microservice calling method according to claim 2, characterized in that: Also includes: Get the upstream service of the current service; The obtained call result is sent to the upstream service.
4. The microservice calling method according to claim 1, characterized in that: After sending the current service to the service registration center, the method further includes: Send heartbeat packets to the service registration center according to time intervals to view the service status information of the current service.
5. A microservice calling device, characterized in that: include: An acquisition module is used to acquire the current service and the downstream services called by the current service; specifically, it includes: starting the current service; sending the current service to the service registration center to register its own service and discover other services to call; using the called other services as the downstream services; other services are the content called in the current service and services not called by the current service; modules with network access function register their own services with the service center through service registration, and modules without network access function register services with the service center through proxy service; A first judgment module is configured to, when the current service receives a call instruction or an execution instruction, determine whether the downstream service has a target service, wherein the target service is a service preset for the current service, and trigger the second judgment module if the target service exists; otherwise, trigger the return module; The second judgment module is used to select a downstream service corresponding to the target service as the target downstream service, determine whether the target downstream service is online, and trigger the first calling module if the target downstream service is online; wherein the target service exists in the downstream services and not all of them are target services; The first calling module is used to call the target downstream service as a service to be called; a third judgment module, configured to, when the call of the to-be-called service is completed, use a downstream service other than the target service as an additional service, determine whether the additional service is online, and trigger the second calling module if the additional service is online; The second calling module is used to call the additional service as the service to be called; the additional service is a minimum paradigm for the system; the additional service is a downstream service that is optional and non-critical to the upstream service, and the additional service is specified by the upstream task; The return module is configured to take the downstream task as an additional service and return to the step of determining whether the additional service is online; Correspondingly, when the target downstream service or the additional service is not online, the calling of the corresponding service is abandoned and the corresponding calling result is output.
6. A microservice calling device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of the microservice calling method according to any one of claims 1 to 4 when executing the computer program.
7. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the microservice calling method according to any one of claims 1 to 4.
Citation Information
Patent Citations
Microservice management system, method and device, computer equipment and storage medium
CN109714319A
Managing parallel microservices
US20220066775A1