A microservice calling method

Abstract

The present invention discloses a microservice calling method, which realizes microservice registration and microservice access proxy through a service registration proxy. The service registration proxy receives microservice connections and saves microservice related information in a service routing table. The service registration proxy can propagate change information of the service routing table to adjacent service registration proxies. The service proxy is used for microservices in a local service domain to call microservices in other service domains for external access. At the same time, it can also proxy microservices in other service domains to request access to microservices registered in the local service domain, thereby solving the complexity of mutual calling of microservices in different networks. In addition, the microservice itself does not need to open a port. The service registration proxy opens a port to receive the registration of the microservice, establishes a long link, realizes two-way communication, improves security, and can avoid high RTT and TIME_WAIT problems caused by frequent creation and disconnection.

Description

Technical Field

[0001] The present invention relates to the field of microservice calling technology, and in particular to a microservice calling method. Background Art

[0002] Currently, microservices deployed within cloud services can only call other microservices deployed on their own cloud platforms through service registration and discovery. The fundamental reason is that when the service is registered, the address and port registered on the registration server are the IP address and port dynamically scheduled and allocated by the cloud platform. This port can only be accessed within the container's internal network; Docker Compose, Docker Swarm, and Kubernetes are all handled in this way; therefore, microservices deployed on different cloud platforms cannot achieve automatic cross-cloud calls through registration services; similarly, multiple microservices in different network environments that cannot access each other cannot achieve mutual calls between services through a registration center that can be accessed together. Summary of the Invention

[0003] The present invention aims to at least solve the technical problems existing in the prior art. To this end, the present invention proposes a microservice calling method, which is applied to a microservice calling system, wherein the microservice calling system includes multiple service registration agents located in different service domains, wherein the multiple service registration agents establish communication connections, each service registration agent respectively builds a service routing table and opens a port to receive registrations of microservices in the corresponding local service domain, each service registration agent includes a service routing table, and the service registration agent stores the online and offline information of the service registration agent in the service routing table, the online and offline information of the microservice, the service node connection status information, and the network link status information; the microservice calling method includes:

[0004] The first service registration agent among the multiple service registration agents receives a call request from the first microservice in its local service domain to call the second microservice, and the call request carries call information; when the second microservice is located in the service domain of the second service registration agent and a communication connection is established between the first service registration agent and the second service registration agent through several service registration agents, the first service registration agent transmits the call request to the second service registration agent in sequence through the several service registration agents, so that the second service registration agent queries the information of the second microservice in the corresponding service routing table according to the call information in the call request, and forwards the call request to the long link between the second service registration agent and the second microservice according to the queried information, and writes the service information generated by this call into the corresponding service routing table.

[0005] According to the embodiments of the present invention, there are at least the following technical effects:

[0006] (1) A cross-cloud and cross-network microservice calling method is proposed. The method combines service registration and service proxy. The service registration proxy jointly realizes microservice registration and microservice access proxy. Among them, the service registration proxy receives microservice connections and saves microservice related information into the service routing table. The service routing table is shared with adjacent service registration proxies and can propagate service routing table change information to adjacent service registration proxies. It is used for mutual calls between microservices in the local service domain of the service proxy and external calls to microservices in other service domains. At the same time, it can also proxy the access requests of microservices in other service domains to microservices registered in the local service domain, solving the complexity of mutual calls of microservices in different networks. Moreover, through the service proxy method, the underlying network differences are shielded.

[0007] (2) In this method, the microservice itself does not need to open a port. The service registration agent opens a port to receive the registration of the microservice, establishes a long link, realizes two-way communication, and improves security.

[0008] (3) Maintaining a long connection between the microservice and the service registration agent can avoid high RTT and TIME_WAIT problems caused by frequent disconnections.

[0009] According to some embodiments of the present invention, the microservice calling method also includes: when the second microservice is located in the local service domain of the first service registration agent, the first service registration agent finds the long link between the first service registration agent and the second microservice from the service routing table according to the call information in the call request, and forwards the call request to the long link between the first service registration agent and the second microservice, and writes the service information generated by this call into the corresponding service routing table.

