A distributed service remote invocation method, system, device and storage medium

Abstract

The application discloses a kind of distributed service remote call method, system, device and storage medium.The method is by obtaining service call request, and according to the service call request determines target node, again the service call request is sent to the routing engine of the target node, then control the routing engine finds corresponding service information, and calls the service information.Through this method, service call request can be quickly sent to the routing engine of target node to carry out remote call of service, and cross-machine room remote call of distributed service is realized.This service calling mode effectively improves equipment access and management efficiency, reduces service call network delay caused by machine room deployment distance, and improves the success rate of service call.The application can be widely applied in the field of Internet of Things technology.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of Internet of Things, and in particular to a distributed service remote calling method, system and device and a storage medium. BACKGROUND

[0002] In related technologies, in order to improve the device access and management efficiency and reduce the data transmission delay, the related microservices are deployed in the same regional machine room as much as possible. However, with the continuous expansion of the business scale, the microservices carried by a regional machine room are more and more, and the management efficiency is continuously reduced. Customized services need to be called across machine rooms, which leads to the continuous increase of data transmission delay. Moreover, the cross-machine room calling based on the traditional microservice architecture is prone to calling failure due to the long interface response time for the scene of slightly large online access volume, large interface response body and network jitter. SUMMARY

[0003] The present application aims to at least partly solve one of the problems in the prior art.

[0004] To this end, one object of the present application is to provide a distributed service remote calling method, system, device and medium, which can realize the cross-machine room remote service calling of distributed microservices.

[0005] To achieve the above technical purposes, the technical solutions adopted by the embodiments of the present application include:

[0006] On the one hand, the embodiments of the present application provide a distributed service remote calling method, which includes the following steps:

[0007] Obtaining a service calling request;

[0008] Determining a target node according to the service calling request;

[0009] Sending the service calling request to the routing engine of the target node;

[0010] Controlling the routing engine to find corresponding service information;

[0011] Calling the service information.

[0012] Further, the target node includes a distributed node and a center node, and before the service calling request is obtained, the method further includes the following steps:

[0013] Obtaining routing information of the routing engine of the distributed node;

[0014] Registering services according to the routing information to obtain registration information of the routing engine of the distributed node;

[0015] Save the registration information to the database of the center node.

[0016] Further, the step of obtaining the routing information of the distributed node routing engine specifically includes:

[0017] After determining that the routing engine of the distributed node is started, the routing information of the routing engine of the distributed node is uploaded, wherein the routing information includes node area identification and node service name.

[0018] The routing engine of the center node obtains the routing information.

[0019] Further, after the step of saving the registration information to the database of the center node, the method further includes the following steps:

[0020] The routing engine of the center node listens to the registration information of the distributed node.

[0021] After determining that the registration information is changed, the changed registration information is synchronized to the database.

[0022] Further, the center node is further provided with an agent module, and after the step of calling the service information, the method further includes the following steps:

[0023] Obtain a broadcast request of the center node.

[0024] According to the broadcast request, determine the target distributed node that needs to be broadcasted.

[0025] Broadcast the target distributed node through the agent module.

[0026] Further, the step of determining the target node according to the service call request specifically includes:

[0027] According to the node area identification in the service call request, determine the target node.

[0028] Further, the step of controlling the routing engine to find the registered service information specifically includes:

[0029] According to the node service name in the service call request, find the corresponding service information.

[0030] On the other hand, the embodiment of the application provides a distributed service remote call system, which includes:

[0031] The first module is used for obtaining a service call request.

[0032] The second module is used for determining a target node according to the service call request.

[0033] The third module is configured to send the service call request to a routing engine of the target node.

[0034] The fourth module is configured to control the routing engine to search for registered service information.

[0035] The fifth module is configured to call the service information.

[0036] In another aspect, an embodiment of the present application provides a distributed service remote calling device, comprising:

[0037] at least one processor;

[0038] at least one memory configured to store at least one program;

[0039] When the at least one program is executed by the at least one processor, the at least one processor is caused to implement the distributed service remote calling method.

[0040] In another aspect, an embodiment of the present application provides a storage medium, wherein the storage medium stores processor-executable instructions, and the processor-executable instructions are used to implement the distributed service remote calling method when executed by a processor.

