Micro-service calling method and apparatus, server, and storage medium

Abstract

The application provides a micro-service calling method and device, a server and a storage medium. It relates to the technical field of micro-service. The method comprises the following steps: in response to receiving the configuration information sent by each micro-service, configuring the corresponding database, and sending the corresponding database to each micro-service. In response to receiving the micro-service calling request, the corresponding calling information is determined. When the first transaction code exists in both the global addressing view database and the consumption transaction code list of the first micro-service, the target publishing environment identifier corresponding to the first transaction code is obtained from the global addressing view database, the registered component information corresponding to the target publishing environment identifier is obtained from the transaction configuration database, the target service instance corresponding to the first transaction code is addressed in the second micro-service based on the registered component information, the micro-service calling request is processed through the target service instance, and the processing result sent by the second micro-service is received and sent to the first micro-service, thereby solving the problem of low micro-service calling efficiency in the prior art.

Description

Technical Field

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

[0002] Microservices are applications composed of multiple smaller, loosely coupled services. Due to the loose coupling between services, microservices offer advantages such as independent deployment, easy code updates, and flexible configuration. This makes them suitable for environments with numerous services, complex call relationships, and diverse runtime frameworks, such as their widespread application in distributed systems. Different types of services can be implemented by calling microservices.

[0003] Existing microservice invocation methods, such as those using load balancing in microservices, can adopt the concept of consumer services and provider services, and provide invocation interface services in a reverse manner through annotation injection.

[0004] However, due to the large number of interfaces in microservices and the complexity of the cluster environment, the above-mentioned calling methods between microservices may fail to accurately address the microservice cluster environment or call the wrong microservice, thus failing to achieve microservice calls and resulting in low calling efficiency. Summary of the Invention

[0005] This application provides a microservice invocation method, apparatus, server, and storage medium to solve the problem of low efficiency in microservice invocation in the prior art.

[0006] Firstly, this application provides a microservice invocation method, including:

[0007] In response to receiving configuration information sent by each microservice, a corresponding database is configured according to the configuration information of each microservice, and the corresponding database is sent to each microservice; the database includes at least one of a transaction configuration database, a global addressing view database, and a consumer transaction code database, and the consumer transaction code database includes a list of consumer transaction codes for each microservice;

[0008] In response to receiving a microservice call request, the system determines the call information corresponding to the microservice call request; wherein the call information includes a first microservice identifier, a second microservice identifier, and a first transaction code; the first microservice identifier is used to indicate a first microservice, and the second microservice identifier is used to indicate a second microservice.

[0009] If the first transaction code exists in the global addressing view database and the first transaction code exists in the consumption transaction code list of the first microservice, the target publishing environment identifier corresponding to the first transaction code is obtained from the global addressing view database.

[0010] From the transaction configuration database, obtain the registration component information corresponding to the target publishing environment identifier, and based on the registration component information, address the target service instance corresponding to the first transaction code in the second microservice so as to process the microservice call request through the target service instance;

[0011] The processing result of the target service instance sent by the second microservice is received and sent to the first microservice.

[0012] In one possible design, the global addressing view database includes global addressing view data for each of the microservices, and the global addressing view data for each microservice includes at least one pending service transaction code; the consumption transaction code list includes at least one pending consumption transaction code; wherein, the pending service transaction code is used to indicate the transaction code for providing services, and the pending consumption transaction code is used to indicate the transaction code for invoking services;

[0013] When the first transaction code exists in both the global addressing view database and the first microservice's consumer transaction code list, retrieving the target publishing environment identifier corresponding to the first transaction code from the global addressing view database includes:

[0014] Match the first transaction code among multiple pending transaction codes in the consumption transaction code list of the first microservice;

[0015] When there is a pending transaction code that matches the first transaction code in the consumption transaction code list of the first microservice, the first transaction code is matched in at least one pending transaction code of the second microservice in the global addressing view database;

[0016] When at least one pending transaction code of the second microservice in the global addressing view database contains a pending transaction code that matches the first transaction code, the target publication identifier corresponding to the first transaction code is obtained from the global addressing view database.

[0017] In one possible design, the global addressing view database further includes a microservice identifier for each of the microservices, and a publishing environment identifier corresponding one-to-one with each pending transaction code; the transaction configuration database includes transaction configuration data for each of the microservices, the transaction configuration data including the microservice identifier of the microservice, multiple transaction codes of the microservice, and at least one resource environment information of the microservice; each piece of resource environment information includes an environment identifier, the name of the registered component corresponding to the environment identifier, and the cluster address of the registered component; the multiple transaction codes of the microservice include each pending transaction code of the microservice;

[0018] When, within the global addressing view database, at least one pending transaction code of the second microservice contains a pending transaction code that matches the first transaction code, retrieving the target publication identifier corresponding to the first transaction code from the global addressing view database includes:

[0019] In the global addressing view database, when at least one pending transaction code of the second microservice contains a pending transaction code that matches the first transaction code, the pending transaction code that matches the first transaction code is determined as the target pending transaction code;

[0020] From the global addressing view database, obtain the publishing environment identifier corresponding to the target pending transaction code, and use it as the target publishing identifier corresponding to the first transaction code.

[0021] In one possible design, the transaction configuration database includes at least one resource environment information for each of the microservices, and each resource environment information includes an environment identifier, the name of the registered component corresponding to the environment identifier, and the cluster address of the registered component;

[0022] The step of retrieving registration component information corresponding to the target publishing environment identifier from the transaction configuration database, and addressing the target service instance corresponding to the first transaction code in the second microservice based on the registration component information, so as to process the microservice call request through the target service instance, includes:

[0023] In the transaction configuration database, find the environment identifier that matches the target publishing environment identifier and use it as the target environment identifier;

[0024] In the transaction configuration database, the name and cluster address of the registered component corresponding to the target environment identifier are determined as the registered component information corresponding to the target publishing environment identifier, wherein the registered component information includes the name and cluster address of the registered component;

[0025] The registration component corresponding to the name and cluster address of the registration component is identified as the target registration component. In the target registration component, each service instance corresponding to the second microservice is determined based on the second microservice identifier. The target registration component stores multiple service instances registered by each microservice.

[0026] From each service instance of the second microservice in the target registration component, at least one healthy service instance corresponding to the first transaction code is determined, and a microservice call request is sent to each of the healthy service instances; the healthy service instance is used to indicate a service instance with the ability to process call requests.

[0027] In response to receiving feedback information from the health service instance, the system determines the health service instance corresponding to the feedback information as the target service instance, and sends a processing instruction to the target service instance. The processing instruction is used to control the target service instance to process the microservice call request; wherein, the feedback information is used to indicate that the service instance is in an idle state.

[0028] In one possible design, after responding to a microservice call request and determining the call information corresponding to the microservice call request, the method further includes:

[0029] If there is no pending transaction code matching the first transaction code in the global addressing view database, and / or if there is no pending call transaction code matching the first transaction code in the consumption transaction code list of the first microservice, a call failure message is generated;

[0030] Send the call failure information to the first microservice; the call failure information is used to indicate to the first microservice that the microservice call request was not successfully invoked.

[0031] In one possible design, the configuration information includes at least one of transaction configuration data, global addressing view data, and consumer transaction code data;

[0032] Correspondingly, the step of responding to receiving configuration information sent by each microservice, configuring the corresponding database according to the configuration information of each microservice, and sending the corresponding database to each microservice includes:

[0033] In response to receiving configuration information sent by each of the microservices, the transaction configuration database is constructed based on the transaction configuration data in the configuration information of each microservice;

[0034] The global addressing view database is constructed based on the global addressing view data in the configuration information of each microservice;

