CN112165431B

CN112165431B - Low-delay micro-service route management system

Info

Publication number: CN112165431B
Application number: CN202010518234.0A
Authority: CN
Inventors: 李思昌; 张海荣; 高剑; 鲁继东; 余峰; 张备战
Original assignee: Shanghai Financial Futures Information Technology Co ltd
Current assignee: Shanghai Financial Futures Information Technology Co ltd
Priority date: 2020-06-09
Filing date: 2020-06-09
Publication date: 2022-04-12
Anticipated expiration: 2040-06-09
Also published as: CN112165431A

Abstract

The invention discloses a low-delay micro-service route management system, which reduces message forwarding delay, supports cross-local area network deployment and meets the fault tolerance requirement. The technical scheme is as follows: and the functions of service discovery, service offline and service routing in the micro-service cluster are supported. The service routing table adopts distributed management, and the routing table of each node can be automatically adjusted along with the change of the service and the node in the cluster. The deployment of single and multiple local area networks is supported, and all nodes in the same domain exchange routing table records. The multiple local area networks realize the cascade connection of the multiple local area networks by deploying the agent nodes, the agent nodes mutually exchange routing information through a TCP network and broadcast and inform the nodes in the local area, and each node in the cluster can obtain the routing information of the whole cluster. By adopting distributed routing management, when the server or the agent node exits unexpectedly, the expected connected nodes can automatically perform offline processing, and inform other nodes in the cluster, so that the cluster automatically completes routing adjustment under node failure.

Description

Low-delay micro-service route management system

Technical Field

The invention relates to a financial software service technology, in particular to a low-delay micro-service route management system.

Background

The micro-service is an architectural model, and advocates dividing an application program into a group of small services, and the services are coordinated and matched with each other to provide flexible application services for users. In the field of financial software service, financial services such as transaction, settlement, supervision and the like can be integrated by using a micro-service architecture, and flexible deployment and access of services are realized. Because the financial software system has the characteristics of low delay, high reliability and the like, the micro-service routing management scheme has the following requirements:

(1) support service discovery and service routing functions: the service discovery means that after a certain service node is on line, other nodes in the micro-service cluster can be notified in time in a certain mode, and the service address, the service type and other messages of the node are notified to other nodes. The service routing means that nodes in a cluster can automatically forward service data, a client node can initiate a service request, request data is routed to a corresponding micro service node, and the service node sends response data after completing the service request processing and routes the response data to a corresponding client through the cluster.

(2) Supporting cross-local area network deployment: in consideration of security, when a financial system is actually deployed, a plurality of local area networks are usually spanned, nodes in the same local area network can directly perform TCP or UDP communication, nodes in different local area networks cannot directly perform communication, and data transfer needs to be performed through a specific proxy node. The micro service routing management system needs to support service discovery and service routing functions under the condition of cross-local area network deployment.

(3) A fault tolerance mechanism: when the node in the cluster is actively withdrawn or the node is unexpectedly disconnected, other nodes in the cluster can automatically adjust the routing table and do not perform message routing on the withdrawn node any more.

Currently, the industry does not have a routing management system for microservices to achieve the above requirements.

Disclosure of Invention

The following presents a simplified summary of one or more aspects in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated aspects, and is intended to neither identify key or critical elements of all aspects nor delineate the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that is presented later.

The invention aims to solve the problems and provides a low-delay micro-service route management system, which reduces the message forwarding delay, supports the cross-local area network deployment and meets the fault-tolerant requirement.

The technical scheme of the invention is as follows: the invention discloses a low-delay microservice route management system, which is used for carrying out route management on nodes on a microservice cluster, wherein the nodes of the microservice cluster comprise a server, a client and a proxy node, each node in the microservice cluster stores a service route table, the service route including the step of forwarding a service request initiated by the client node to a corresponding service address is realized by inquiring the service route table on the node, and the system comprises a service discovery function module, a service offline function module and a service request and service response function module, wherein:

the service discovery function module is configured to configure that nodes in a domain share and update routing table information in real time through the same UDP broadcast address owned by each node in the domain;