[0041] The present application discloses a distributed service remote calling method, which has the following advantages:

[0042] The embodiment obtains a service call request, determines a target node according to the service call request, sends the service call request to a routing engine of the target node, controls the routing engine to search for corresponding service information, and calls the service information. Through the method, the service call request can be quickly sent to the routing engine of the target node for remote calling of the service, and cross-machine room remote calling of the distributed service is realized. BRIEF DESCRIPTION OF DRAWINGS

[0043] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following introduces the drawings of the related technical solutions in the embodiments of the present application or the prior art. It should be understood that the drawings in the following introduction are only for the convenience of clearly describing some embodiments of the technical solutions in the present application, and other drawings can be obtained by those skilled in the art without creative labor on the basis of these drawings.

[0044] Figure 1 A module schematic diagram of a distributed Internet of Things platform provided by an embodiment of the present application;

[0045] Figure 2 A hardware structure schematic diagram of an Internet of Things node provided by an embodiment of the present application;

[0046] Figure 3 A flowchart of a distributed service remote invocation method provided by an embodiment of the present application is shown in FIG. 1.

[0047] Figure 4 A structural diagram of a distributed service remote invocation system provided by an embodiment of the present application is shown in FIG. 2.

[0048] Figure 5 A structural diagram of a distributed service remote invocation device provided by an embodiment of the present application is shown in FIG. 3.

[0049] Figure 6 A module diagram of another distributed Internet of Things platform provided by an embodiment of the present application is shown in FIG. 4. DETAILED DESCRIPTION

[0050] This part will describe the specific embodiments of the present application in detail, and the preferred embodiments of the present application are shown in the accompanying drawings, which serve to supplement the description in the text part of the specification and enable people to intuitively and visually understand each technical feature and the overall technical scheme of the present application, but it cannot be understood as a limitation on the protection scope of the present application.

[0051] In the description of the embodiments of the present application, several means one or more, the meaning of multiple is two or more, greater than, less than, more than, etc. are understood as not including the number, above, below, within, etc. are understood as including the number, "at least one" means one or more, "at least one of the following" and similar expressions mean any combination of these items, including any combination of single or multiple items. If there is a description of "first", "second", etc., it is only used to distinguish technical features for the purpose, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of indicated technical features or implicitly indicating the order of indicated technical features.

[0052] It should be noted that the terms such as setting, installing and connecting in the embodiments of the present application should be understood in a broad sense, and the skilled in the art can reasonably determine the specific meaning of the above terms in the embodiments of the present application in combination with the specific content of the technical scheme. For example, the term "connection" can be mechanical connection, electrical connection or can communicate with each other; it can be directly connected, or indirectly connected through an intermediate medium.

[0053] In the description of the embodiments of the present application, the description of the terms "one embodiment", "another embodiment" or "certain embodiments", "in the above embodiment" and the like means that the specific features, structures, materials or characteristics described in connection with the embodiments or examples are contained in at least two embodiments or embodiments of the present disclosure. In the present disclosure, the illustrative description of the above terms does not necessarily refer to the same embodiment or embodiment. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or embodiments as appropriate.

[0054] It should be noted that the technical features involved in each of the embodiments of the present application described below can be combined with each other as long as there is no conflict.

[0055] With the rapid development of the Internet of Things industry, the business demand of the Internet of Things platform has also experienced explosive growth. In the past, the Internet of Things open platform only needed to provide fast development, deployment and application management for Internet of Things application developers. Today, in the face of special and complex business scenarios, it is difficult to meet market demand. For improving the market competitiveness of the Internet of Things platform, realizing the efficiency of device access and management, reducing data transmission delay and the voice of individual customization is getting higher and higher.

[0056] At present, the improvement of device access and management efficiency and the reduction of data transmission delay mainly depend on communication network optimization and measures such as deploying related microservices in the same regional machine room as much as possible. But with the continuous expansion of business scale, the microservices carried by a regional machine room are more and more, and the efficiency of device access and management is continuously reduced. The cross-machine room call caused by the customized service demand of large customers leads to the continuous increase of data transmission delay. Moreover, the cross-machine room call realized based on the traditional microservice architecture is prone to call failure due to too long interface response time for scenes with slightly large online access volume, large interface response body, network jitter and the like.

