Micro-service calling method, device and equipment and storage medium

Abstract

Embodiments of the present application provide a micro-service calling method, device and equipment and a storage medium. The method comprises: obtaining a calling request of a first micro-service calling a second micro-service in a target system, the target system comprising at least one business module, the calling request comprising a first micro-service registration address of the first micro-service, a second micro-service registration address of the second micro-service, the first micro-service registration address comprising a first module identifier of a business module to which the first micro-service belongs, a first micro-service type of the first micro-service and a first micro-service identifier, and the second micro-service registration address comprising a second module identifier of a business module to which the second micro-service belongs, a second micro-service type of the second micro-service and a second micro-service identifier; determining whether the second micro-service supports being called by the first micro-service according to the first micro-service registration address and the second micro-service registration address; and if the second micro-service supports being called by the first micro-service, calling the second micro-service according to the second micro-service identifier, thereby improving the efficiency and security of micro-service calling.

Description

Technical Field

[0001] This application relates to the field of microservice technology, and in particular to a microservice invocation method, apparatus, device and storage medium. Background Technology

[0002] An internet system typically consists of multiple business modules. Due to the large scale of these modules, microservice calls are often required within and between different business modules.

[0003] Traditional microservice invocation solutions typically treat business modules as independent platforms, with complete isolation between them. Microservice invocation between business modules is implemented using a capability-opening approach, which involves encapsulating microservices into a capability layer and then placing the capabilities in a dedicated capability development platform to enable capability invocation.

[0004] However, traditional microservice invocation schemes require the establishment of a capability layer, and microservice invocation is indirectly implemented through the capability layer, which reduces the efficiency of microservice invocation. Summary of the Invention

[0005] This application provides a microservice invocation method, apparatus, device, and storage medium, which can improve the efficiency and security of microservice invocation.

[0006] In a first aspect, embodiments of this application provide a microservice invocation method, the method comprising:

[0007] Obtain the call request from the first microservice to the second microservice in the target system. The target system includes at least one business module. The call request includes the first microservice registration address of the first microservice and the second microservice registration address of the second microservice. The first microservice registration address includes the first module identifier of the business module to which the first microservice belongs, the first microservice type of the first microservice, and the first microservice identifier of the first microservice. The second microservice registration address includes the second module identifier of the business module to which the second microservice belongs, the second microservice type of the second microservice, and the second microservice identifier of the second microservice.

[0008] Based on the registration addresses of the first and second microservices, determine whether the second microservice supports being called by the first microservice;

[0009] If the second microservice supports being called by the first microservice, the second microservice is called based on the identifier of the second microservice.

[0010] Secondly, embodiments of this application provide a microservice invocation device, the device comprising:

[0011] The acquisition module is used to acquire a call request from a first microservice in a target system to call a second microservice. The target system includes at least one business module. The call request includes the first microservice registration address of the first microservice and the second microservice registration address of the second microservice. The first microservice registration address includes the first module identifier of the business module to which the first microservice belongs, the first microservice type of the first microservice, and the first microservice identifier of the first microservice. The second microservice registration address includes the second module identifier of the business module to which the second microservice belongs, the second microservice type of the second microservice, and the second microservice identifier of the second microservice.

[0012] The determination module is used to determine whether the second microservice supports being called by the first microservice, based on the registration address of the first microservice and the registration address of the second microservice.

[0013] The calling module is used to invoke the second microservice based on the identifier of the second microservice when the second microservice supports being invoked by the first microservice.

[0014] Thirdly, embodiments of this application provide a microservice invocation device, which includes: a processor and a memory storing computer program instructions; the processor executes the computer program instructions to implement the microservice invocation method described in the first aspect.

[0015] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the microservice invocation method described in the first aspect.