[0035] Based on the consumption transaction code data in the configuration information of each microservice, a consumption transaction code list corresponding to each microservice is constructed; wherein, the consumption transaction code data includes multiple transaction codes of at least one microservice;

[0036] The transaction configuration database and the global addressing view database are sent to each of the microservices, and a list of consumption transaction codes corresponding to each microservice is sent to each of the microservices respectively.

[0037] In one possible design, the step of determining the call information corresponding to the microservice call request in response to receiving the microservice call request includes:

[0038] In response to receiving the microservice call request, the microservice call request is parsed to obtain the first microservice carried in the microservice call request, and the first microservice corresponding to the first microservice identifier is determined.

[0039] The second microservice identifier and the first transaction code carried in the microservice call request are obtained, and the second microservice corresponding to the second microservice identifier is determined.

[0040] Secondly, this application provides a microservice invocation device, comprising:

[0041] The database configuration module is used to respond to receiving configuration information sent by each microservice, configure the corresponding database according to the configuration information of each microservice, and send the corresponding database to each microservice; the database includes at least one of a transaction configuration database, a global addressing view database, and a consumer transaction code database, and the consumer transaction code database includes a list of consumer transaction codes for each microservice;

[0042] The call information determination module is used to determine the call information corresponding to the microservice call request in response to receiving the microservice call request; wherein, the call information includes a first microservice identifier, a second microservice identifier, and a first transaction code; the first microservice identifier is used to indicate a first microservice, and the second microservice identifier is used to indicate a second microservice;

[0043] The environment identifier acquisition module is used to acquire the target publishing environment identifier corresponding to the first transaction code from the global addressing view database when the first transaction code exists in the global addressing view database and the first transaction code exists in the consumption transaction code list of the first microservice.

[0044] The request processing module is used to obtain the registration component information corresponding to the target publishing environment identifier from the transaction configuration database, and based on the registration component information, to address the target service instance corresponding to the first transaction code in the second microservice, so as to process the microservice call request through the target service instance;

[0045] The sending module is used to receive the processing result of the target service instance sent by the second microservice and send it to the first microservice.

[0046] Thirdly, embodiments of this application provide a server, including: at least one processor and a memory; the memory stores computer-executable instructions; the at least one processor executes the computer-executable instructions stored in the memory, causing the at least one processor to execute the microservice invocation method as described in the first aspect and various possible designs of the first aspect.

[0047] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions. When a processor executes the computer-executable instructions, it implements the microservice invocation method described in the first aspect and various possible designs of the first aspect.

[0048] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the microservice invocation method described in the first aspect and various possible designs of the first aspect.

[0049] The microservice invocation method, apparatus, server, and storage medium provided in this application configure at least one database from the following sources based on the configuration information received from each microservice: a transaction configuration database, a global addressing view database, and a consumer transaction code list for each microservice. Upon receiving a microservice invocation request, the application determines the invocation information, including the first microservice, the second microservice, and the first transaction code. If the first transaction code exists in both the global addressing view database and the first microservice's consumer transaction code list, the application retrieves the target publishing environment identifier corresponding to the first transaction code from the global addressing view database. It then retrieves the registration component information corresponding to the target publishing environment identifier from the transaction configuration database, and addresses the target service instance corresponding to the first transaction code in the second microservice based on this registration component information, processing the microservice invocation request based on the target service instance. Finally, the application receives the processing result of the target service instance from the second microservice and sends it to the first microservice. In this way, the resource environment of the provider's microservice can be quickly located based on the target release environment identifier, and the corresponding target service instance can be quickly found from the provider's microservice based on the transaction code. Microservice call requests can be processed in a timely manner through the target service instance, thereby improving the calling efficiency and processing efficiency of microservice call requests. Attached Figure Description

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

[0051] Figure 1 A diagram illustrating application scenarios for existing microservice invocation methods;

[0052] Figure 2 This is an architecture diagram of the microservice invocation system provided in the embodiments of this application;

[0053] Figure 3 The flow of the microservice invocation method provided in the embodiments of this application Figure 1 ;

[0054] Figure 4 The flow of the microservice invocation method provided in the embodiments of this application Figure 2 ;

[0055] Figure 5 The flow of the microservice invocation method provided in the embodiments of this application Figure 3 ;

[0056] Figure 6 This is a schematic diagram illustrating an application scenario of the microservice invocation method provided in the embodiments of this application;

[0057] Figure 7The flow of the microservice invocation method provided in the embodiments of this application Figure 4 ;

[0058] Figure 8 The flow of the microservice invocation method provided in the embodiments of this application Figure 5 ;

[0059] Figure 9 This is a schematic diagram of the structure of the microservice invocation device provided in the embodiments of this application;

[0060] Figure 10 This is a schematic diagram of the server structure provided in an embodiment of this application.

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

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

[0063] The collection, storage, use, processing, transmission, provision, and disclosure of financial data or user data involved in the technical solution of this application all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0064] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0065] Terminology Explanation:

[0066] Microservices are applications composed of multiple smaller, loosely coupled services. Microservices are characterized by loose coupling.

[0067] A service identifier is used to uniquely identify a microservice. Each microservice has multiple services, and each service includes a unique transaction code. Each microservice may include multiple resource environments, and each resource environment includes a set of resource environment information.

[0068] Service instances are used to provide services, and each service can include multiple service instances.

[0069] A transaction code is used to uniquely identify a service. For example, the transaction code for deleting an order is JY001, and the transaction code for adding an order is JY002.

[0070] Resource environment information is used to indicate information related to the resource environment in which the microservice is deployed. A set of resource environment information includes, but is not limited to, an environment identifier, the name of the registered component, and the cluster address of the registered component.

[0071] Among them, environmental labels are used to indicate the unique identity of resources and the environment;

[0072] The registration component is used to store one or more service instances in the resource environment;

[0073] The cluster address is used to indicate the cluster domain name of the registered component, including the IP address and port of the registered component.

[0074] Recently, the total transaction volume across various industries has shown a steady upward trend, and the types of transactions are becoming increasingly diverse, such as in the financial and apparel industries. Traditional monolithic architecture service systems can no longer meet the transaction needs of these industries, leading to a gradual shift towards distributed architecture systems. Based on the growth in transaction volume and types, the number of services, components, and machines in distributed systems is also increasing, making the call relationships within distributed systems increasingly complex. Due to the loose coupling between services in microservices, which offer advantages such as independent deployment, easy code updates, and flexible configuration, microservices are suitable for environments with numerous services, complex call relationships, and diverse runtime frameworks, such as distributed systems. Various types of services can be implemented by calling microservices. Existing methods for calling microservices primarily employ the concept of consumer services and provider services, using annotation injection to provide the call interface service.

[0075] Figure 1 An exemplary diagram illustrating an application scenario of a microservice invocation method in the prior art is provided.

[0076] See Figure 1 The existing methods for calling microservices mainly involve consumer microservices (such as...) Figure 1 The microservice A shown in the diagram provides a microservice to the provider (such as...). Figure 1 Microservice B shown in the diagram sends a microservice call request (such as...) Figure 1 (As shown by the dashed arrow in the image), to find the corresponding target service from multiple interfaces of the provider's microservice.

[0077] However, due to the large number of services and corresponding interfaces in microservices, as well as the complexity of the cluster environment, the above-mentioned calling methods between microservices cannot accurately address the microservice cluster environment or call the wrong microservice, thus failing to achieve microservice calls and resulting in low calling efficiency for microservices.