[0057] Therefore, the present application proposes a distributed service remote calling method, system and device and storage medium. The service calling request is obtained, and the target node is determined according to the service calling request. Then the service calling request is sent to the routing engine of the target node. Then the routing engine is controlled to find the corresponding service information and call the service information. Through this method, the service calling request can be quickly sent to the routing engine of the target node for remote calling of the service, realizing the cross-machine room remote calling of the distributed service. This service calling method effectively improves the efficiency of device access and management, reduces the service calling network delay caused by the deployment distance of the machine room, and improves the success rate of service calling.

[0058] Reference Figure 1 ,Figure 1 In the embodiments of the present application, a distributed Internet of Things platform is provided, which comprises a center node 101, a distributed node 102 and a distributed node 103.

[0059] The center node 101 mainly comprises microservices mainly in terms of business and partial enabling capabilities, a service routing engine and a service registration center. The registration center mainly realizes registration and discovery of services. When the service deployed in the center node 103 is started, the domain name and port number of the service are registered in the registration center, and the center routing engine can discover the corresponding service in the registration center, and realize routing of service call requests through the route rule of SpringCloud Gateway.

[0060] The distributed node 102 and the distributed node 103 mainly comprise microservices mainly in terms of business and customized services, a service routing engine and a service registration center. Similar to the service forwarding process of the center node, the distributed node routing engine obtains the services of the distributed node in the registration center, and realizes routing of service call requests through the route rule of SpringCloud Gateway.

[0061] It can be understood that one or more distributed nodes can be set, which is not limited here.

[0062] It should be noted that only a part of the modules of the distributed Internet of Things platform is exemplarily given in the embodiments of the present application, and the distributed Internet of Things platform can further comprise other modules included in other existing distributed Internet of Things platforms to realize corresponding functions, which are not limited in detail.

[0063] Referring to Figure 2 , Figure 2 The hardware structure of the Internet of Things node related in the embodiments of the present application is shown in FIG. 2. In the embodiments of the present application, the Internet of Things node can comprise a processor 201 (for example, a central processing unit, CPU), a communication bus 202, an input port 203, an output port 204 and a memory 205. The communication bus 202 is used to realize connection and communication among these components; the input port 203 is used for data input; the output port 204 is used for data output, and the memory 205 can be a high-speed RAM memory or a stable memory (for example, a disk memory). The memory 205 can optionally be a storage device independent of the aforementioned processor 201. Those skilled in the art can understand that the hardware structure shown in FIG. 2 does not constitute a limitation on the present application, and can comprise more or fewer components than those shown in the figure, or combine certain components, or different component arrangements. Figure 2 The hardware structure shown in FIG. 2 does not constitute a limitation on the present application, and can comprise more or fewer components than those shown in the figure, or combine certain components, or different component arrangements.

[0064] With reference to the foregoing Figure 2 , Figure 2 The memory 205 as a readable storage medium in the foregoing embodiment can include an operating system, a network communication module, an application module, and a control program. In the foregoing embodiment, the network communication module is mainly used for connecting a server and performing data communication with the server; and the processor 201 can invoke the control program of the Internet of Things node stored in the memory 205 and execute the method for remote invocation of distributed services provided by the embodiment. Figure 2

[0065] Based on the distributed Internet of Things platform shown in Figure 1 and Figure 2 , as shown in Figure 3 , the embodiment provides a method for remote invocation of distributed services, which includes but is not limited to steps S301, S302, S303, S304, and S305:

[0066] S301, obtaining a service invocation request.

[0067] It should be noted that the embodiment needs to mark each service through a distributed node region identifier (regionId) and a distributed node service name (appID). The distributed node region identifier (regionId) is used to distinguish services on different distributed nodes; and the distributed node service name (appID) is used to distinguish different services. By marking the services through the distributed node region identifier (regionId) and the distributed node service name (appID), the origin and the service type of each service can be clearly distinguished, thereby facilitating the reporting and storage of the routing engine and service information of different nodes. A user can download a corresponding application program on various terminal devices, initiate a service invocation request through the corresponding application program, and then upload the service invocation request through an http protocol. The routing engine on the distributed node 102 or the distributed node 103 obtains the service invocation request sent by the user. Specifically, after the user downloads the corresponding application program, the user can perform some interactive operation (such as clicking, touching, gesture, input box input, drop-down menu selection, and the like) on the display interface of the application program to trigger a corresponding operation instruction to the background. After the background receives the operation instruction, the background responds and processes the operation instruction, and then sends the service invocation request to the distributed node 102 or the distributed node 103, and causes the display interface to display the corresponding processing result and the like.