[0010] According to some embodiments of the present invention, the microservice calling method further includes:

[0011] When the first microservice is disconnected from the first service registration agent, the first service registration agent discards all information about the first microservice in the service routing table and sends the network link status information of the first service registration agent to its neighbor agent.

[0012] According to some embodiments of the present invention, the first service registration agent communicates with the microservices within its local service domain using the RSOCKET protocol or the GRPC protocol.

[0013] According to some embodiments of the present invention, the call information includes at least the name of the called microservice, and the name of the called microservice is written into the message header of the call request; the second service registration agent queries the information of the second microservice corresponding to the service routing table according to the call information in the call request, including:

[0014] The second service registration agent parses the message header in the call request to obtain the name of the second microservice, and queries the information of the second microservice from the service routing table according to the name of the second microservice.

[0015] According to some embodiments of the present invention, the first service registration agent sequentially transmitting the call request to the second service registration agent through the plurality of service registration agents includes:

[0016] The first service registration agent parses the message header in the call request to obtain the name of the second microservice, and queries the second service registration agent from the service routing table according to the name of the second microservice;

[0017] The first service registration agent calculates the shortest path for forwarding the call request from the first service registration agent to the second service registration agent according to the shortest path algorithm of the graph;

[0018] The first service registration agent forwards the call request to the next neighbor agent in the shortest path, so that the neighbor agent receiving the call request forwards the call request to the next neighbor agent in the shortest path, and so on, until the call request is forwarded to the second service registration agent.

[0019] According to some embodiments of the present invention, the first service registration agent propagates the network link status information to its neighbor agents in the following manner:

[0020] The first service registration agent builds current network link status data with its neighbor agents;

[0021] The first service registration agent forwards the current network link status data carrying the version to all neighbor agents of the first service registration agent, so that any neighbor agent of the first service registration agent compares the current network link status data with the historical network link status data. When the version of the current network link status data is greater than the version of the historical network link status data, the current network link status data is written into the corresponding service routing table and the historical network link status data is discarded.

[0022] According to some embodiments of the present invention, before the two service registration agents establish a communication connection, the microservice calling method further includes:

[0023] The two service registration agents authenticate each other.

[0024] According to some embodiments of the present invention, the microservice calling method further includes:

[0025] The service registration agent manages microservices through the service routing table.

[0026] According to some embodiments of the present invention, the microservice calling method further includes:

[0027] When the interface provided by the first microservice is RSOCKET or GRPC, the first microservice sends the call request to the first service registration agent;

[0028] When the interface provided by the first microservice is an HTTP / Dubbo interface, the first microservice converts the requested call information into a binary string and sends the binary string to the first service registration agent through the message header; when the second service registration agent parses the message header through the Agent, the second microservice calls the HTTP / Dubbo interface.

[0029] Additional aspects and advantages of the present invention will be set forth in part in the description which follows and, in part, will be obvious from the description which follows, or may be learned by practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the following description of the embodiments with reference to the accompanying drawings, in which:

[0031] Figure 1 This is a flowchart of a method for calling a microservice provided by one embodiment of the present invention;

[0032] Figure 2 This is a flowchart of a microservice calling method provided by another embodiment of the present invention;

[0033] Figure 3 This is a logical diagram of a microservice calling system provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0034] The following describes embodiments of the present invention in detail. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended only to explain the present invention and are not to be construed as limiting the present invention.

[0035] It should be noted that although the device schematics illustrate functional module divisions and the flowcharts illustrate logical sequences, in certain circumstances, the steps shown or described may be performed in a sequence that differs from the module divisions in the device or the sequence in the flowcharts. The terms "first," "second," and so on, in the specification, claims, and drawings, are used to distinguish similar items and are not necessarily used to describe a specific sequence or precedence.

[0036] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application pertains. The terms used herein are for the purpose of describing the embodiments of this application only and are not intended to limit this application.