[0078] To address the aforementioned issues, this application provides a microservice invocation method applied in a server. The method includes: in response to receiving configuration information sent by each microservice, configuring at least one database from a transaction configuration database, a global addressing view database, and a consumer transaction code list for each microservice based on the configuration information of each microservice. In response to receiving a microservice invocation request, determining the invocation information corresponding to the microservice invocation request, such as a first microservice, a second microservice, and a first transaction code. If the first transaction code exists in both the global addressing view database and the first microservice's consumer transaction code list, obtaining a target publishing environment identifier corresponding to the first transaction code from the global addressing view database. Obtaining registration component information corresponding to the target publishing environment identifier from the transaction configuration database, addressing the target service instance corresponding to the first transaction code in the second microservice based on the registration component information, and processing the microservice invocation request based on the target service instance. Receiving the processing result of the target service instance from the second microservice and sending it to the first microservice. In this way, the resource environment of the provider's microservice can be quickly located based on the target release environment identifier, and the corresponding target service instance can be quickly found from the provider's microservice based on the transaction code. Microservice call requests can be processed in a timely manner through the target service instance, thereby improving the calling efficiency and processing efficiency of microservice call requests.

[0079] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0080] Figure 2 This is an architecture diagram of a microservice invocation system applicable to embodiments of this application.

[0081] like Figure 2 As shown, the microservice invocation system includes: microservice 1, microservice 2, and server 3. Microservice 1 deploys an integration agent A1, and microservice 2 deploys an integration agent A2. Each microservice's integration agent communicates with server 3. Each microservice has multiple resource environments, and each resource environment has a unique corresponding registration component. Figure 1Only one resource environment and its corresponding registration component are shown. Each microservice includes multiple services ( Figure 1 Only 5 services are shown in each microservice. Figure 1 (Services are represented by solid dots in the code). Multiple services within each microservice are registered in the registration component.

[0082] Server 3 includes data delivery component 4 and database 5 (data Server).

[0083] Database 5 is used to store at least one of the following: transaction configuration database 5, global addressing view database 5, and consumer transaction code database 5. The consumer transaction code database 5 includes a list of consumer transaction codes for each microservice. Figure 1 The table only shows the consumer transaction code list LB1 for microservice 1 and the consumer transaction code list LB2 for microservice 2.

[0084] Among them, the data delivery component 4 is used to read various data (including but not limited to one or more of the following: consumer transaction code list data, transaction configuration data, and global addressing view data) from the server 3, and send the transaction configuration database 5 and the global addressing view database 5 to microservice 1 and microservice 2 respectively, send the consumer transaction code list LB1 of microservice 1 to microservice 1, and send the consumer transaction code list LB2 of microservice 2 to microservice 2.

[0085] In a scenario where microservice 1 calls microservice 2, microservice 1 is used to send microservice call requests to server 3 through integration proxy A1 (e.g., ...). Figure 1 (As indicated by the dashed curve arrow).

[0086] Server 3 is used to determine the corresponding Service 2 and the first transaction code based on the microservice call request. If the first transaction code exists in the global addressing view database and the first transaction code exists in the consumption transaction code list of microservice 1, server 3 obtains the registration component information corresponding to the first transaction code from the transaction configuration database 5, and addresses the target service instance corresponding to the first transaction code from the above registration component information through the integration proxy A2 of microservice 2.

[0087] Microservice 2 is used to process microservice call requests through the target service instance and to report the processing results of the target service instance to server 3 through integration proxy 2.

[0088] Server 3 is also used to receive the processing results of the target service instance from microservice 2, and send the aforementioned feedback results (such as...) to microservice 1. Figure 1 (As indicated by the solid line curve arrow).

[0089] based on Figure 2The microservice invocation system shown in this application embodiment also provides a microservice invocation method. Figure 3 A flowchart illustrating the microservice invocation method provided in this application embodiment. Figure 3 As shown, the microservice invocation method includes:

[0090] S101. In response to receiving configuration information sent by each microservice, configure a corresponding database according to the configuration information of each microservice, and send the corresponding database to each microservice; the database includes at least one of a transaction configuration database, a global addressing view database, and a consumer transaction code database, and the consumer transaction code database includes a list of consumer transaction codes for each microservice.

[0091] Specifically, in response to receiving configuration information from each microservice, a transaction configuration database is configured based on the transaction configuration data in the configuration information sent by each microservice. This database stores the transaction configuration data of each microservice. The transaction configuration data includes, but is not limited to, the microservice identifier, multiple transaction codes for the microservice, functional information for each transaction code, a transaction code address (e.g., URI path) corresponding to each transaction code, and at least one resource environment information for each microservice. For ease of explanation, the transaction configuration database can also be called a transaction code configuration model, and the global addressing view database can also be called a global addressing view model. The transaction configuration data of a microservice can also be called the metadata of the microservice.

[0092] As an example and not a limitation, each microservice may include an integration agent for receiving database requests, creating service instances, registering, sending microservice call requests, and / or receiving microservice call requests.

[0093] For example, the integration proxy for each microservice can generate multiple corresponding service instances based on the received database and register them in the registration component. Simultaneously, information such as the microservice identifier and the corresponding transaction code for each microservice is stored in the registration component to facilitate service instance addressing.

[0094] In some embodiments, each piece of resource environment information includes an environment identifier, the name of the registered component corresponding to the environment identifier, and the cluster address of the registered component.

[0095] Specifically, each microservice includes multiple resource environments. Each resource environment includes a unique environment identifier, the name of the registered component corresponding to that environment identifier, and the cluster address of that registered component. There is a one-to-one correspondence between registered components and resource environments.

[0096] Understandably, when a microservice involves multiple resource environments, directly addressing the service through the microservice identifier may fail to accurately locate the target service among numerous resource environments, resulting in low efficiency of microservice calls.

[0097] This embodiment provides information about each resource environment in the transaction configuration database, and in the global addressing view database, each transaction code corresponds to only one resource environment. This allows for the rapid matching of resource environments that can provide service instances based on transaction codes, thereby quickly finding the target service instance corresponding to the first transaction code from the cluster environment of that resource environment.

[0098] For example, if the target service type carried in the microservice call request is "delete order", then the target service instance that can provide the "delete order" service can be quickly found in the resource environment corresponding to the transaction code of the "delete order" service instance.

[0099] Specifically, a global addressing view database is configured based on the global addressing view data in the configuration information sent by each microservice. The global addressing view database is used to store the global addressing view data of each microservice.

[0100] Specifically, based on the consumption transaction code data in the configuration information sent by each microservice, a consumption transaction code list corresponding to each microservice is configured, resulting in a consumption transaction code database. This database stores the consumption transaction code list for each microservice. The transaction configuration database, the global addressing view database, and the consumption transaction code list corresponding to each microservice are then sent to each microservice.

[0101] In some embodiments, the publishing environment identifier in the global addressing view data can be updated.

[0102] As an example, and not a limitation, when there are anomalies in the resource environment, the publishing environment identifier in the global addressing view data sent by the microservice can be updated, allowing for changes to the corresponding registered component name and cluster address. This allows for changing the cluster environment used by the consumer to address service instances.

[0103] As an example, and not a limitation, when two microservices share the same resource environment, the provider microservice can provide in the global addressing view data an environment identifier that is the same resource environment as the service instance that the consumer service is intervening in, serving as the publishing environment identifier. This way, the consumer service does not need to access across regions; it can directly address the target service instance from the same resource environment, reducing addressing time and improving the efficiency of microservice calls.

[0104] In some embodiments, the global addressing view database includes global addressing view data for each of the microservices, and the global addressing view data for each microservice includes at least one pending service transaction code; the consumption transaction code list includes at least one pending consumption transaction code; wherein, the pending service transaction code is used to indicate the transaction code for providing services, and the pending consumption transaction code is used to indicate the transaction code for invoking services.