[0068] S302, determining a target node according to the service invocation request.

[0069] Further, the step of determining a target node according to the service invocation request specifically includes:

[0070] ​According to the node area identifier in the service call request, the target node is determined.

[0071] In step S302, according to the node area identifier in the service call request, the target node is determined. Taking the center node 101 calling the distributed node service as an example, after the routing engine of the center node 101 receives the request, the routing information in the distributed node routing table can be queried according to the node area identifier (regionId) in the http request header, so as to determine the specific distributed node that needs to be routed, so as to route the service call request to the corresponding distributed node.

[0072] It can be understood that the center node service called by the distributed node is the same, and the corresponding node can be determined according to the data contained in the http request header.

[0073] S303, the service call request is sent to the routing engine of the target node.

[0074] According to the foregoing description, by analyzing the data contained in the http request header, the specific node that needs to be routed can be determined, and when the node that needs to be routed is determined, the routing engine on the node is used for sending.

[0075] S304, the routing engine is controlled to find the corresponding service information.

[0076] Optionally, the step of controlling the routing engine to find the corresponding service information specifically includes:

[0077] According to the node service name in the service call request, the corresponding service information is found.

[0078] The services (including the routing engine) in the present application are all registered in the Zookeeper registration center, and through the appID information encapsulated in the http protocol, the service type corresponding to the service call request can be determined by comparing with the service table.

[0079] S305, the service information is called.

[0080] According to the foregoing steps, the service type corresponding to the service call request and the target node have been determined. When the service type corresponding to the service call request and the target node are determined, the service can be called.

[0081] In order to better find the service corresponding to the service call request, the target node includes a distributed node and a center node, and before the service call request is obtained, the method further includes the following steps:

[0082] The routing information of the routing engine of the distributed node is obtained;

[0083] Registering a service according to the routing information to obtain registration information of the distributed node routing engine;

[0084] Saving the registration information into a database of the center node.

[0085] In this embodiment, all services are registered to the service registration center. Through this method, the center node routing engine and the distributed node routing engine can realize forwarding of service calling requests through the service proxy function of the SpringCloud Gateway after obtaining the corresponding services from the registration center. When the distributed node routing engine service of a region is started, the regionId, the appId and other information of the distributed node service of the region are reported to the center node routing engine through the service reporting function.

[0086] Optionally, the step of obtaining the routing information of the distributed node routing engine specifically includes:

[0087] Determining that the routing engine of the distributed node is started, and uploading the routing information of the routing engine of the distributed node, wherein the routing information includes a node region identifier and a node service name;

[0088] Controlling the routing engine of the center node to obtain the routing information.

[0089] In this embodiment, the routing information of the routing engine is obtained to facilitate calling in subsequent steps, complete registration of the routing engine information, and thus the corresponding service can be more quickly queried when remote service calling is performed.

[0090] Optionally, after the registration information is saved into the database of the center node, the method further includes the following steps:

[0091] Controlling the routing engine of the center node to listen to the registration information of the distributed node;

[0092] Determining that the registration information is changed, and synchronizing the changed registration information to the database.

[0093] Specifically, the center node routing engine accepts the service reporting request of the distributed node routing engine, registers the reporting information of the distributed node to the registration center, and synchronously updates the database. When the routing information of the distributed node is changed, the center node routing engine dynamically updates the previous reporting information through listening. In this way, the center node routing engine can obtain the corresponding distributed routing engine reporting information in real time from the database, and thus accurate routing of the center node service to the distributed node routing engine through the center node routing engine is realized.

[0094] Optionally, the center node is also provided with a proxy module, and after the service information is called, the method further includes the following steps:

[0095] Obtaining a broadcast request of the center node;