[0037] Reference Figure 1 One embodiment of the present application provides a microservice calling method, which is applied to a microservice calling system. The microservice calling system includes multiple service registration agents located in different service domains, and a communication connection is established between the multiple service registration agents. Before establishing the communication connection, the two agents first authenticate each other to improve security; each service registration agent separately builds a service routing table and opens a port to receive registrations of microservices in the corresponding local service domain. Each service registration agent includes a service routing table, and the service registration agent stores the online and offline information of the service registration agent in the service routing table, the online and offline information of the microservice, the service node connection status information, and the network link status information. In some embodiments of the present application, the agent communicates with the microservices in its local service domain using the RSOCKET protocol or the GRPC protocol.

[0038] The calling methods of microservices include:

[0039] Step S100: A first service registration agent among multiple service registration agents receives a call request from a first microservice in its local service domain to call a second microservice, where the call request carries call information.

[0040] Step S200: When the second microservice is located in the service domain of the second service registration agent and a communication connection is established between the first service registration agent and the second service registration agent through several service registration agents, the first service registration agent transmits the call request to the second service registration agent in sequence through the several service registration agents, so that the second service registration agent queries the information of the second microservice in the corresponding service routing table according to the call information in the call request, and forwards the call request to the long link between the second service registration agent and the second microservice according to the queried information, and writes the service information generated by this call into the corresponding service routing table.

[0041] In this embodiment, a microservice calling method across cloud environments and network environments is provided. The method combines service registration and service proxy, and a service registration proxy (referring to a server with service registration and proxy) simultaneously implements microservice registration and microservice access proxy; wherein the service registration proxy receives microservice connections and saves microservice-related information in a service routing table. The service registration proxy can propagate change information of the service routing table (such as online and offline information of the service registration proxy, online and offline information of the microservice, service node connection status information, and network link status information) to adjacent service registration proxies (referred to as neighbor proxies in this application), which are used for mutual calls between microservices in the local service domain of the service proxy, as well as external calls to microservices in other service domains. At the same time, it can also proxy access requests from microservices in other service domains to microservices registered in the local service domain, thereby solving the complexity of mutual calls between microservices in different networks; and through the service proxy method, the underlying network differences are shielded.

[0042] Unlike existing technologies, in this embodiment, the microservice itself does not need to open a port. Instead, the service registration agent opens a port to receive microservice registrations, establishing a persistent connection, enabling two-way communication and improving security. Furthermore, maintaining a persistent connection between the microservice and the service registration agent avoids high RTTs and TIME_WAIT issues caused by frequent connection creation and disconnection.

[0043] In some embodiments of the present application, the above-mentioned microservice calling method also includes: when the second microservice is located in the service domain of the second service registration agent and the second service registration agent is a neighbor agent of the first service registration agent, the first service registration agent directly transmits the call request to the second service registration agent without the need for multiple data propagation through adjacent agents.

[0044] Reference Figure 2 In some embodiments of the present application, the above-mentioned microservice calling method further includes the following step S300:

[0045] Step S300: When the second microservice is located in the local service domain of the first service registration agent, the first service registration agent finds the long link between the first service registration agent and the second microservice from the service routing table based on the call information in the call request, forwards the call request to the long link between the first service registration agent and the second microservice, and writes the service information generated by this call into the corresponding service routing table. It should be noted that after being written to the service routing table, the service information generated by the call (such as the traffic generated by the service call, the duration, etc.) will be stored in the local memory and the service information will not be propagated.

[0046] In some embodiments of the present application, the service registration agent can manage microservices in the service routing table through a management program. For example, when a first microservice is disconnected from the first service registration agent, the management program of the first service registration agent will discard all information of the first microservice in the service routing table and send the network link status information of the first service registration agent to its neighbor agent.