[0105] Specifically, the global addressing view data for each microservice includes at least one pending transaction code for that microservice. The at least one pending transaction code for a microservice includes a transaction code selected from all transaction codes of that microservice that provides services to other microservices besides that microservice.

[0106] Specifically, the consumer transaction code list includes at least one transaction code to be consumed. The transaction code to be consumed in the consumer transaction code list is the transaction code of the service that the microservice needs to call.

[0107] In some embodiments, a microservice can determine the corresponding callable transaction code based on the service callable transaction code in the global addressing view, which facilitates the quick addressing of the target service instance based on the global addressing view database and avoids calling the wrong microservice.

[0108] Specifically, the transaction codes to be consumed in the consumption transaction code list include: transaction codes of services to be called by the microservice corresponding to the consumption transaction code list, selected from the service codes to be called by other microservices besides the microservice corresponding to the consumption transaction code list.

[0109] For example, the transaction codes for microservice 2 include transaction code JYM007 for deleting an order, transaction code JYM008 for adding an order, and transaction code JYM009 for modifying order information. The pending service transaction codes include transaction code JYM007 for providing the deleting order service and transaction code JYM008 for providing the adding order service. The transaction codes for microservice 3 include transaction code JYM101 for telephone inquiry service and transaction code JYM102 for telephone communication service. The pending service transaction codes include transaction code JYM102 for providing telephone communication service. The pending service codes in microservice 1 include transaction codes for services to be invoked selected from the pending service transaction codes of microservice 2, including transaction code JYM007 for invoking the deleting order service and transaction code JYM008 for invoking the adding order service, and transaction codes for services to be invoked selected from the pending service transaction codes of microservice 3, including transaction code JYM102 for invoking the telephone communication service.

[0110] Specifically, the global addressing view data sent by each microservice includes multiple pending transaction codes for that microservice, and the global addressing data database built based on the global addressing view data of each microservice includes multiple pending transaction codes for each microservice.

[0111] As an example, and not a limitation, a data delivery component can be used to send the global addressing database to each microservice, enabling a global layout of pending service transaction codes for each microservice providing services. This allows each microservice to retrieve all pending service transaction codes from the global addressing database, thus determining the corresponding microservice call request in a given scenario.

[0112] In some embodiments, the global addressing view database further includes a microservice identifier for each microservice and a publishing environment identifier corresponding one-to-one with each pending transaction code; the transaction configuration database includes transaction configuration data for each microservice, the transaction configuration data including the microservice identifier of the microservice, multiple transaction codes of the microservice, and at least one resource environment information of the microservice; each piece of resource environment information includes an environment identifier, the name of the registered component corresponding to the environment identifier, and the cluster address of the registered component; the multiple transaction codes of the microservice include each pending transaction code of the microservice.

[0113] Specifically, the global addressing view data for each microservice also includes the microservice identifier and the publishing environment identifier that corresponds one-to-one with each pending transaction code in that microservice. Correspondingly, the global addressing view database also includes the microservice identifier for each microservice and an environment identifier corresponding to each pending transaction code in each microservice.

[0114] By using the microservice identifiers of each microservice in the global addressing view database, the multiple pending transaction codes in each microservice, and the publishing environment identifier corresponding to each pending transaction code, the microservice that matches the second microservice identifier carried in the microservice call request and the pending transaction code that matches the first transaction code can be matched in the global addressing view database, thereby quickly determining the publishing environment identifier corresponding to the first transaction code.

[0115] Specifically, the transaction configuration database includes transaction configuration data for each microservice. Each microservice's transaction configuration data includes its microservice identifier, multiple transaction codes within that microservice, and at least one resource environment information for that microservice. The corresponding transaction configuration database includes: the microservice identifier for each microservice, multiple transaction codes for each microservice, and at least one resource environment information for each microservice. Furthermore, each resource environment information includes, but is not limited to, an environment identifier, the name of the registered component corresponding to that environment identifier, and the cluster address of that registered component. The multiple transaction codes for each microservice include all pending transaction codes for that microservice; that is, each pending transaction code for a microservice is one or more transaction codes selected from its multiple transaction codes.

[0116] In this way, once the publishing environment identifier corresponding to the first transaction code is determined, the environment identifier matching the publishing environment identifier can be found in the transaction configuration database, thus identifying the unique resource environment information corresponding to the first transaction code. Furthermore, the name of the registered component and the cluster address of that registered component can be quickly determined within this resource environment information. This allows for the identification of a cluster address corresponding to the first transaction code, enabling rapid addressing service operations at that cluster address.

[0117] The execution subject of the method in this embodiment can be Figure 2 The server shown.

[0118] In some embodiments, step S101 includes:

[0119] In response to receiving configuration information sent by each of the microservices, the transaction configuration database is constructed based on the transaction configuration data in the configuration information of each microservice;

[0120] The global addressing view database is constructed based on the global addressing view data in the configuration information of each microservice;

[0121] Based on the consumption transaction code data in the configuration information of each microservice, a consumption transaction code list corresponding to each microservice is constructed; wherein, the consumption transaction code data includes multiple transaction codes of at least one microservice;

[0122] The transaction configuration database and the global addressing view database are sent to each of the microservices, and a list of consumption transaction codes corresponding to each microservice is sent to each of the microservices respectively.

[0123] Specifically, in response to receiving configuration information from each microservice, transaction configuration data for each microservice is extracted from the configuration information, and a transaction configuration database is constructed based on the transaction configuration data of each microservice. Global addressing view data for each microservice is also extracted from the configuration information, and a global addressing view database is constructed based on the global addressing view data of each microservice.

[0124] Specifically, the corresponding consumption transaction code data is extracted from the configuration information of each microservice. Based on the consumption transaction code data of each microservice, a consumption transaction code list corresponding to each microservice is constructed. The consumption transaction code data of each microservice includes multiple transaction codes to be invoked for that microservice. The transaction configuration database and the global addressing view database are sent to each microservice, and the consumption transaction code list corresponding to that microservice is also sent to each microservice.

[0125] S102. In response to receiving a microservice call request, determine the call information corresponding to the microservice call request; wherein, the call information includes a first microservice identifier, a second microservice identifier, and a first transaction code; the first microservice identifier is used to indicate a first microservice, and the second microservice identifier is used to indicate a second microservice.

[0126] Specifically, in response to receiving a microservice call request, the process parses the request to obtain corresponding call information, which includes a first microservice identifier, a second microservice identifier, and a first transaction code. The first microservice identifier indicates the first microservice, which in turn indicates the consumer microservice. That is, the first microservice that sent the call request can be identified based on the first microservice identifier. The second microservice identifier indicates the second microservice, which in turn indicates the provider microservice. That is, the target microservice to be called by the first microservice, i.e., the second microservice, can be identified based on the second microservice identifier. The first transaction code is used to indicate the unique identifier of the target service to be called by the first microservice.

[0127] In some embodiments, step S102 includes:

[0128] In response to receiving the microservice call request, the microservice call request is parsed to obtain the first microservice carried in the microservice call request, and the first microservice corresponding to the first microservice identifier is determined.

[0129] The second microservice identifier and the first transaction code carried in the microservice call request are obtained, and the second microservice corresponding to the second microservice identifier is determined.

[0130] Specifically, in response to receiving a microservice call request, the process parses the microservice call request, determines the first microservice identifier carried in the microservice call request, and thus identifies the first microservice that sent the microservice call request. Simultaneously, it determines the second microservice identifier and the first transaction code carried in the microservice call request, thereby identifying the unique identifier of the target service and the second microservice to be called.