[0096] According to the broadcast request, determining a target distributed node that needs to be broadcasted;

[0097] Broadcasting the target distributed node through the proxy module.

[0098] Referring to Figure 6 When the center node 101 needs to broadcast to multiple distributed nodes, a proxy module can be set in the center node, that is, a broadcast proxy function of the routing engine is added between the center node service and the routing engine. The proxy module processes multiple regionId values transmitted by the center service call request and forwards them to the center node routing engine one by one, so as to realize service broadcast to each distributed node. The same as the service accessing a single node, after the routing engine receives the broadcast request, the routing information in the distributed node routing table is queried according to the node region identifier (regionId) in the http request header, so as to determine the specific distributed node that needs to be routed, so as to route the service call request to the corresponding distributed node.

[0099] In some embodiments, the process of the center node calling the distributed node service is as follows: through a series of processing of a custom annotation RouteParam, the distributed node region identifier (regionId) and the distributed node service name (appId) information are encapsulated in Feign. Finally, the center node service sends a request to the center node routing engine in the new encapsulated HTTP protocol; after the center node routing engine receives the request, the routing information in the distributed node routing table is queried according to the regionId in the http request header, so as to determine the specific distributed node that needs to be routed, and route the service call request to the corresponding distributed node routing engine; after the distributed node routing engine receives the request, the service information in the registry center is searched according to the appId in the http request header, and the request is forwarded to the related service through the SpringCloudGateway service proxy function.

[0100] Based on the foregoing description, taking the center node service calling the distributed node service as an example, as shown in Figure 3 The distributed service remote call method of the embodiment of the application specifically includes the following steps:

[0101] Obtaining routing information of the distributed node routing engine;

[0102] According to the routing information, service registration is performed to obtain registration information of the distributed node routing engine;

[0103] saving the registration information into a database of the center node;

[0104] obtaining a service call request;

[0105] determining a target node according to the service call request;

[0106] sending the service call request to a routing engine of the target node;

[0107] controlling the routing engine to find corresponding service information;

[0108] calling the service information.

[0109] Exemplarily, taking 3 nodes as an example, a center node with a region identifier of 1001 and two distributed nodes are distinguished by region identifiers of 1014 and 1074. The three nodes all introduce a service routing engine, encapsulate the node region identifier and app identifier information in the http protocol through a custom annotation, and when the service is instantiated, all microservices (including the routing engine) are registered to the ZooKeeper registration center. Usually, the center node service routing engine is started first. After the startup is completed, the distributed node service routing engine is started and the routing information (region identifier regionId, service identifier appId, predicate, filter, etc.) is reported, and the distributed routing engine service reporting is realized. The center node routing engine accepts the distributed node routing engine service reporting request, registers the routing information of the distributed node to the ZooKeeper registration center, and synchronously updates the database to realize service registration. The center node routing engine dynamically updates the routing information of SpringCloudGateway by listening to the registration information of the distributed node routing engine in the registration center, and realizes the routing update of the distributed node routing engine information to the center node routing engine. When the center node routing engine receives a service call request of the center node, the distributed node region information in the header spliced by the improved FeignClient function (custom annotation) is found from the database according to the corresponding service routing information, and the routing finding is realized. The service routing engine registered in the registration center uses the service proxy function of SpringCloudGateway to discover the services of each module and forward the services, and realizes service discovery. In this way, the service routing engine realizes the remote call of the cross-machine room service. Finally, the problem of microservice cross-machine room call is successfully solved. The platform localization service target is realized, the device access and management efficiency is effectively improved, the service call network delay caused by the deployment distance of the machine room is reduced, and the success rate of service call is improved.

[0110] From the above, the application obtains a service call request, determines a target node according to the service call request, sends the service call request to a routing engine of the target node, controls the routing engine to find corresponding service information, and calls the service information. Through this method, the service call request can be quickly sent to the routing engine of the target node for remote service calling, and cross-machine room remote calling of distributed services is realized. This service calling method effectively improves device access and management efficiency, reduces service calling network delay caused by machine room deployment distance, and improves service calling success rate.

[0111] With reference to Figure 4 The embodiment of the application provides a distributed service remote calling system, which comprises:

[0112] A first module 401 is configured to obtain a service call request.

[0113] A second module 402 is configured to determine a target node according to the service call request.

[0114] A third module 403 is configured to send the service call request to a routing engine of the target node.

[0115] A fourth module 404 is configured to control the routing engine to find registered service information.

[0116] A fifth module 405 is configured to call the service information.

[0117] The contents in the above method embodiments are applicable to the system embodiments, the system embodiments specifically realize the same functions as the above method embodiments, and achieve the same beneficial effects as the above method embodiments.

[0118] With reference to Figure 5 The embodiment of the application provides a distributed service remote calling device, which comprises:

[0119] At least one processor 501;

[0120] At least one memory 502 is configured to store at least one program.

[0121] When the at least one program is executed by the at least one processor 501, the at least one processor 501 is caused to implement Figure 3 The distributed service remote calling method shown in the figure.

[0122] The contents in the above method embodiments are applicable to the device embodiments, the device embodiments specifically realize the same functions as the above method embodiments, and achieve the same beneficial effects as the above method embodiments.

[0123] The embodiment of the present application further provides a storage medium, wherein the storage medium stores processor-executable instructions, and the processor-executable instructions are used for realizing the method for remote calling of the distributed service when executed by a processor. Figure 3 The distributed service remote calling method is shown.

[0124] The above is a specific description of the preferred embodiment of the present application, but the present application is not limited to the described embodiment, and those skilled in the art can make various equivalent modifications or replacements without departing from the spirit of the present application, and these equivalent modifications or replacements are all included in the scope defined by the claims of the present application.

Claims

1. A method for distributed service remote invocation, characterized in that, The method comprises the following steps: obtaining routing information of a distributed node routing engine; registering services according to the routing information to obtain registration information of the distributed node routing engine; storing the registration information in a database of a central node; obtaining a service call request; determining a target node according to the service call request; the target node comprises a distributed node and a central node, and the central node is provided with a proxy module; sending the service call request to a routing engine of the target node; controlling the routing engine to search for corresponding service information; calling the service information; obtaining a broadcast request of the central node; determining a target distributed node that needs to be broadcast according to the broadcast request; broadcasting the service call request to the target distributed node through the proxy module.

2. The method of claim 1, wherein, The step of obtaining the routing information of the distributed node routing engine specifically comprises: determining that the routing engine of the distributed node is started, and then uploading the routing information of the routing engine of the distributed node, wherein the routing information comprises a node area identifier and a node service name; controlling the routing engine of the central node to obtain the routing information.

3. The method of claim 1, wherein, After the registration information is stored in the database of the central node, the method further comprises the following steps: controlling the routing engine of the central node to listen to the registration information of the distributed node; determining that the registration information is changed, and synchronizing the changed registration information to the database.

4. The method of claim 1, wherein, The step of determining the target node according to the service call request specifically comprises: determining the target node according to a node area identifier in the service call request.

5. The method of claim 1, wherein, The step of controlling the routing engine to search for corresponding service information specifically comprises: searching for the corresponding service information according to a node service name in the service call request.

6. A distributed service remote invocation system, characterized by The method comprises: a first module configured to obtain routing information of a distributed node routing engine, register services according to the routing information to obtain registration information of the distributed node routing engine, store the registration information in a database of a central node, and obtain a service call request; a second module configured to determine a target node according to the service call request; the target node comprises a distributed node and a central node, and the central node is provided with a proxy module; a third module configured to send the service call request to a routing engine of the target node; a fourth module configured to control the routing engine to search for registered service information; a fifth module configured to call the service information, obtain a broadcast request of the central node, determine a target distributed node that needs to be broadcast according to the broadcast request, and broadcast the service call request to the target distributed node through the proxy module.

7. A distributed service remote invocation apparatus, characterized by comprising: The method comprises: at least one processor; at least one memory configured to store at least one program; when the at least one program is executed by the at least one processor, the at least one processor implements the distributed service remote call method according to any one of claims 1-5.

8. A computer-readable storage medium having stored therein instructions that are executable by a processor, the instructions comprising: The processor-executable instructions, when executed by the processor, implement the distributed service remote call method according to any one of claims 1-5.

Images