[0047] In some embodiments of the present application, the management program of the service registration agent can view the routing table information and temporarily take a specified service offline; it can set the calling frequency, rate, bandwidth and other information of the registered service; it can view the calling frequency, number, average delay and other statistical information of the service; for the calling frequency, number and other statistical information of the service internal interface, different interceptor plug-ins can be defined for interfaces of different protocols to generate.

[0048] In some embodiments of the present application, the call information includes at least the name of the called microservice, and the name of the called microservice is written into the message header of the call request; the second service registration agent queries the information of the second microservice in the corresponding service routing table according to the call information in the call request, including:

[0049] Step S2011: The second service registration agent parses the message header in the call request to obtain the name of the second microservice, and queries the information of the second microservice from the service routing table according to the name of the second microservice.

[0050] In some embodiments of the present application, the first service registration agent transmits the call request to the second service registration agent in sequence through several service registration agents, including:

[0051] Step S2021: The first service registration agent parses the message header in the call request to obtain the name of the second microservice, and searches the service routing table for the second service registration agent based on the name of the second microservice.

[0052] Step S2022: The first service registration agent calculates the shortest path for forwarding the call request from the first service registration agent to the second service registration agent according to the shortest path algorithm of the graph;

[0053] Step S2023: The first service registration agent forwards the call request to the next neighbor agent in the shortest path, so that the neighbor agent that receives the call request forwards the call request to the next neighbor agent in the shortest path, and so on, until the call request is forwarded to the second service registration agent.

[0054] In some embodiments of the present application, the first service registration agent propagates network link status information to its neighbor agents in the following manner:

[0055] Step S2031: The first service registration agent constructs current network link status data with its neighboring agents; wherein the network link status data at least includes information in the service routing table and current network information;

[0056] Step S2032: The first service registration agent forwards the current network link status data carrying the version to all neighbor agents of the first service registration agent, so that any neighbor agent of the first service registration agent compares the current network link status data with the historical network link status data. When the version of the current network link status data is greater than the version of the historical network link status data, the current network link status data is written into the corresponding service routing table and the historical network link status data is discarded.

[0057] In some embodiments of the present application, the microservice calling method further includes:

[0058] Step S2041: When the interface provided by the first microservice is RSOCKET or GRPC, the first microservice sends a call request to the first service registration agent;

[0059] Step S2051: When the interface provided by the first microservice is an HTTP / Dubbo interface, the first microservice converts the requested call information into a binary string and sends the binary string to the first service registration agent through the message header; when the second service registration agent parses the message header through the Agent, the second microservice calls the HTTP / Dubbo interface.

[0060] At this stage, microservices still have the following technical defects:

[0061] (1) Currently, microservices deployed within cloud services can only call other microservices deployed on their own cloud platforms through service registration and discovery. The fundamental reason is that when a service is registered, the cloud platform dynamically schedules and allocates an IP address and port to the address and port on the registration server, and this port can only be accessed within the container's internal network. This is how Docker Compose, Docker Swarm, and Kubernetes are all handled. Therefore, microservices deployed on different cloud platforms cannot automatically call each other across clouds through registration services. Similarly, multiple microservices in different network environments that cannot access each other cannot call each other through a registration center that can be accessed together.

[0062] (2) The existing registration found that the microservices registered on the server must expose the port, which increases the possibility of being scanned and attacked;

[0063] (3) Inter-service call control, such as frequency, rate, and logging, must be coupled within the microservice;

[0064] (4) The service registry and microservices are connected via HTTP, and data changes in the registry are detected through polling. This is inefficient and wastes resources. Frequent creation of short HTTP connections can easily cause TIME WAIT.

[0065] (5) When a microservice crashes abnormally, or when the network connection between the microservice and the registration center is abnormal, the registration center cannot perceive the service abnormality in time, affecting the normal call of other services to the microservice.