[0016] This application provides a microservice invocation method, apparatus, device, and storage medium. It can obtain a call request from a first microservice in a target system to call a second microservice. The call request includes the first microservice's registration address and the second microservice's registration address. Based on the first and second microservice registration addresses, it determines whether the second microservice supports being invoked by the first microservice. If the second microservice supports being invoked by the first microservice, it invokes the second microservice based on its second microservice identifier. In this way, based on the registration addresses of the requesting and called microservices, the feasibility of the microservice invocation can be quickly determined. If feasible, the microservice can be invoked quickly, improving the efficiency and security of microservice invocation and reducing the pressure on backend microservices. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a schematic diagram of a microservice invocation scenario provided in an embodiment of this application;

[0019] Figure 2 This is a flowchart illustrating a microservice invocation method provided in an embodiment of this application;

[0020] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0021] Figure 4 This is a schematic diagram of the structure of a microservice invocation device provided in an embodiment of this application;

[0022] Figure 5 This is a schematic diagram of the structure of a microservice calling device provided in an embodiment of this application. Detailed Implementation

[0023] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and not intended to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0024] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0025] To address the problems in the background technology, embodiments of this application provide a microservice invocation method, apparatus, device, and storage medium. It can obtain an invocation request from a first microservice in a target system to invoke a second microservice. The invocation request includes the first microservice's registration address and the second microservice's registration address. Based on the first and second microservice registration addresses, it is determined whether the second microservice supports being invoked by the first microservice. If the second microservice supports being invoked by the first service, it is invoked based on its second microservice identifier. In this way, based on the registration addresses of the microservice requesting the invocation and the invoked microservice, the feasibility of the microservice invocation can be quickly determined. If feasible, the microservice can be invoked quickly, improving the efficiency and security of microservice invocation and reducing the pressure on backend microservices.

[0026] The microservice invocation method, apparatus, device, and storage medium provided in this application will be described in detail below with reference to the accompanying drawings and through specific embodiments and application scenarios.

[0027] Figure 1 This is a schematic diagram of a microservice invocation scenario provided in an embodiment of this application, such as... Figure 1 As shown, in this microservice call scenario, there are electronic devices 110 and target systems 120. Electronic devices 110 and target systems 120 are connected by communication, which can be wired or wireless communication.

[0028] Among them, electronic device 110 can be a server, network attached storage (NAS), or personal computer (PC), etc.

[0029] The target system 120 can be an Internet Technology (IT) system, such as a communication system, a payment system, or an Internet of Things (IoT) system, etc., without limitation. The target system 120 may include multiple business modules, and the business logic of each module can be implemented by combining multiple microservices.

[0030] like Figure 1As shown, in the target system 120, when a business module executes its business logic, it needs to call a microservice. Specifically, the electronic device 110 can obtain a call request from the first microservice in the target system 120 to call the second microservice. The first microservice is the microservice requesting the call, and the second microservice is the microservice being called. The call request includes the first microservice registration address of the first microservice and the second microservice registration address of the second microservice. The first microservice registration address includes the first module identifier of the business module to which the first microservice belongs, the first microservice type, and the first microservice identifier. The second microservice registration address includes the second module identifier of the business module to which the second microservice belongs, the second microservice type, and the second microservice identifier. For example, the microservice registration address is used for microservice link tracing and analysis, the module identifier indicates the module's identity, the microservice type indicates the microservice's control type, and the microservice identifier indicates the microservice's identity. Then, based on the first and second microservice registration addresses, it can be determined whether the second microservice supports being called by the first microservice. If the second microservice supports being called by the first microservice, the second microservice is called based on the second microservice identifier.

[0031] In this way, based on the registration addresses of the microservices that request and call the microservice, it is possible to quickly determine whether the microservice call is feasible. If it is feasible, the microservice can be called quickly, improving the efficiency and security of microservice calls and reducing the pressure on backend microservices.

[0032] The microservice invocation method provided in the embodiments of this application will be described below. The executing entity of this microservice invocation method can be... Figure 1 The electronic device 110 shown.