[0131] S103. If the first transaction code exists in the global addressing view database and the first transaction code exists in the consumption transaction code list of the first microservice, obtain the target publishing environment identifier corresponding to the first transaction code from the global addressing view database.

[0132] Specifically, if a matching transaction code exists among multiple pending transaction codes in the global addressing view database, it is determined that the first transaction code has been globally published. Furthermore, if a matching transaction code exists among multiple pending call transaction codes in the first microservice's consumer transaction code list, it is determined that a call relationship exists between the first microservice and the service corresponding to the first transaction code. Within the global addressing map database, based on the pending transaction code in the second microservice that matches the first transaction code, the publishing environment identifier corresponding to the first transaction code is obtained.

[0133] S104. Obtain the registration component information corresponding to the target publishing environment identifier from the transaction configuration database, and address the target service instance corresponding to the first transaction code in the second microservice based on the registration component information, so as to process the microservice call request through the target service instance.

[0134] Specifically, within the environment resource information of the second microservice in the transaction configuration database, an environment identifier matching the published environment identifier is determined. The name and cluster address of the registered component corresponding to the environment identifier matching the published environment identifier are then obtained as the registered component information corresponding to the published environment identifier. Based on the registered component information, the target service instance corresponding to the first transaction code is located among multiple service instances of the second microservice. A microservice call request is sent to the target service instance of the second microservice, and the microservice call request is processed based on the target service instance of the second microservice.

[0135] It's important to note that there's a one-to-one correspondence between the registration component and the resource environment (specifically, the environment identifier of the resource environment). The registration component stores multiple service instances registered by one or more microservices. Each microservice can be implemented through one or more service instances. Each service corresponds to a different service instance.

[0136] For example, microservice 2 includes three services, with transaction codes as follows: JYM007 for deleting an order, JYM008 for adding an order, and JYM009 for modifying order information. The health service instances of microservice 2 include SL001, SL002, SL003, SL005, SL006, SL008, and SL009. Specifically, health service instances SL001, SL002, and SL003 can be used to provide the order deletion service, corresponding to transaction code JYM007; health service instances SL005 and SL006 are used to provide the order addition service, corresponding to transaction code JYM008; and health service instances SL008 and SL009 are used to provide the order modification service, corresponding to transaction code JYM009. Correspondingly, when the first transaction code is JYM009, the health service instances SL008 and SL009 corresponding to the transaction code JYM009 can be found among all health service instances of microservice 2 in the target registration component.

[0137] S105. Receive the processing result of the target service instance sent by the second microservice and send it to the first microservice.

[0138] Specifically, it receives the processing result of the target service instance sent by the second microservice and sends the processing result back to the first microservice.

[0139] Figure 4 This is a flowchart of step S103 of the microservice invocation method provided in an embodiment of this application. Figure 4 As shown, step S103 of the microservice invocation method includes the following steps:

[0140] S1031. Match the first transaction code among multiple pending transaction codes in the consumption transaction code list of the first microservice.

[0141] Specifically, each of the multiple pending transaction codes in the consumption transaction code list of the first microservice is matched with the first transaction code.

[0142] S1032. When there is a pending transaction code that matches the first transaction code in the consumption transaction code list of the first microservice, the first transaction code is matched in at least one pending transaction code of the second microservice in the global addressing view database.

[0143] Specifically, when a pending transaction code matching the first transaction code exists in the consumer transaction code list of the first microservice, it is determined that a call relationship exists between the first microservice and the second microservice: the first microservice calls the service corresponding to the first transaction code. Each pending transaction code in the global addressing view database is then matched against the first transaction code.

[0144] S1033. When at least one pending transaction code of the second microservice in the global addressing view database contains a pending transaction code that matches the first transaction code, the target publication identifier corresponding to the first transaction code is obtained from the global addressing view database.

[0145] Specifically, when a pending transaction code matching the first transaction code exists in the global addressing view database, it is determined that the first transaction code is globally published. In the global addressing view database, the publishing environment identifier corresponding to the pending transaction code matching the first transaction code is used as the publishing environment identifier corresponding to the first transaction code.

[0146] Figure 5 This is a flowchart of step S1033 of the microservice invocation method provided in an embodiment of this application. Figure 5 As shown, step S1032 of the microservice invocation method includes the following steps:

[0147] S10321. In the global addressing view database, when at least one pending transaction code of the second microservice contains a pending transaction code that matches the first transaction code, the pending transaction code that matches the first transaction code is determined as the target pending transaction code.

[0148] Specifically, in the global addressing view database, when there is a pending transaction code that matches the first transaction code, the pending transaction code that matches the first transaction code is identified as the target pending transaction code.

[0149] S10322. Obtain the publishing environment identifier corresponding to the target pending transaction code from the global addressing view database, and use it as the target publishing identifier corresponding to the first transaction code.

[0150] Specifically, in the global addressing view database, the publishing environment identifier corresponding to the target pending transaction code is searched, and this publishing environment identifier corresponding to the target pending transaction code is used as the publishing environment identifier corresponding to the first transaction code.

[0151] It is understood that the above embodiment is illustrated by first searching for a matching transaction code to be invoked in the consumer transaction code list of the first microservice, and then searching for a matching transaction code to be serviced in the global addressing view database. In practical applications, the order of the above two steps is not unique. For example, one could first search for a matching transaction code to be serviced in the global addressing view database, and then search for a matching transaction code to be invoked in the consumer transaction code list of the first microservice. Alternatively, one could simultaneously search for a matching transaction code to be serviced in the global addressing view database and search for a matching transaction code to be invoked in the consumer transaction code list of the first microservice.

[0152] Figure 6 An exemplary application scenario diagram of a microservice invocation method applicable to embodiments of this application is provided.

[0153] Figure 6 The consumer transaction code database stores a consumer transaction code list 1 for microservice 1 and a consumer transaction code list 2 for microservice 2. Consumer transaction code list 1 stores multiple pending transaction codes that have a call relationship with microservice 1, namely pending transaction code 1 and pending transaction code 2. Consumer transaction code list 2 stores multiple pending transaction codes that have a call relationship with microservice 2, namely pending transaction code 3 and pending transaction code 4. The global addressing view database stores global addressing view data for microservice 1, including the microservice identifier 1, pending transaction code 3 in microservice 1, and a unique publishing environment identifier 5. The global addressing view database also stores global addressing view data for microservice 2, including the microservice identifier 2, pending transaction code 1 in microservice 2, and a unique publishing environment identifier 1.