[0066] Reference Figure 3 For ease of understanding, an embodiment of the present application provides a microservice invocation system and a microservice invocation method thereof. The system includes: multiple service registration agents. Assuming that there is a service registration agent in each service domain, the service registration agent adopts a combination of service registration and service proxy. A communication connection is established between the multiple service registration agents. Before establishing a communication connection, mutual authentication is required. Only after successful authentication is a communication connection established. In this embodiment, the connection mode between two service registration agents includes: active connection and passive reception. The reason for the existence of active connection and passive connection is determined by different network environments. Some internal networks only allow access from external whitelisted machines, but the internal network cannot actively access the external network; some internal networks do not allow external network access, but can access externally specified whitelisted service registration agents from the internal network. The service registration agent in the local service domain can establish a communication connection with other service registration agents, or use a public service registration agent as an intermediate node for the communication connection between two service registration agents.

[0067] To enable microservice communication across network environments or cloud platforms, assume that each service domain contains multiple microservices. Microservices in the local service domain connect to a local service registry proxy. The local microservices connect to the local service registry proxy in the following way:

[0068] The service registration agent opens ports to receive active connections from microservices and registers metadata related to the microservices themselves, including the service name, service instance ID, version number, and other custom tags. A microservice needs to provide corresponding connection credentials when connecting to the service registration agent. After the active connection is successful, a long connection is established between the service registration agent and the microservice. The service registration agent adds the service information to the service routing table through the service routing manager and stores it in the service routing repository. The microservice and the service registration agent maintain a long connection and communicate using the RSOCKET protocol or the GRPC protocol. Two-way communication can be carried out on a single connection, and microservices do not need to open ports separately. Establishing a long connection between services avoids the three-way handshake problem when frequently establishing connections, improves the RTT, and avoids the TIME WAIT problem when frequently establishing short connections.

[0069] When a microservice in the local service domain goes offline or a network anomaly causes the microservice to be disconnected from the service registration agent, the service routing manager of the service registration agent deletes the service information of the microservice from the service routing table, updates the service routing repository, and propagates the service node connection status information to neighboring agents.

[0070] The service registration agent will propagate its own service routing table change information to neighboring agents. The service routing table change information includes the online and offline status of the service registration agent and the online and offline status of microservices. Through the propagation of routing, the routing information of multiple service registration agents connected in cascade will form a complete service routing table on each service registration agent. The information in the service routing table can form a complete service node graph.

[0071] The management program of the service registration agent can view the information of the service routing table and temporarily take designated services offline; it can set the calling frequency, rate, bandwidth and other information of the registered service; it can view the statistical information such as the calling frequency, number, average delay and so on of the service; for the statistical information such as the calling frequency and number of the internal interface of the service, different interceptor plug-ins can be defined for interfaces of different protocols to generate.

[0072] The following describes how to call the microservices of this system:

[0073] When a first microservice (the first microservice is the microservice that actively calls the service) needs to call a second microservice (the second microservice is the microservice being called), it places the name, version number, and other information of the second microservice in the request header and sends the request to the first service registration agent (the first service registration agent is the service registration agent in the service domain of the first microservice). After receiving the request, the first service registration agent parses the header information as needed and queries the service routing table of the first service registration agent through the service routing manager of the first service registration agent. If the called second microservice is a service in the local service domain, it finds the service connection established with the service registration agent based on the name of the second microservice and forwards the request message content to this connection to call the second microservice. If the called second microservice is a service in the remote service domain, when calling the second microservice in the remote service domain, the request is sent to the first service registration agent. The first service registration agent requests the service routing manager to query the forwarding path based on the name of the second microservice in the message header and other information. The first service registration agent finds the optimal request path based on the shortest path algorithm of the graph and forwards the request to the next service registration agent (the neighbor agent of the first service registration agent); the next service registration agent continues to execute the proxy forwarding logic of the request until the request is sent to the second service registration agent, and forwards the request message content to the connection to call the second microservice.

[0074] When forwarding requests, the service registration agent implements zero copy of data packets, without the need to repeatedly copy memory data, and only parses the required field information when parsing the message header.