[0033] Figure 2 This is a flowchart illustrating a microservice invocation method provided in an embodiment of this application, as shown below. Figure 2 As shown, the microservice invocation method may include the following steps:

[0034] S210: Obtain the call request from the first microservice in the target system to call the second microservice.

[0035] The target system includes at least one business module, a first microservice is the microservice requesting a microservice call, and a second microservice is the microservice being called. The call request includes the first microservice registration address of the first microservice and the second microservice registration address of the second microservice. The first microservice registration address includes the first module identifier of the business module to which the first microservice belongs, the first microservice type of the first microservice, and the first microservice identifier of the first microservice. The second microservice registration address includes the second module identifier of the business module to which the second microservice belongs, the second microservice type of the second microservice, and the second microservice identifier of the second microservice.

[0036] Understandably, the microservice registration address is used for tracing and analyzing the microservice chain, the module identifier is used to represent the identity of the module (which can be the module name), and the microservice type is used to represent the control type of the microservice. The microservice identifier is used to represent the identity of the microservice (which can be the microservice name, and the microservice name can be considered the actual address of the microservice).

[0037] As an example, in the target system, when a business module performs its business logic, it needs to call a microservice. In this case, it can receive a call request from the server where the first microservice is deployed, requesting the first microservice to call the second microservice.

[0038] S220, based on the registration address of the first microservice and the registration address of the second microservice, determine whether the second microservice supports being called by the first microservice.

[0039] Optionally, if the second microservice type is a public type, it can be determined that the second microservice supports being called by the first microservice. Here, a public type means that the microservice supports calls from any microservice of any business module.

[0040] For example, the first microservice is microservice 'a', registered at ` / module_x / public / server_a`, where the first module identifier is `module_x`, the first microservice type is `public`, and the first microservice identifier is `server_a`. The second microservice is microservice 'b', registered at ` / module_x / public / server_b`, where the second module identifier is `module_x`, the second microservice type is `public`, and the second microservice identifier is `server_b`. By comparison, we know that the second microservice's type is `public`, meaning it supports calls from any microservice. Therefore, we can determine that the second microservice can be called by the first microservice.

[0041] If the second microservice type is an internal type and the first module identifier is the same as the second module identifier, it can be determined that the second microservice supports being called by the first microservice. Here, "internal type" means that the microservice supports calls from any microservice within the same business module.

[0042] For example, the first microservice is microservice a, and its registration address is / module_x / public / server_a. The second microservice is microservice b, and its registration address is / module_x / inside / server_b. By comparison, we can see that the second microservice is of type "inside," meaning it supports calls from any microservice within the same submodule. Furthermore, the identifiers of the first and second modules are both "module_x," indicating that the first and second microservices belong to the same module. Therefore, we can determine that the second microservice can be called by the first microservice.

[0043] If the second microservice type is an authorization type, and the authorization list corresponding to the second microservice registration address contains the registration address of the first microservice, then the second microservice is determined to be callable by the first microservice. Here, authorization type indicates that the microservice supports calls from authorized microservices, and the authorization list corresponding to the second microservice registration address includes the registration addresses of the microservices authorized to call the second microservice.

[0044] For example, the first microservice is microservice a, and its registration address is / module_x / public / server_a. The second microservice is microservice b, and its registration address is / module_x / auth / server_b. By comparison, we can see that the second microservice is of type auth, meaning it supports authorized microservice calls. Meanwhile, / m o The authorization list corresponding to dule_x / auth / server_b contains / m o The value of `dule_x / public / server_a` indicates that the first service has been authorized to be invoked by the second microservice. Therefore, it can be determined that the second microservice supports being invoked by the first microservice.

[0045] If both the second microservice type and the first microservice type are private types, the name of the second microservice type is the same as the name of the first microservice type, and the identifier of the first module is the same as the identifier of the second module, then the second microservice is determined to be callable by the first microservice. Here, a private type indicates that the microservice supports calls from other microservices within the same module and scope.