[0154] The transaction configuration database stores the transaction codes of multiple services in microservice 1, and the transaction code address of each transaction code ( Figure 6 Only two services are shown, namely service X and service Q, and the corresponding transaction codes are only shown as transaction code 3, transaction code address 3, transaction code 4, and transaction code address 5. Multiple resource environments are shown for each service. Figure 6 Only three resource environment information entries for microservice 1 are shown: resource environment information 4, resource environment information 5, and resource environment information 6. Specifically, the service instances corresponding to transaction code 1 are registered in resource environment 1, the service instances corresponding to transaction code 2 are registered in resource environment 3, the service instances corresponding to transaction code 3 are registered in resource environment 4, and the service instances corresponding to transaction code 4 are registered in resource environment 5.

[0155] The transaction configuration database also stores the transaction codes of multiple services in Microservice 2, and the transaction code address of each transaction code ( Figure 6 Only two services are shown, namely service Z and service Y, and the corresponding transaction codes are shown only as transaction code 1, transaction code address 1, transaction code 2, and transaction code address 2. Multiple resource environments are shown for each service. Figure 6 Only three resource environment information entries from microservice 2 are shown: resource environment information 1, resource environment information 2, and resource environment information 3. Each resource environment information entry includes its environment identifier, registered component name, and registered component cluster address.

[0156] The microservice call request includes a first microservice identifier (microservice identifier 1), a second microservice identifier (microservice identifier 2), and a first transaction code (transaction code 1). It can be determined that microservice 1 calls the service corresponding to transaction code 2 in microservice 2 through the microservice call request.

[0157] If the pending transaction code 1 in the consumer transaction code list 1 of microservice 1 matches the first transaction code (and transaction code 1), and the pending transaction code 1 in microservice 2 in the global addressing view database matches the first transaction code, then based on the publishing environment identifier 1 corresponding to the pending transaction code 1 in the global addressing view database, the environment identifier 1 associated with transaction code 1 is matched in microservice 2. Based on this, the registered component name and cluster address corresponding to environment identifier 1 can be used to identify multiple healthy service instances within service 2 in microservice 2. Figure 6 The image shows only four health service instances of service 2, represented by hollow dots. The corresponding target service instance was found within this image. Figure 6 (Represented by dashed hollow circles).

[0158] Figure 7 This is the second flowchart of a microservice invocation method provided in an embodiment of this application. Figure 7 As shown, after step S102, the microservice invocation method further includes the following steps:

[0159] S201. When there is no pending service transaction code matching the first transaction code in the global addressing view database, and / or when there is no pending call transaction code matching the first transaction code in the consumption transaction code list of the first microservice, a call failure message is generated.

[0160] Specifically, if any one or more of the following conditions are met: there is no pending service transaction code matching the first transaction code in the global addressing view database, or there is no pending call transaction code matching the first transaction code in the consumption transaction code list of the first microservice, then it is determined that there is at least one of the following situations: the first transaction code has not been globally published, or there is no "call relationship between the first microservice and the second microservice" where the first microservice calls the service corresponding to the first transaction code.

[0161] S202. Send the call failure information to the first microservice; the call failure information is used to indicate to the first microservice that the microservice call request was not successfully invoked.

[0162] Specifically, in the above scenario, the first microservice cannot call the second microservice's first transaction code-related service. A call failure message is generated and sent to the first microservice. This message indicates to the first microservice that its microservice call request to the second microservice's first transaction code-related service failed.

[0163] Figure 8 This is a flowchart of step S104 of the microservice invocation method provided in an embodiment of this application. Figure 8 As shown, step S104 of the microservice invocation method further includes the following steps:

[0164] S1041. In the transaction configuration database, find the environment identifier that matches the target publishing environment identifier and use it as the target environment identifier;

[0165] S1042. In the transaction configuration database, determine the name and cluster address of the registered component corresponding to the target environment identifier, as the registered component information corresponding to the target publishing environment identifier, wherein the registered component information includes the name and cluster address of the registered component;

[0166] Specifically, based on the second microservice identifier, the system searches for an environment identifier matching the target deployment environment within the second microservice of the transaction configuration database. Furthermore, it searches the transaction configuration database for the registered component name and cluster address corresponding to the environment identifier matching the target deployment environment identifier, using these as the name and cluster address of the registered component corresponding to the target deployment environment identifier. For clarity, the cluster address of the registered component corresponding to the target deployment environment identifier can also be referred to as the registered component information.

[0167] For example, the registration component can be Nacos.

[0168] S1043. Determine the registration component corresponding to the name and cluster address of the registration component as the target registration component. In the target registration component, determine each service instance corresponding to the second microservice based on the second microservice identifier. The target registration component stores multiple service instances registered by each microservice.

[0169] S1044. From each service instance of the second microservice in the target registration component, determine at least one healthy service instance corresponding to the first transaction code, and send a microservice call request to each of the healthy service instances; the healthy service instance is used to indicate a service instance with the ability to process call requests.

[0170] Specifically, the corresponding registration component is determined based on the name and cluster address of the registered component, and this component serves as the target registration component. The target registration component stores multiple service instances registered by each microservice. Therefore, each service instance corresponding to the second microservice can be identified based on the second microservice identifier.

[0171] Specifically, at least one healthy service instance corresponding to the first transaction code is identified from the multiple service instances registered by the second microservice stored in the aforementioned registration component, and a microservice call request is sent to each healthy service instance. The healthy service instance indicates a service instance capable of processing call requests.

[0172] As an example, and not a limitation, each microservice can monitor the status of each service instance. If it detects that one or more service instances lack the ability to handle call requests, and determines that these unhealthy service instances are in an unhealthy state, the microservice can deregister the unhealthy service instances. It will then send a transaction code deregistration request to the transaction configuration database and the global addressing view database. The server can then deregister the request transaction code against the transaction code corresponding to the service instance. This prevents microservice calls from resulting in calls to unhealthy service instances.

[0173] As a capability rather than a limitation, in microservices, multiple services work in a round-robin fashion. At any given time, some services may be active while others are idle. The server may not know the running status of each service instance, therefore, it needs to send microservice call requests to each healthy service instance.

[0174] S1045. In response to receiving feedback information from the health service instance, determine the health service instance corresponding to the feedback information as the target service instance, and send a processing instruction to the target service instance. The processing instruction is used to control the target service instance to process the microservice call request; wherein, the feedback information is used to indicate that the service instance is in an idle state.

[0175] Specifically, in response to receiving feedback information from a healthy service instance, indicating that the service instance is in an idle state, the system determines that the service instance has the capability and time to process microservice call requests, and identifies the service instance as the target service instance. A processing instruction is then sent to the target service instance to control it to process the microservice call request.

[0176] Understandably, in a microservices environment with multiple services polling, multiple service instances may be idle at any given time. These idle instances receive instructions or requests sequentially according to the polling order. Therefore, the first service instance to receive a microservice call request will directly provide feedback, allowing the target service instance to be identified directly from this feedback.

[0177] Figure 9 This is a schematic diagram of the microservice invocation device provided in an embodiment of this application. Figure 9 As shown, the microservice invocation device includes:

[0178] The database configuration module 901 is used to respond to receiving configuration information sent by each microservice, configure the corresponding database according to the configuration information of each microservice, and send the corresponding database to each microservice; the database includes at least one of a transaction configuration database, a global addressing view database, and a consumer transaction code database, and the consumer transaction code database includes a list of consumer transaction codes for each microservice;

[0179] The call information determination module 902 is used to determine the call information corresponding to the microservice call request in response to receiving the microservice call request; wherein, the call information includes a first microservice identifier, a second microservice identifier, and a first transaction code; the first microservice identifier is used to indicate a first microservice, and the second microservice identifier is used to indicate a second microservice;

[0180] The environment identifier acquisition module 903 is used to acquire the target publishing environment identifier corresponding to the first transaction code from the global addressing view database when the first transaction code exists in the global addressing view database and the first transaction code exists in the consumption transaction code list of the first microservice.

[0181] The request processing module 904 is used to obtain the registration component information corresponding to the target publishing environment identifier from the transaction configuration database, and to locate the target service instance corresponding to the first transaction code in the second microservice based on the registration component information, so as to process the microservice call request through the target service instance;

[0182] The sending module 905 is used to receive the processing result of the target service instance sent by the second microservice and send it to the first microservice.

[0183] In some embodiments, the global addressing view database includes global addressing view data for each of the microservices, and the global addressing view data for each microservice includes at least one pending service transaction code; the consumption transaction code list includes at least one pending consumption transaction code; wherein, the pending service transaction code is used to indicate the transaction code for providing services, and the pending consumption transaction code is used to indicate the transaction code for invoking services;

[0184] The environment identifier acquisition module includes:

[0185] The first matching unit is used to match the first transaction code among multiple transaction codes to be invoked in the consumption transaction code list of the first microservice;

[0186] The second matching unit is used to match the first transaction code in at least one pending transaction code of the second microservice within the global addressing view database when there is a pending transaction code in the consumption transaction code list of the first microservice that matches the first transaction code.

[0187] The first acquisition unit is configured to acquire a target publication identifier corresponding to the first transaction code from the global addressing view database when at least one pending transaction code of the second microservice contains a pending transaction code that matches the first transaction code.

[0188] In some embodiments, the global addressing view database further includes a microservice identifier for each microservice and a publishing environment identifier corresponding to each pending transaction code; the transaction configuration database includes transaction configuration data for each microservice, the transaction configuration data including the microservice identifier, multiple transaction codes for the microservice, and at least one resource environment information for the microservice; each resource environment information includes an environment identifier, the name of the registered component corresponding to the environment identifier, and the cluster address of the registered component; the multiple transaction codes for the microservice include each pending transaction code for the microservice;

[0189] The first acquisition unit includes:

[0190] The first determining subunit is configured to determine the pending transaction code that matches the first transaction code as the target pending transaction code when there is a pending transaction code that matches the first transaction code in at least one pending transaction code of the second microservice in the global addressing view database.

[0191] The first acquisition subunit is used to acquire the publishing environment identifier corresponding to the target pending transaction code from the global addressing view database, and use it as the target publishing identifier corresponding to the first transaction code.

[0192] In some embodiments, the transaction configuration database includes at least one resource environment information for each of the microservices, and each resource environment information includes an environment identifier, the name of the registered component corresponding to the environment identifier, and the cluster address of the registered component;

[0193] The request processing module includes:

[0194] The environment identifier acquisition unit is used to search for an environment identifier that matches the target publishing environment identifier in the transaction configuration database, and use it as the target environment identifier.

[0195] The component information acquisition unit is used to determine the name and cluster address of the registered component corresponding to the target environment identifier in the transaction configuration database, as the registered component information corresponding to the target publishing environment identifier, wherein the registered component information includes the name and cluster address of the registered component;

[0196] A microservice determination unit is used to determine the registration component corresponding to the name and cluster address of the registration component as a target registration component. In the target registration component, each service instance corresponding to the second microservice is determined based on the second microservice identifier. The target registration component stores multiple service instances registered by each microservice.

[0197] The sending unit is configured to determine at least one healthy service instance corresponding to the first transaction code from each service instance of the second microservice in the target registration component, and send a microservice call request to each of the healthy service instances; the healthy service instance is used to indicate a service instance with the ability to process call requests.

[0198] The control unit is configured to, in response to receiving feedback information from the health service instance, determine the health service instance corresponding to the feedback information as the target service instance, and send a processing instruction to the target service instance, wherein the processing instruction is configured to control the target service instance to process the microservice call request; wherein the feedback information is configured to indicate that the service instance is in an idle state.

[0199] In some embodiments, the microservice invocation apparatus further includes:

[0200] The generation module is used to generate call failure information when there is no pending service transaction code matching the first transaction code in the global addressing view database, and / or when there is no pending call transaction code matching the first transaction code in the consumption transaction code list of the first microservice;

[0201] The prompting module is used to send the call failure information to the first microservice; the call failure information is used to prompt the first microservice that the microservice call request was not successfully invoked.

[0202] In some embodiments, the configuration information includes at least one of transaction configuration data, global addressing view data, and consumer transaction code data;

[0203] The database configuration module includes:

[0204] The first construction unit is configured to, in response to receiving configuration information sent by each of the microservices, construct the transaction configuration database based on the transaction configuration data in the configuration information of each microservice;

[0205] The second construction unit is used to construct the global addressing view database based on the global addressing view data in the configuration information of each microservice;

[0206] The third construction unit is used to construct a consumer transaction code list corresponding to each microservice based on the consumer transaction code data in the configuration information of each microservice; wherein, the consumer transaction code data includes multiple transaction codes of at least one microservice;

[0207] The second sending unit is used to send the transaction configuration database and the global addressing view database to each of the microservices, and to send a list of consumption transaction codes corresponding to each of the microservices to each of the microservices respectively.

[0208] In some embodiments, invoking the information determination module includes:

[0209] The parsing unit is configured to, in response to receiving the microservice call request, parse the microservice call request, obtain the first microservice carried in the microservice call request, and determine the first microservice corresponding to the first microservice identifier;

[0210] The microservice determination unit is used to obtain the second microservice identifier and the first transaction code carried in the microservice call request, and determine the second microservice corresponding to the second microservice identifier.

[0211] The microservice invocation device provided in this application embodiment can be used to execute the technical solution of the microservice invocation method in the above embodiment. Its implementation principle and technical effect are similar, and will not be described again here.

[0212] It should be noted that the division of the various modules in the above device is merely a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, these modules can be implemented entirely in software via processing element calls; they can be fully implemented in hardware; or some modules can be implemented by processing element calls to software, while others are implemented in hardware. For example, the request processing module 904 can be a separate processing element, or it can be integrated into a chip in the above device. Alternatively, it can be stored as program code in the memory of the above device, and its functions can be called and executed by a processing element of the device. The implementation of other modules is similar. Moreover, these modules can be fully or partially integrated together, or they can be implemented independently. The processing element here can be an integrated circuit with signal processing capabilities. In the implementation process, each step of the above method or each of the above modules can be completed through integrated logic circuits in the hardware of the processor element or through software instructions.

[0213] Figure 10 This is a schematic diagram of the server structure provided in an embodiment of this application. Figure 10 As shown, the server may include: transceiver 101, processor 102, and memory 103.

[0214] Processor 102 executes computer execution instructions stored in memory, causing processor 102 to perform the scheme in the above embodiments. Processor 102 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0215] The memory 103 is connected to the processor 102 via the system bus and completes communication between them. The memory 103 is used to store computer program instructions.

[0216] Transceiver 101 can be used to obtain the task to be run and its configuration information.

[0217] The system bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The system bus can be divided into address bus, data bus, control bus, etc. For ease of representation, only one thick line is used in the diagram, but this does not indicate that there is only one bus or one type of bus. Transceivers are used to enable communication between database access devices and other computers (e.g., clients, read-write libraries, and read-only libraries). Memory may include random access memory (RAM) and may also include non-volatile memory.

[0218] This application also provides a chip for executing instructions, which is used to execute the technical solution of the microservice calling method in the above embodiments.

[0219] This application also provides a computer-readable storage medium storing computer instructions that, when executed on a computer, cause the computer to perform the microservice invocation method described above.

[0220] This application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. At least one processor can read the computer program from the computer-readable storage medium, and when the at least one processor executes the computer program, it can implement the technical solution of the microservice invocation method in the above embodiments.

[0221] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or modules, and may be electrical, mechanical, or other forms.

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

[0223] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit. The unit composed of the above modules can be implemented in hardware or in the form of hardware plus software functional units.

[0224] The integrated modules described above, implemented as software functional modules, can be stored in a computer-readable storage medium. These software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods of the various embodiments of this application.

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

[0226] The memory may include high-speed RAM, and may also include non-volatile storage (NVM), such as at least one disk storage device, and may also be a USB flash drive, external hard drive, read-only memory, disk or optical disc, etc.

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

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

[0229] An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Alternatively, the storage medium can be an integral part of the processor. The processor and storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and storage medium can exist as discrete components within an electronic control unit or main control device.

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

[0231] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A microservice calling method, characterized in that, The method comprises: configuring a corresponding database according to the configuration information of each microservice in response to receiving the configuration information sent by each microservice, and sending the corresponding database to each microservice; the database comprises at least one of a transaction configuration database, a global addressing view database, and a consumption transaction code database, and the consumption transaction code database comprises a consumption transaction code list of each microservice; determining the corresponding call information of the microservice call request in response to receiving the microservice call request; wherein the call information comprises a first microservice identifier, a second microservice identifier, and a first transaction code; the first microservice identifier is used to indicate a first microservice, and the second microservice identifier is used to indicate a second microservice; in the case that the first transaction code exists in the global addressing view database and the first transaction code exists in the consumption transaction code list of the first microservice, obtaining a target publishing environment identifier corresponding to the first transaction code from the global addressing view database; obtaining registration component information corresponding to the target publishing environment identifier from the transaction configuration database, and addressing a target service instance corresponding to the first transaction code in the second microservice based on the registration component information, so as to process the microservice call request through the target service instance; receiving the processing result of the target service instance sent by the second microservice, and sending the processing result to the first microservice.

2. The method of claim 1, wherein, The global addressing view database comprises global addressing view data of each microservice, and the global addressing view data of each microservice comprises at least one to-be-served transaction code; the consumption transaction code list comprises at least one to-be-consumed transaction code; wherein the to-be-served transaction code is used to indicate a transaction code providing a service, and the to-be-consumed transaction code is used to indicate a transaction code to be called; In the case that the first transaction code exists in the global addressing view database and the first transaction code exists in the consumption transaction code list of the first microservice, obtaining a target publishing environment identifier corresponding to the first transaction code from the global addressing view database comprises: matching the first transaction code in a plurality of to-be-called transaction codes in the consumption transaction code list of the first microservice; when the to-be-called transaction code matched with the first transaction code exists in the consumption transaction code list of the first microservice, matching the first transaction code in at least one to-be-served transaction code of the second microservice in the global addressing view database; when the to-be-served transaction code matched with the first transaction code exists in at least one to-be-served transaction code of the second microservice in the global addressing view database, obtaining a target publishing identifier corresponding to the first transaction code from the global addressing view database.

3. The method according to claim 1 or 2, characterized in that, The global addressing view database further comprises microservice identifiers of the microservices, and a release environment identifier corresponding to each transaction code to be served; the transaction configuration database comprises transaction configuration data of the microservices, the transaction configuration data comprising microservice identifiers of the microservices, a plurality of transaction codes of the microservices, and at least one resource environment information of the microservices; each resource environment information comprises an environment identifier, a name of a registered component corresponding to the environment identifier, and a cluster address of the registered component; the plurality of transaction codes of the microservices comprises the transaction codes to be served of the microservices; When there is a transaction code to be served matching the first transaction code in the at least one transaction code to be served of the second microservice in the global addressing view database, the target release identifier corresponding to the first transaction code is acquired from the global addressing view database, comprising: When there is a transaction code to be served matching the first transaction code in the at least one transaction code to be served of the second microservice in the global addressing view database, the transaction code to be served matching the first transaction code is determined as a target transaction code to be served; The release environment identifier corresponding to the target transaction code to be served is acquired from the global addressing view database as the target release identifier corresponding to the first transaction code.

4. The method according to claim 1 or 2, characterized in that, The transaction configuration database comprises at least one resource environment information of the microservices, each resource environment information comprising an environment identifier, a name of a registered component corresponding to the environment identifier, and a cluster address of the registered component; The registered component information corresponding to the target release environment identifier is acquired from the transaction configuration database, and the target service instance corresponding to the first transaction code is addressed in the second microservice based on the registered component information, so as to process the microservice invocation request through the target service instance, comprising: An environment identifier matching the target release environment identifier is found in the transaction configuration database as a target environment identifier; The name and cluster address of the registered component corresponding to the target environment identifier are determined in the transaction configuration database as the registered component information corresponding to the target release environment identifier, wherein the registered component information comprises the name and cluster address of the registered component; The registered component corresponding to the name and cluster address of the registered component is determined as a target registered component, and each service instance corresponding to the second microservice is determined in the target registered component based on the second microservice identifier; wherein the target registered component stores a plurality of service instances registered by the microservices; At least one healthy service instance corresponding to the first transaction code is determined from each service instance of the second microservice in the target registered component, and a microservice invocation request is sent to each healthy service instance; the healthy service instance is used to indicate a service instance having the ability to process the invocation request. In response to receiving the feedback information of the health service instance, the health service instance corresponding to the feedback information is determined as a target service instance, and a processing instruction is sent to the target service instance, the processing instruction being used to control the target service instance to process the microservice calling request; wherein the feedback information is used to indicate that the service instance is in an idle state.

5. The method according to claim 1 or 2, characterized in that, The method further includes, after determining the calling information corresponding to the microservice calling request: When there is no to-be-served transaction code matching the first transaction code in the global addressing view database, and / or there is no to-be-called transaction code matching the first transaction code in the consumption transaction code list of the first microservice, generating calling failure information; Sending the calling failure information to the first microservice; the calling failure information is used to prompt the first microservice that the microservice calling request is not successfully called.

6. The method according to claim 1 or 2, characterized in that, The configuration information includes at least one of transaction configuration data, global addressing view data, and consumption transaction code data; Correspondingly, the method further includes: In response to receiving the configuration information sent by each microservice, constructing the transaction configuration database based on the transaction configuration data in the configuration information of each microservice; Constructing the global addressing view database based on the global addressing view data in the configuration information of each microservice; Constructing a consumption transaction code list corresponding to each microservice based on the consumption transaction code data in the configuration information of each microservice; wherein the consumption transaction code data includes multiple transaction codes of at least one microservice; Sending the transaction configuration database, the global addressing view database, and the consumption transaction code list corresponding to each microservice to each microservice.

7. The method according to claim 1 or 2, characterized in that, The method further includes: In response to receiving the microservice calling request, parsing the microservice calling request to obtain a first microservice carried by the microservice calling request, and determining a first microservice corresponding to the first microservice identifier; Obtaining a second microservice identifier and a first transaction code carried by the microservice calling request, and determining a second microservice corresponding to the second microservice identifier.

8. A microservice invocation apparatus, characterized by comprising: The method further includes: A database configuration module is configured to, in response to receiving the configuration information sent by each microservice, configure a corresponding database according to the configuration information of each microservice, and send the corresponding database to each microservice; the database includes at least one of a transaction configuration database, a global addressing view database, and a consumption transaction code database, and the consumption transaction code database includes a consumption transaction code list of each microservice. The calling information determination module is configured to determine calling information corresponding to the microservice calling request in response to receiving the microservice calling request, wherein the calling information comprises a first microservice identifier, a second microservice identifier, and a first transaction code; the first microservice identifier is used to indicate the first microservice, and the second microservice identifier is used to indicate the second microservice; The environment identifier acquisition module is configured to acquire, from the global addressing view database, a target publishing environment identifier corresponding to the first transaction code in a case where the first transaction code exists in the global addressing view database and the first transaction code exists in a consumption transaction code list of the first microservice. The request processing module is configured to acquire, from the transaction configuration database, registration component information corresponding to the target publishing environment identifier, address a target service instance corresponding to the first transaction code in the second microservice based on the registration component information, and process the microservice calling request through the target service instance. The sending module is configured to receive a processing result of the target service instance sent by the second microservice and send the processing result to the first microservice.

9. A server, characterized by The processor and a memory connected with the processor in communication; The memory stores computer execution instructions; The processor executes the computer execution instructions stored in the memory to implement the method in any one of claims 1-7. The computer readable storage medium stores computer execution instructions, and the computer execution instructions are executed by the processor to implement the method in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer program is executed by the processor to implement the method in any one of claims 1-7.

11. A computer program product, characterised in that, ​

Images