[0075] It should be noted that when the interface provided by the microservice supports RSOCKET or GRPC, the message can be sent directly to the service registration agent of the corresponding service domain without format conversion; when the interface provided in the microservice is an HTTP / DUBBO interface, the HTTP / DUBBO calls made by registration and discovery in the microservice are processed in the microservice as an agent; the original request data is converted into a binary string and sent to the service registration agent through the message body, while the message header retains some of the original request header data that needs to be used in the service agent plug-in; the service registration agent forwards the request to the called agent, and after the agent restores the request data, the HTTP / Dubbo interface is called in the local process.

[0076] In some embodiments of the present application, a link state routing algorithm is used between service registration agents to propagate network link state information, which is mainly divided into the following steps:

[0077] Step S401: Each service registration agent establishes a connection with a neighboring agent and constructs network link status data with the neighboring agent; the network link status data includes bandwidth information actively set by the connection establishing party, service load, network delay between the two service registration agents, service instance ID, service name, and other relevant metadata of the service.

[0078] Step S402: Send the versioned network link status data to all neighbor agents.

[0079] Step S403: The service registration router of the service registration agent receives the network link status data sent by the neighbor agent, compares the versions, stores them in the local routing repository, and forwards them to all neighbor agents except the source neighbor agent; when the local network link status data version is greater than the received network link status data version, the received network link status data is discarded; to avoid the hierarchical depth of the routing agent, when forwarding the network link status data packet of the neighbor agent, the forwarding depth field can be incremented, and after exceeding a certain depth, the network link status data packet will no longer be forwarded.

[0080] Step S404: The service registration agent periodically refreshes the dynamic load status of each link and sends a network link status data packet to the relevant neighbor agent. The dynamic load attributes include network delay, effective bandwidth capacity per unit time, service load, etc.

[0081] Step S405: When the microservice or service registration agent goes offline or the connection is abnormally interrupted, the network link status data is sent to all neighboring agents.

[0082] Step S406: After receiving the network link status data, update the local service routing table information, establish the mapping relationship between the service name and version of the microservice and the service registration agent service; and calculate the shortest path between the current service registration agent and all other service registration agents in the local service routing table.

[0083] The microservice invocation system and microservice invocation method provided in this embodiment have at least the following beneficial effects:

[0084] (1) To solve the complexity of mutual calls between microservices in different networks, it is only necessary for services in each network to access the same service registration agent, or to establish a connection between the accessed service registration agents. Then, the services registered on each service registration agent can be accessed through the service registration agent.

[0085] (2) The microservice itself does not need to open ports. It only needs to establish a connection from the microservice to the service registration agent to achieve two-way communication. Service registration agents also only need to establish a one-way connection to achieve two-way communication. This can improve system security, and security protection only needs to pay attention to the service registration agent with open ports.

[0086] (3) The service registration agent can be used to uniformly manage the online and offline operations of microservices, manage the call frequency and traffic of services, and monitor the call status of services.

[0087] (4) A long connection is maintained between the microservice and the service registration agent. When a service fails abnormally or the network encounters an abnormality, the service status can be promptly propagated to the service registration agent of the global service network by forcing the long connection network connection to be interrupted, ensuring that subsequent microservice calls can be balanced to other backup microservice nodes.

[0088] (5) Maintaining long connections between services avoids RTT and TIME_WAIT problems caused by frequent creation and disconnection.

[0089] Throughout this specification, reference to terms such as "one embodiment," "some embodiments," "illustrative embodiments," "examples," "specific examples," or "some examples" means that a specific feature, structure, material, or characteristic described in conjunction with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, illustrative uses of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

[0090] The above is a specific description of the preferred implementation of the embodiments of the present application, but the embodiments of the present application are not limited to the above-mentioned implementation methods. Technical personnel familiar with the art can also make various equivalent modifications or substitutions without violating the spirit of the embodiments of the present application. These equivalent modifications or substitutions are all included in the scope defined by the claims of the embodiments of the present application.

Claims