the service offline function module is configured to delete the service information from the micro service cluster and update the routing table information on each node when the service end does not provide a certain service to the outside any more;

and the service request and service response function module is configured to realize service calling in the micro service cluster in a request-response mode.

According to an embodiment of the low-latency micro-service routing management system of the present invention, the service routing table is established by each node after the micro-service cluster is started, and the nodes also update their respective service routing tables in real time: each node in the same domain receives service routing information through a multicast channel, and records of a service routing table are exchanged among local area networks through proxy nodes; one record in the service routing table is (S, N, a, L), where S is the service number, N is the node number, a is the service address, and L is the path length, and the meaning of the record is: the shortest path length from the node to the service number S is L, the next node on the shortest path is N, the corresponding service address is A, the request data is forwarded to the address A, the node number N points to the next node of the path, the next node comprises an agent node or a service end node, and in the service routing table, for the same service number S, only the route with the shortest path length is recorded in the service routing table.

According to an embodiment of the low latency microservice routing management system of the present invention, the service discovery function module includes a single domain service discovery unit, and the single domain service discovery unit is configured to:

after a service end node is started, service information broadcasting is carried out on a broadcasting UDP address at regular time according to configured frequency, and a service routing table record (S, N, A and L) is sent outwards aiming at each service provided by the service end when the service information broadcasting is carried out every time, wherein S is a service number, N is a service end node number, A is a service address of the service, and L is 0;