[0046] For example, the first microservice is microservice a, and its registration address is / module_x / def_x / server_a. The second microservice is microservice b, and its registration address is / module_x / def_x / / server_b. By comparison, we can see that both the first and second microservices are of type 'def', i.e., private types. At the same time, the name of the second microservice type is the same as the first microservice type, 'def_x', and the identifiers of the first and second modules are both 'module_x', meaning the first and second microservices belong to the same module and the same scope. Therefore, it can be determined that the second microservice can be called by the first microservice.

[0047] In this way, by comparing the registration addresses of the first and second microservices, it can be determined whether the second microservice is allowed to be called by the first microservice, thereby achieving security control over microservice calls.

[0048] S230, if the second microservice supports being called by the first microservice, the second microservice is called according to the identifier of the second microservice.

[0049] In one embodiment, where the second microservice supports invocation by the first microservice, the second microservice identifier can be extracted from the second microservice's registration address. Based on the second microservice identifier, at least one server deploying the second microservice is determined, i.e., at least one server corresponding to the second microservice identifier. Then, according to a load balancing algorithm, a target server for invoking the second microservice is determined from the at least one server, and the second microservice is invoked from the target server. This load balancing approach determines the optimal server for executing microservice calls, improving invocation efficiency and resource utilization.

[0050] For example, the first microservice is microservice a, and its registration address is / module_x / public / server_a. The second microservice is microservice b, and its registration address is / module_x / public / server_b. Microservice b is deployed on servers 1 and 2. Server 1's address is IP_1:portal / server_b, and server 2's address is IP_2:portal / server_b. Therefore, when microservice a calls microservice b, microservice b can also be called by microservice a. It can extract `server_b` from / module_x / public / server_b, or it can be viewed as converting / module_x / public / server_b into `server_b`. According to the load balancing algorithm, the target server is determined to be server 2. Server 2 is accessed using its address, IP_2:portal / server_b, and microservice b is called from server 2.

[0051] In this embodiment, the feasibility of a microservice call can be quickly determined based on the registration addresses of the microservice requesting the call and the called microservice. If feasible, the microservice can be called quickly without the need for capability development, thus improving the efficiency and security of microservice calls and reducing the pressure on backend microservices.

[0052] Before a first microservice calls a second microservice, both the first and second microservices need to register first. In other words, both parties involved in the microservice call need to register before the call. In one embodiment, a microservice registration request for the target microservice can be obtained. The target microservice is the microservice that needs to be registered, and the registration request includes at least one third module identifier of the business module to which the target microservice belongs, the third microservice type of the target microservice, and the third microservice identifier. In response to the registration request, the target microservice is registered, obtaining its third microservice registration address. The third microservice registration address includes the third module identifier, the third microservice type, and the third service identifier.

[0053] For example, the microservice registration request for microservice c includes module_x, public, and server_c. The third module is identified as module_x, the third microservice type is public, and the third microservice identifier is server_c. Registering microservice c yields the third microservice registration address as / module_x / public / server_c.

[0054] The microservice registration request for microservice c includes module_x, inside, and server_c, where the third microservice type is inside. Registering microservice c yields the third microservice registration address as / module_x / inside / server_c.

[0055] The microservice registration request for microservice c includes module_x, auth, and server_c, where the third microservice type is auth, i.e., the authorization type. Registering microservice c yields the third microservice registration address as / module_x / auth / server_c.

[0056] The microservice registration request for microservice c includes module_x, def_x, and server_c. The third microservice type is def (private), and its name is def_x. Registering microservice c yields the third microservice registration address as / module_x / def_x / server_c.

[0057] For example, when the third microservice type of the target microservice is an authorization type, an authorization list for the target microservice needs to be configured. This authorization list corresponds to the registration address of the third microservice of the target microservice, including the registration address of the microservice that authorizes calls to the target microservice. Specifically, it can be manually specified that all microservices of a certain business module can access the target microservice, all microservices of a certain business module can access all microservices of the business module to which the target microservice belongs, a certain microservice can access the target microservice, etc., without any restrictions.

[0058] The microservice invocation method provided in this application will be described in detail below with reference to a specific embodiment:

[0059] like Figure 3 As shown, the electronic device 110 may include a configuration module 111, a security service registration module 112, a security control gateway module 113, a service authorization control module 114, and a security service routing module 115.

[0060] Users can configure the security service registration address and service authorization control address through configuration module 111. When the target microservice (i.e., the microservice to be registered) is registered, the server deploying the target microservice can first obtain basic information such as the security service registration address and service authorization control address from configuration module 111. Then, the microservice registration request is sent to the security service registration module 112 corresponding to the security service registration address.

[0061] The security service registration module 112 can register the target microservice according to the microservice registration request, and obtain the third microservice registration address of the target microservice. If the third microservice type is authorized, the security service registration module 112 will synchronize the third microservice registration address to the service authorization control module 114 corresponding to the service authorization control address.

[0062] Users can configure and store the authorization list of the target microservice through the service authorization control module 114. The authorization list of the target microservice corresponds to the registration address of the third microservice.

[0063] When a registered first microservice calls a registered second microservice, the server deploying the first microservice can send a call request from the first microservice to the security control gateway module 113.

[0064] The security control gateway module 113 can determine whether the second microservice supports being called by the first microservice based on the first microservice registration address and the second microservice registration address. For example, when the second microservice type is authorized, it can obtain the authorization list corresponding to the second microservice registration address from the service authorization control module 114. If the first microservice registration address exists in the authorization list, it is determined that the second microservice supports being called by the first microservice. If the second microservice supports being called by the first microservice, a call request is sent to the security service routing module 115.

[0065] The security service routing module 115 can extract the second microservice identifier from the second microservice registration address, that is, convert the second microservice registration address into the second microservice identifier, which is the real address of the second microservice. Based on the second microservice identifier, it determines at least one server where the second microservice is deployed. Then, based on the load balancing algorithm, it determines the target server from the at least one server, and then accesses the target server based on the address of the target server, and calls the second microservice from the target server.

[0066] Based on the microservice invocation method provided in the embodiments of this application, the embodiments of this application also provide a microservice invocation apparatus, such as... Figure 4 As shown, the microservice invocation device 400 may include:

[0067] The acquisition module 410 is used to acquire a call request from a first microservice in a target system to call a second microservice. The target system includes at least one business module. The call request includes the first microservice registration address of the first microservice and the second microservice registration address of the second microservice. The first microservice registration address includes the first module identifier of the business module to which the first microservice belongs, the first microservice type of the first microservice, and the first microservice identifier of the first microservice. The second microservice registration address includes the second module identifier of the business module to which the second microservice belongs, the second microservice type of the second microservice, and the second microservice identifier of the second microservice.

[0068] The determination module 420 is used to determine whether the second microservice supports being called by the first microservice based on the registration address of the first microservice and the registration address of the second microservice.

[0069] Module 430 is used to invoke the second microservice based on its identifier, provided that the second microservice is supported for invocation by the first microservice.

[0070] In one embodiment, the determining module 420 is specifically used for:

[0071] If the second microservice type is a public type, then the second microservice is determined to be able to be called by the first microservice.

[0072] In one embodiment, the determining module 420 is specifically used for:

[0073] If the second microservice type is an internal type and the first module identifier is the same as the second module identifier, then the second microservice is determined to be able to be called by the first microservice.

[0074] In one embodiment, the determining module 420 is specifically used for:

[0075] If the second microservice type is an authorization type, and the registration address of the first microservice exists in the authorization list corresponding to the second microservice identifier, then it is determined that the second microservice supports being called by the first microservice.

[0076] In one embodiment, the determining module 420 is specifically used for:

[0077] If both the second microservice type and the first microservice type are private types, the name of the second microservice type is the same as the name of the first microservice type, and the first module identifier is the same as the second module identifier, then it is determined that the second microservice supports being called by the first microservice.

[0078] In one embodiment, module 430 is specifically used for:

[0079] Based on the second microservice identifier, identify at least one server where the second microservice is deployed.

[0080] Based on the load balancing algorithm, the target server for calling the second microservice is determined from at least one server.

[0081] Call the second microservice from the target server.

[0082] In one embodiment, the acquisition module 410 is further configured to acquire a microservice registration request for the target microservice, wherein the microservice registration request includes at least one third module identifier of the business module to which the target microservice belongs, the third microservice type of the target microservice, and the third microservice identifier.

[0083] The microservice invocation device 400 may also include:

[0084] The registration module is used to respond to microservice registration requests, register the target microservice, and obtain the third microservice registration address of the target microservice. The third microservice registration address includes the third module identifier, the third microservice type, and the third microservice identifier.

[0085] Understandable, Figure 4Each module / unit in the microservice invocation device 400 shown has the function of implementing each step in the microservice invocation method provided in the embodiments of this application, and can achieve its corresponding technical effect. For the sake of brevity, it will not be described in detail here.

[0086] Figure 5 This is a schematic diagram of the structure of a microservice calling device provided in an embodiment of this application. For example... Figure 5 As shown, the determining device may include a processor 501 and a memory 502 storing computer program instructions.

[0087] Specifically, the processor 501 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0088] Memory 502 may include mass storage for data or instructions. For example, and not limitingly, memory 502 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 502 may include removable or non-removable (or fixed) media. Where appropriate, memory 502 may be internal or external to a defined device. In a particular embodiment, memory 502 is a non-volatile solid-state memory. In a particular embodiment, memory 502 includes read-only memory (ROM). Where appropriate, the ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically rewritable ROM (EAROM), or flash memory, or a combination of two or more of these.

[0089] The processor 501 can implement the microservice calling method provided in this application embodiment by reading and executing the computer program instructions stored in the memory 502, and achieve the corresponding technical effects achieved by executing the method in this application embodiment. For the sake of brevity, it will not be described in detail here.

[0090] In one example, the determining device may further include a communication interface 503 and a bus 510. Wherein, as... Figure 5 As shown, the processor 501, memory 502, and communication interface 503 are connected through bus 510 and complete communication with each other.

[0091] The communication interface 503 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0092] Bus 510 includes hardware, software, or both, which couples together the components that define the device. For example, and not as a limitation, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local Bus (VESA Local Bus, VLB) bus, or other suitable buses, or a combination of two or more of these. Where appropriate, bus 510 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0093] The device can execute the microservice invocation method in the embodiments of this application, thereby achieving the corresponding technical effects of the microservice invocation method provided in the embodiments of this application.

[0094] In addition, this application embodiment also provides a computer-readable storage medium storing computer program instructions; when the computer program instructions are executed by a processor, they implement the microservice invocation method provided in this application embodiment.

[0095] It should be clarified that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually, and for the sake of brevity, they will not be described again. This application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0096] The functional blocks shown in the above-described structural diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, ASICs, appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. The programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, EROM, floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0097] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0098] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0099] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A microservice invocation method, characterized in that, The method includes: The system obtains a call request from a first microservice in a target system to call a second microservice. The target system includes at least one business module. The call request includes a first microservice registration address for the first microservice and a second microservice registration address for the second microservice. The first microservice registration address includes a first module identifier, a first microservice type, and a first microservice identifier of the business module to which the first microservice belongs within the at least one business module. The second microservice registration address includes a second module identifier, a second microservice type, and a second microservice identifier of the business module to which the second microservice belongs within the at least one business module. The microservice type indicates the control type of the microservice. The microservice registration address is used for tracing and analyzing microservice links. Both the first and second microservices need to register before calling the second microservice. Based on the first microservice registration address and the second microservice registration address in the call request, determine whether the second microservice supports being called by the first microservice; If the second microservice supports being invoked by the first microservice, the second microservice is invoked based on the identifier of the second microservice. The step of determining whether the second microservice supports being called by the first microservice based on the first microservice registration address and the second microservice registration address in the call request includes: If the second microservice type is an authorization type, and the first microservice registration address exists in the authorization list corresponding to the second microservice registration address, then it is determined that the second microservice supports being called by the first microservice; wherein, the authorization type indicates that the microservice supports being called by authorized microservices, and the authorization list corresponding to the second microservice registration address includes the microservice registration address authorized to call the second microservice; If the second microservice type is a public type, it is determined that the second microservice supports being called by the first microservice; If the second microservice type is an internal type and the first module identifier is the same as the second module identifier, it is determined that the second microservice supports being called by the first microservice. If both the second microservice type and the first microservice type are private types, the name of the second microservice type is the same as the name of the first microservice type, and the first module identifier is the same as the second module identifier, then it is determined that the second microservice supports being called by the first microservice.

2. The method according to claim 1, characterized in that, The step of invoking the second microservice based on the second microservice identifier includes: Based on the second microservice identifier, at least one server is identified where the second microservice is deployed; According to the load balancing algorithm, a target server for calling the second microservice is determined from the at least one server; The second microservice is invoked from the target server.

3. The method according to claim 1, characterized in that, The method further includes: Obtain the microservice registration request of the target microservice, wherein the microservice registration request includes the third module identifier of the business module to which the target microservice belongs in the at least one business module, the third microservice type of the target microservice, and the third microservice identifier; In response to the microservice registration request, the target microservice is registered to obtain the third microservice registration address of the target microservice, wherein the third microservice registration address includes the third module identifier, the third microservice type, and the third microservice identifier.

4. A microservice invocation device, characterized in that, The device includes: The acquisition module is used to acquire a call request from a first microservice in a target system to call a second microservice. The target system includes at least one business module. The call request includes a first microservice registration address of the first microservice and a second microservice registration address of the second microservice. The first microservice registration address includes a first module identifier, a first microservice type, and a first microservice identifier of the business module to which the first microservice belongs within the at least one business module. The second microservice registration address includes a second module identifier, a second microservice type, and a second microservice identifier of the business module to which the second microservice belongs within the at least one business module. The microservice type indicates the control type of the microservice. The microservice registration address is used for microservice link tracing and analysis. Both the first and second microservices need to register before calling the second microservice. The determining module is used to determine whether the second microservice supports being called by the first microservice based on the first microservice registration address and the second microservice registration address in the call request; The invocation module is used to invoke the second microservice based on the identifier of the second microservice, provided that the second microservice supports invocation by the first microservice. Specifically, the determining module can be used for: If the second microservice type is an authorization type, and the first microservice registration address exists in the authorization list corresponding to the second microservice registration address, then it is determined that the second microservice supports being called by the first microservice; wherein, the authorization type indicates that the microservice supports being called by authorized microservices, and the authorization list corresponding to the second microservice registration address includes the microservice registration address authorized to call the second microservice; If the second microservice type is a public type, it is determined that the second microservice supports being called by the first microservice; If the second microservice type is an internal type and the first module identifier is the same as the second module identifier, it is determined that the second microservice supports being called by the first microservice. If both the second microservice type and the first microservice type are private types, the name of the second microservice type is the same as the name of the first microservice type, and the first module identifier is the same as the second module identifier, then it is determined that the second microservice supports being called by the first microservice.

5. A microservice invocation device, characterized in that, The device includes: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, it implements the microservice invocation method as described in any one of claims 1-3.

6. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed by a processor, implement the microservice invocation method as described in any one of claims 1-3.

Images