1. A method for calling a microservice, characterized in that: A microservice invocation system includes multiple service registration agents located in different service domains. Communication connections are established between the multiple service registration agents. Each service registration agent constructs a service routing table and opens a port to receive registrations of microservices in the corresponding local service domain. Each service registration agent includes a service routing table. The service registration agent propagates online and offline information of the service registration agent, online and offline information of the microservice, service node connection status information, and network link status information in the service routing table to corresponding neighbor agents. The calling method of the microservice includes: A first service registration agent among the multiple service registration agents receives a call request from a first microservice in its local service domain to call a second microservice, where the call request carries call information; when the second microservice is located in the service domain of the second service registration agent and a communication connection is established between the first service registration agent and the second service registration agent through a plurality of service registration agents, the first service registration agent transmits the call request to the second service registration agent in sequence through the plurality of service registration agents, so that the second service registration agent queries the information of the second microservice in the corresponding service routing table according to the call information in the call request, and forwards the call request to the long link between the second service registration agent and the second microservice according to the queried information, and writes the service information generated by this call into the corresponding service routing table; The first service registration agent builds current network link status data with its neighbor agents; The first service registration agent forwards the current network link status data carrying the version to all neighbor agents of the first service registration agent, so that any neighbor agent of the first service registration agent compares the current network link status data with the historical network link status data. When the version of the current network link status data is greater than the version of the historical network link status data, the current network link status data is written into the corresponding service routing table and the historical network link status data is discarded.

2. The microservice calling method according to claim 1, characterized in that: The calling method of the microservice also includes: When the second microservice is located in the local service domain of the first service registration agent, the first service registration agent finds the long link between the first service registration agent and the second microservice from the service routing table according to the call information in the call request, and forwards the call request to the long link between the first service registration agent and the second microservice, and writes the service information generated by this call into the corresponding service routing table.

3. The microservice calling method according to claim 2, characterized in that: The calling method of the microservice also includes: When the first microservice is disconnected from the first service registration agent, the first service registration agent discards all information about the first microservice in the service routing table and sends the network link status information of the first service registration agent to its neighbor agent.

4. The microservice calling method according to claim 2, characterized in that: The first service registration agent communicates with the microservices within its local service domain using the RSOCKET protocol or the GRPC protocol.

5. The microservice calling method according to claim 2, characterized in that: The call information at least includes the name of the called microservice, and the name of the called microservice is written into the message header of the call request; The second service registration agent queries the information of the second microservice corresponding to the service routing table according to the call information in the call request, including: The second service registration agent parses the message header in the call request to obtain the name of the second microservice, and queries the information of the second microservice from the service routing table according to the name of the second microservice.

6. The microservice calling method according to claim 5, characterized in that: The first service registration agent transmits the call request to the second service registration agent in sequence through the plurality of service registration agents, including: The first service registration agent parses the message header in the call request to obtain the name of the second microservice, and queries the second service registration agent from the service routing table according to the name of the second microservice; The first service registration agent calculates the shortest path for forwarding the call request from the first service registration agent to the second service registration agent according to the shortest path algorithm of the graph; The first service registration agent forwards the call request to the next neighbor agent in the shortest path, so that the neighbor agent receiving the call request forwards the call request to the next neighbor agent in the shortest path, and so on, until the call request is forwarded to the second service registration agent.

7. The microservice calling method according to claim 1, characterized in that: Before the two service registration agents establish a communication connection, the calling method of the microservice also includes: The two service registration agents authenticate each other.

8. The microservice calling method according to claim 1, characterized in that: The calling method of the microservice also includes: The service registration agent manages microservices through the service routing table.

9. The microservice calling method according to claim 6, characterized in that: The calling method of the microservice also includes: When the interface provided by the first microservice is RSOCKET or GRPC, the first microservice sends the call request to the first service registration agent; When the interface provided by the first microservice is an HTTP / Dubbo interface, the first microservice converts the requested call information into a binary string and sends the binary string to the first service registration agent through the message header; when the second service registration agent parses the message header through the Agent, the second microservice calls the HTTP / Dubbo interface.

Images