after receiving the routing table record (S, N, A, L) broadcasted by the server, the proxy node and the client node in the same domain as the server node do the following processing: (1) searching a routing table of the node, judging whether a record of the service number S exists or not, and if the record of the service number S does not exist, inserting a record of (S, N, A, L +1) into the routing table of the node; (2) if the routing table of the node has the original record, taking out the original record (S, N ', A ', L '). If L +1> is L', the routing table does not need to be updated; if L +1< L', the original record is updated to (S, N, A, L + 1).

According to an embodiment of the low latency microservice routing management system of the present invention, the service discovery function module includes a cross-domain service discovery unit, and the cross-domain service discovery unit is configured to:

a local domain proxy node of one domain establishes TCP connection with cross-domain proxy nodes of other domains;

the local domain proxy node receives the information on the UDP broadcast channel in real time, updates the routing table of the local domain proxy node, and sends a routing update message to all connected cross-domain proxy nodes when the routing table of the local domain proxy node is updated;

the local domain proxy nodes of other domains receive the routing update message sent by the cross-domain proxy nodes in real time and update the routing tables (S, N, A, L) of the local domain proxy nodes, wherein S is a service number, N is a service end node number, A is a service address of the service, and L represents the path length, and the updating process comprises the following steps:

(a) searching a routing table of the node, judging whether a record of the service number S exists or not, and if the record of the service number S does not exist, inserting a record of (S, N, A, L +1) into the routing table of the node;

(b) if the routing table of the node has the original record of the service number S, taking out the original record (S, N ', A', L '), and if L +1> is L', the routing table does not need to be updated; if L +1< L', updating the original record to (S, N, A, L + 1);

(c) if the routing table record is updated to (S, N, A, L +1), the local domain PROXY node sends a (S, N _ PROXY, A _ PROXY, L +1) routing message to the UDP broadcast channel in the local domain at regular time, wherein N _ PROXY and A _ PROXY are the node number and the service address of the local domain PROXY node respectively.

According to an embodiment of the low-latency microservice routing management system of the present invention, the processing configuration of the service offline function module for actively sending the service offline notification to the server is as follows:

when the service end does not provide a certain service any more, sending a service offline notification through a UDP broadcast channel, wherein the service offline notification comprises routing information (S, N, A, L) related to the service, S and A are a service number and a service address of the service to be offline, N is a node number of the service end, and L represents the path length;

for the condition in the same domain, after receiving the service offline message, the client and the proxy node in the same domain search whether the record of (S, N, A, L +1) exists in the routing table of the node, if so, the record is deleted from the routing table;

for the case of cross-domain deployment, the agent node receives and processes the service offline message from the connected cross-domain agent nodes, and if the agent node successfully processes the service offline message and deletes a corresponding record (S, N, A, L), the agent node simultaneously sends a service offline notification (S, N _ PROXY, A _ PROXY, L) to the UDP broadcast channel of the local domain and other connected cross-domain agent nodes, wherein N _ PROXY and A _ PROXY are the node number and the service address of the agent node.

According to an embodiment of the low-latency micro-service routing management system of the present invention, the processing configuration of the service logout function module for the unexpected exit of the service end is as follows:

the server-side node is accidentally quitted, so that the server-side node cannot actively send out a service offline notification, and when the server-side node is accidentally quitted, the TCP connection established between the server-side node and the client-side node and the proxy node is automatically disconnected;

if the client detects that the connection with the service end node or the agent node is disconnected, deleting a routing record containing the service end node from the routing table;

and if the agent node detects that the connection with the server or the agent node is disconnected, deleting the routing record containing the server node from the routing table, and sending a service offline notification to the connected cross-domain agent node for each deleted record.

According to an embodiment of the low latency microservice routing management system of the present invention, the processing of the service invocation mode by the service request and service response function module is further configured as follows:

a client node initiates a service request, and request data is finally forwarded to a corresponding service end node according to routing table information on each node;

the service end node processes the service request, and sends the response data generated by the service request back to the client end node, when the service request is forwarded, each node on the path through which the service request passes records the source address of the request data, and when the response data is forwarded, the response data is returned according to the original route of the routing path of the request data.

Compared with the prior art, the invention has the following beneficial effects: the system of the invention adopts distributed routing management, does not have centralized routing nodes, stores service routing information by each node in the cluster, can directly inquire routing tables in the memory for request and response data and select forwarding paths, and reduces message forwarding delay. The cross-local area network deployment can be supported, in the same local area network, UDP broadcast channels are used for exchanging routing information, and cross-domain data exchange is realized through a TCP network protocol by deploying proxy nodes under the condition of cross-local area network. In addition, after the nodes in the cluster exit, other nodes can adjust the routing table by themselves to meet the fault-tolerant requirement. Specifically, the innovation points of the system of the invention include:

1. the invention supports the functions of service discovery, service offline, service routing and the like in the micro-service cluster. The service routing table adopts distributed management, each node in the cluster stores one routing table, and the routing table of each node can be automatically adjusted along with the service and node change in the cluster without human intervention. Because each node independently maintains the routing table, when the routing of the request data is carried out, each node can directly inquire the routing table data stored in the memory so as to reduce the whole routing time delay.

2. The invention supports the flexible deployment of single local area network and multiple local area networks. Each node in the same domain exchanges the record of the routing table through the UDP broadcast channel, and the diffusion speed of the routing information is high and the time delay is low. When a plurality of local area networks exist, the cascade connection of the local area networks can be realized by deploying the agent nodes, the agent nodes exchange routing information with each other through a TCP network and inform each node in the local area through UDP broadcast, and each node in the cluster can obtain the routing information of the whole cluster.

3. The invention adopts distributed routing management, and has no single-point fault risk. When the server or the agent node exits unexpectedly, the expected connected nodes can automatically perform offline service processing after detecting disconnection, and notify other nodes in the cluster through the local domain UDP or the agent node, so that the whole cluster can automatically complete the routing adjustment under the node failure, and has strong fault tolerance.

Drawings

The above features and advantages of the present disclosure will be better understood upon reading the detailed description of embodiments of the disclosure in conjunction with the following drawings. In the drawings, components are not necessarily drawn to scale, and components having similar relative characteristics or features may have the same or similar reference numerals.

FIG. 1 illustrates a schematic diagram of one embodiment of a low latency microservice route management system of the present invention.

Fig. 2 shows a schematic diagram of a proxy node of the present invention.

Fig. 3 is a schematic diagram illustrating processing for a single domain service discovery case in a service discovery function module in the embodiment of the low latency microservice routing management system of fig. 1.

Fig. 4 and 5 are schematic diagrams illustrating processing for a cross-domain service discovery case in a service discovery function module in the embodiment of the low-latency microservice routing management system of fig. 1.

Figure 6 shows a process diagram of a service logoff function in the embodiment of the low latency microservice routing management system of figure 1.

Fig. 7A and 7B are schematic diagrams illustrating processing of a service request and service response function module in the embodiment of the low latency microservice routing management system of fig. 1.

Detailed Description

The invention is described in detail below with reference to the figures and specific embodiments. It is noted that the aspects described below in connection with the figures and the specific embodiments are only exemplary and should not be construed as imposing any limitation on the scope of the present invention.

Figure 1 illustrates the principles of one embodiment of the low latency microservice route management system of the present invention. Referring to fig. 1, the system of the present embodiment includes: the system comprises a service discovery function module, a service offline function module and a service request and service response function module.

The system is used for carrying out route management on the nodes on the micro-service cluster.

A microserver cluster is a network of nodes (nodes), each of which is a Linux application process. Each node within the microservice cluster has a globally unique number, called the node id. After the node is started, the node number is automatically generated by the system.

The node numbers are stored by 4-byte integers, and the number generation algorithm is as follows:

step 1: acquiring a system process number of a node process, and storing the system process number in a shaping variable proc _ id with the length of 1 byte;

step 2: acquiring the system starting time of a current machine, and storing the system starting time in a shaping variable local _ timestamp with the length of two bytes;

and step 3: generating a random number of 1 byte, and storing the random number in a variable rand _ id;

and 4, step 4: generate 4-byte node number: node _ id ═ (proc _ id < <24) | (local _ timestamp < <8) | rand _ id. Wherein, "<" is the operation of "left shift", and "|" is the operation of "bitwise or".

The nodes are divided into three types, namely a server type (server), a client type (client) and a proxy type (proxy) according to functions.

The service end nodes in the micro-service cluster can provide various micro-services, also called services, for the outside, wherein the micro-services correspond to a specific service function. Each type of service has a unique service number, which is stored in a string and assigned by the user. In addition, when the service end provides external services, each service is allocated with a service address, and the address is a TCP network address, and other nodes can be connected to the address to access the corresponding service.

The microservice cluster may span multiple local area networks when actually deployed, and the present invention abstracts the concept of a local area network as a "domain". The microservice cluster may be comprised of multiple domains, each of which may contain multiple nodes. Each node in the same domain can directly perform TCP or UDP communication. Each domain needs to be configured with a UDP broadcast channel, and nodes in the domain exchange data required for service routing through the channel. Network isolation exists between different domains, except for proxy nodes, nodes between different domains cannot directly carry out TCP or UDP communication, and the two domains can realize TCP communication through the proxy nodes. If a client node needs to request a service provided in another domain, the requested data must be forwarded through proxy nodes in both domains.

And each node in the micro service cluster stores a service routing table, and service routing including forwarding a service request initiated by a client node to a corresponding service address is realized by inquiring the service routing table on the node.

The following description is made with respect to the three types of process nodes (server, client, and proxy nodes) in the microservice cluster mentioned above.

The server side is the micro-service provider. A service end monitors a service address, the service end can provide a plurality of services through the service address, and each service has an independent service number and an independent service address. The server side sends information such as service numbers and service addresses to the intra-domain broadcast channel at regular time, and other nodes construct a routing table through the information. The server can receive the TCP connection initiated by the client or the proxy node, receive the service request sent by the client or the proxy node, then call the corresponding service for processing, and return the response data.

The client is the micro-service requester. The client monitors the message on the intra-domain broadcast channel in real time and updates the routing table, and can initiate a service request for the service registered in the routing table.

The role of the proxy node is as follows: when the micro service cluster has a plurality of mutually isolated domains, a plurality of local area networks can carry out message forwarding through the proxy node. After the proxy node is started, the service end and the proxy node in the same domain can be automatically discovered through the service discovery function module and TCP connection is established with the proxy node, and in addition, the proxy node in other domains can be discovered through reading the configuration file and TCP connection is established with the proxy node, so that service information in other domains can be obtained. When there is only one domain within the entire microservice cluster, no proxy node may be added.

As shown in fig. 2, a domain a (DomainA) and a domain b (DomainB) are two different domains, and according to manual configuration, a Proxy node Proxy1 in DomainA and a Proxy node Proxy2 in DomainB can establish a TCP connection, and other nodes (Server 1 and Client1) in DomainA cannot directly communicate with any node in DomainB, and only data forwarding can be performed via Proxy 1. For DomainA, in this embodiment, Proxy1 is referred to as "home domain Proxy node", and Proxy2 is referred to as "cross-domain Proxy node".

The client nodes in the micro service cluster can initiate service requests, the service requests are finally forwarded to corresponding service addresses, the service nodes perform service processing, and the process of forwarding request data is called service routing. Each node in the micro service cluster stores a mapping table to record the mapping relationship between the service number and the service address, which is called a service routing table, and the service routing is realized by inquiring the service routing table on the node.

The service routing table is used for forwarding the service request initiated by the client node to the corresponding service address. The management of the service routing table is the core of the micro service routing management system, and the service routing table is an important basis for routing request data and response data of each node. After the micro service cluster is started, each node establishes a service routing table, and the nodes update the respective service routing tables in real time: each node in the same domain receives service routing information through a multicast channel, and records of a service routing table are exchanged among local area networks through proxy nodes. When the node receives the request or response data, the service routing table is inquired according to the final target address of the data, and the next target node is determined.

One record in the service routing table contains four fields: (service number S, node number N, service address a, path length L), the meaning of this record is: the shortest path from the node to the service number S has a length L, the next node on the shortest path is N, the corresponding service address is a, and the request data is forwarded to address a. The node number N points to the next node of the path, which may be a proxy node or a service end node. In the service routing table, for the same service number S, only the route with the shortest path length is recorded in the routing table.

Each functional block will be described below.

The service discovery function module is configured to enable nodes in the domain to share and update the routing table information in real time through the same UDP broadcast address owned by each node in the domain.

In the micro-service cluster, all nodes in the same domain have the same broadcast UDP address configuration, and the nodes in the domain share the routing table information in real time through the broadcast address, which is called service discovery.

The service discovery function module is configured with a single-domain service discovery unit and a cross-domain service discovery unit.

The single domain service discovery unit implements the following configuration procedure.

If only one domain exists within the cluster, service discovery is accomplished through the UDP broadcast channel within that domain.

And after the service end node is started, broadcasting service information on the broadcasting UDP address at fixed time according to the configured frequency. When broadcasting the service information each time, aiming at each service provided by the service end, a service routing table record (S, N, A, L) is sent outwards, wherein: s is the service number, N is the service end node number, A is the service address of the service, and L is 0. When the server has a new micro service online, the information can be notified to other nodes through a timing broadcast mechanism.

After receiving the routing table record (S, N, A, L) broadcasted by the server, the proxy node and the client node in the same domain as the server node do the following processing:

(1) and searching the routing table of the node to determine whether the service number S is recorded. If there is no matching record, inserting a record of (S, N, A, L +1) into the node routing table

(2) If the original record exists in the node routing table, the original record (S, N ', A ', L ') is taken out. If L +1> is equal to L', the newly received route record does not form the shortest path, and the route table does not need to be updated; l +1< L', then the original record is updated to (S, N, A, L +1)

After the agent node and the client node are started, the routing information on the broadcast UDP address is intercepted in real time, and the routing table is updated according to the rule.

As shown in fig. 3, there is only one domain DomainA in the cluster. The domain is provided with two SERVER nodes, wherein a SERVER SERVER1 (the node number is 1001) provides two services with the service numbers of ServiceA and ServiceB, and the service addresses are AddrA and AddrB respectively; SERVER2 (node number 1002) provides a service ServiceC with a service address AddrC. According to the above rule, after the Server1 is started, two service route records, namely (ServiceA,1001, AddrA,0) and (ServiceB,1001, AddrB,0), are broadcasted into the UDP broadcast channel at regular time; after the Server2 is started, a service route record is broadcasted to the UDP channel at regular time: (ServiceC,1002, AddrC, 0).

The cluster comprises a Proxy node Proxy1 and a Client node Client1, and when two server nodes are started, the Proxy node and the Client node construct the following service routing table according to the broadcast messages of the two server nodes:

service number S	Target node N	Target address A	Shortest path length L
				ServiceA	1001	AddrA	1
ServiceB	1001	AddrB	1
				ServiceC	1002	AddrC	1

According to the routing table, if the CLIENT1 needs to request the service with the service number of ServiceB, the next node on the shortest path for accessing the service is obtained by table lookup and is 1001 node, and the data needs to be forwarded to the AddrB service address.

The cross-domain service discovery unit implements the following configuration procedure.

If a plurality of different domains exist in the micro-service cluster, cross-domain service access cannot be directly performed, and transfer needs to be performed through configuration of the proxy nodes. In this scenario, each domain should include at least one proxy node, and the connections between the proxy nodes need to be manually configured. After the proxy node is started, TCP connection is actively established with the cross-domain proxy node according to the configuration information, and subsequent routing record exchange is carried out through the TCP connection. In addition, each proxy node has a service address for forwarding traffic data.

After the agent node is started, the following operations are carried out:

(1) according to the configuration file, the proxy nodes are connected with the cross-domain proxy nodes in a TCP mode.

(2) And the proxy node receives the message on the UDP broadcast channel in real time and updates the routing table of the proxy node. When the routing table of the proxy node generates update, the proxy node sends a routing update message to all connected cross-domain proxy nodes. Assuming that the route update message in the PROXY node is (S, N, a, L), the route record sent to the cross-domain PROXY node is (S, N _ PROXY, a _ PROXY, L), where N _ PROXY and a _ PROXY are the node number and service address of the node, respectively. If the proxy node is connected to a new cross-domain proxy node, all routing information on the node needs to be sent to the newly connected proxy node in the above manner.

(3) And receiving a routing update message sent by the cross-domain proxy node in real time, and updating a routing table. Assuming that the current proxy node receives a (S, N, a, L) route record from the cross-domain proxy node (where N and a are the node number and service address of the cross-domain proxy node), the following checks will be made:

(a) and searching the routing table of the node to determine whether the service number S is recorded. If the record is not matched, inserting a record of (S, N, A, L +1) into the routing table of the node;

(b) if the node routing table has records, the original records (S, N ', A ', L ') are taken out. If L +1> is equal to L', the newly received route record does not form the shortest path, and the route table does not need to be updated; if L +1< L', the original record is updated to (S, N, A, L + 1);

(c) if the routing table record is updated to (S, N, A, L +1), the current node will periodically send a (S, N _ PROXY, A _ PROXY, L +1) routing message to the broadcast channel in the local domain, wherein N _ PROXY and A _ PROXY are the node number and service address of the PROXY node, respectively. In addition, when the routing table is updated, other connected cross-domain proxy nodes also need to be notified of the message.

By the mechanism, the routing information exchange between different domains can be realized. When the service information provided in a certain domain is changed, all nodes in the cluster adjust respective routing tables.

As shown in fig. 4, there are two domains DomainA and DomainB within the cluster, and according to the configuration information, PROXY nodes PROXY1 (service address Addr _ P1) and PROXY2 (service address Addr _ P2) will establish TCP connections for exchanging routing table data.

According to the service discovery mechanism, finally:

the routing table on PROXY node PROXY1 is as follows:

service number S	Target node N	Target address A	Shortest path length L
				ServiceA	1001	AddrA	1
ServiceB	1001	AddrB	1
				ServiceC	1002	AddrC	1
ServiceD	2002	Addr_P2	2

The routing table on PROXY node PROXY2 is as follows:

service number S	Target node N	Target address A	Shortest path length L
				ServiceA	2001	Addr_P1	2
ServiceB	2001	Addr_P1	2
				ServiceC	2001	Addr_P1	2
ServiceD	1003	AddrD	1

The routing table on the CLIENT node CLIENT1 is as follows:

service number S	Target node N	Target address A	Shortest path length L
				ServiceA	1001	AddrA	1
ServiceB	1001	AddrB	1
				ServiceC	1002	AddrC	1
ServiceD	2001	Addr_P1	3

The routing table on the CLIENT node CLIENT2 is as follows:

service number S	Target node N	Target address A	Shortest path length L
				ServiceA	2002	Addr_P2	3
ServiceB	2002	Addr_P2	3
				ServiceC	2002	Addr_P2	3
ServiceD	1003	AddrD	1

Assuming that the CLIENT node CLIENT1 requests a service with a service number of ServiceD, queries the routing table of the node to know that the next node on the shortest path is the PROXY node PROXY1, and the CLIENT node CLIENT1 forwards the data to the service address Addr _ P1 of the PROXY node PROXY 1. After receiving the data, the PROXY node PROXY1 checks the table according to the service number to know that the next node is the PROXY node PROXY2, and forwards the data to the corresponding service address Addr _ P2. After the PROXY node PROXY2 receives the request data, the next node is known to be the service end node SERVER3 by table lookup, and the next node is forwarded to the corresponding service address, and the service end processes the request data. The route forwarding links for the requested data are shown as arrows in fig. 5.

The service offline function module is configured to delete the service information from the micro service cluster and update the routing table information on each node when the service end does not provide a certain service to the outside any more.

When the server no longer provides a certain service to the outside, the service information needs to be deleted from the cluster, which is called service offline. The service is offline for two cases:

(1) the server side actively sends out a service offline notification

When the service end does not provide a certain service any more, a service offline notification is sent through a broadcast channel, and the service offline notification contains routing information (S, N, A, L) related to the service, wherein S and A are a service number and a service address of the service to be offline, N is a node number of the service end, and L is fixed to 0.

After receiving the service offline message, the client and the proxy node in the same domain search whether the record of (S, N, A, L +1) exists in the routing table of the node, and if so, delete the record from the routing table.

For the case of cross-domain deployment, the proxy node will also receive and process service logoff messages from connected cross-domain proxy nodes. If the agent node successfully processes the service offline message and deletes a corresponding record (S, N, A, L), the agent node needs to simultaneously send a service offline notification (S, N _ PROXY, A _ PROXY, L) to the local domain UDP broadcast channel and other connected cross-domain agent nodes, wherein N _ PROXY and A _ PROXY are the node number and the service address of the agent node.

As shown in fig. 6, if the SERVER node SERVER1 in the cluster needs to take the ServiceB service down, the node needs to broadcast a down notification (ServiceB,1001, AddrB,0) in the UDP channel.

After receiving the offline notification, the CLIENT node CLIENT1 in the domain deletes the relevant record, and the routing table is updated as follows:

after receiving the offline notification, the PROXY node PROXY1 in the domain deletes the relevant record, and the routing table is updated as follows:

meanwhile, the PROXY node PROXY1 will send a offline notification message (ServiceB, 2001, Addr _ P1,1) to the connected cross-domain PROXY node PROXY2, and after the PROXY node 2 receives the message, the routing table is updated as follows:

finally, the PROXY node PROXY2 will send a service down message (ServiceB, 2002, Addr _ P2,2) on the broadcast channel in the domain DomainB, and after the CLIENT node CLIENT2 receives the message, the routing table is updated as follows:

(2) unexpected exit of server

If the server-end node fails to cause unexpected exit, the server-end node cannot actively send out the service offline notification. When the server exits, the TCP connection it establishes with the client and the proxy node will also automatically disconnect.

If the client detects that the connection with the service end node or the proxy node is disconnected, the routing record containing the service end node is deleted from the routing table.

The service calling mode in the micro-service cluster is a request-response mode, a client node initiates a service request, and request data is finally forwarded to a corresponding service end node according to the routing table information on each node. The service end node calls the corresponding service processing function to process the request, and sends the generated response data back to the client node. When the request is forwarded, each node on the path through which the request passes records the source address of the request data, and returns according to the original route of the routing path of the request data when the response data is forwarded. As shown in fig. 6, the response will be returned back along the requested path.

The service request and service response module is configured to implement service invocation in the micro-service cluster in a request-response manner.

The service calling mode in the micro-service cluster is a request-response mode, a client node initiates a service request, and request data is finally forwarded to a corresponding service end node according to the routing table information on each node. The service end node calls the corresponding service processing function to process the request, and sends the generated response data back to the client node. When the request is forwarded, each node on the path through which the request passes records the source address of the request data, and returns according to the original route of the routing path of the request data when the response data is forwarded. As shown in fig. 7A and 7B, the response will be rerouted back along the requested path.

While, for purposes of simplicity of explanation, the methodologies are shown and described as a series of acts, it is to be understood and appreciated that the methodologies are not limited by the order of acts, as some acts may, in accordance with one or more embodiments, occur in different orders and/or concurrently with other acts from that shown and described herein or not shown and described herein, as would be understood by one skilled in the art.

Those of skill would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

The various illustrative logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In the alternative, the processor and the storage medium may reside as discrete components in a user terminal.

In one or more exemplary embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software as a computer program product, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a web site, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, Digital Subscriber Line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Disk (disk) and disc (disc), as used herein, includes Compact Disc (CD), laser disc, optical disc, Digital Versatile Disc (DVD), floppy disk and blu-ray disc where disks (disks) usually reproduce data magnetically, while discs (discs) reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

The previous description of the disclosure is provided to enable any person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other variations without departing from the spirit or scope of the disclosure. Thus, the disclosure is not intended to be limited to the examples and designs described herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A low-delay micro-service route management system is characterized in that the system is used for carrying out route management on nodes on a micro-service cluster, the nodes of the micro-service cluster comprise a server, a client and a proxy node, a service route table is stored in each node in the micro-service cluster, service routes including forwarding service requests initiated by the client nodes to corresponding service addresses are realized by inquiring the service route tables on the nodes, and the system comprises a service discovery function module, a service offline function module and a service request and service response function module, wherein:

the service request and service response function module is configured to realize service calling in the micro-service cluster in a request-response mode;

the service routing table is established by each node after the micro service cluster is started, and the nodes update respective service routing tables in real time: each node in the same domain receives service routing information through a multicast channel, and records of a service routing table are exchanged among local area networks through proxy nodes; one record in the service routing table is (S, N, a, L), where S is the service number, N is the node number, a is the service address, and L is the path length, and the meaning of the record is: the shortest path length from the node to the service number S is L, the next node on the shortest path is N, the corresponding service address is A, the request data is forwarded to the address A, the node number N points to the next node of the path, the next node comprises an agent node or a service end node, and in the service routing table, for the same service number S, only the route with the shortest path length is recorded in the service routing table.

2. The low latency microservice routing management system of claim 1, wherein the service discovery function module comprises a single domain service discovery unit configured to:

after receiving the routing table record (S, N, A, L) broadcasted by the server, the proxy node and the client node in the same domain as the server node do the following processing: (1) searching a routing table of the node, judging whether a record of the service number S exists or not, and if the record of the service number S does not exist, inserting a record of (S, N, A, L +1) into the routing table of the node; (2) if the routing table of the node has the original record, taking out the original record (S, N ', A', L '), and if L +1> is L', the routing table does not need to be updated; if L +1< L', the original record is updated to (S, N, A, L + 1).

3. The system according to claim 2, wherein the service discovery function module comprises a cross-domain service discovery unit configured to:

4. The routing management system of the micro service with low latency of claim 3, wherein the processing configuration of the service offline function module for the server to actively send the service offline notification is as follows:

5. The routing management system of claim 4, wherein the service logoff function module is configured to process unexpected exit of the service end as follows:

6. The system of claim 5, wherein the service request and service response function module further configures the following for processing the service invocation mode: