A High-Performance Microservice Differentiated Domain Communication Method Based on Adaptive Strategies

Abstract

This invention discloses a high-performance microservice differentiated domain communication method based on an adaptive strategy: On the client side, dynamic proxies and annotation configuration rules are used to transmit information about the server-side methods that need to be called locally to different domain servers (i.e., local or remote domain servers) pointed to by the domain allocation strategy. On the server side, the service provider provides the API services that need to be published externally according to the annotation configuration rules and the service center, thereby realizing communication interaction between the local domain server and the client, or between the remote domain server and the client. This invention can effectively improve service communication performance by dividing services into different domain communication domains according to the different service communication needs in a microservice development architecture through technologies such as domain allocation strategies and annotation configuration rules.

Description

Technical Field

[0001] This invention relates to the field of data transmission in microservice development architectures, and more specifically, to a high-performance microservice differentiated domain communication method based on an adaptive strategy. Background Technology

[0002] With the rapid development of the internet and information technology, the complexity and scale of software applications are increasing daily. To address this challenge, software development architecture, as the structure and pattern adopted when building and organizing software systems, is widely used in various aspects of economic development, public affairs management, and public social services, including finance and insurance, traffic management, energy conservation and environmental protection, logistics and retail, and is attracting increasing attention from developers and researchers. Microservices software development architecture, as a novel parallel development architecture, is gradually becoming a popular trend in the software development field. It is an architectural style that breaks down applications into multiple small, independent services. Each service can be deployed, scaled, and maintained independently, and collaborates through lightweight communication mechanisms. Furthermore, microservices development architecture supports agile development and continuous integration deployment practices, thereby accelerating the development cycle and meeting the demands of modern businesses for rapid iteration and high availability.

[0003] However, this hierarchical design of microservice software development architecture also introduces significant challenges to distributed systems. Improving service communication performance within microservice architectures has been a hot topic and key issue in researchers' studies of scalability. Especially in the diverse scenarios of microservice software development architectures, service communication algorithms for a single scenario cannot adapt to the communication needs of multiple scenarios. Therefore, a high-performance service communication method that can adapt to different application scenarios is needed in the service communication algorithms of microservice software development architectures.

[0004] To date, numerous technologies have been proposed to improve the performance of service communication in microservice software development architectures. These include optimizing container network performance (such as improving NAT mechanisms and shared memory technology), adopting efficient communication protocols (such as gRPC and Thrift replacing REST), designing intelligent service allocation algorithms (such as interactively aware deployment and asynchronous communication modes), introducing middleware optimization (such as message queues and streaming platforms), event-driven architecture, and remote procedure call multiple (RPCM) methods for microservices. These methods can significantly reduce latency and improve throughput in different scenarios. RPCM employs different network communication models depending on the service's domain: local domain service communication uses the AF_UNIX domain communication model, while remote domain service communication uses the gRPC domain communication model. Developers can manually change the domain communication strategy according to service communication performance requirements. However, under current technology, service communication often suffers from insufficient stability in high-load scenarios, and the impact mechanism of service partitioning and scheduling strategies on performance is not yet fully clear. Especially in the diverse scenarios of microservice software development architecture, service communication technology under a single scenario cannot adapt to the communication needs of multiple scenarios. For example, RPCM requires developers to manually set different service communication strategies according to service performance requirements. Therefore, in the service communication methods of microservice software development architecture, there is a need for a high-performance service communication method that can adapt to communication under different application scenarios. Summary of the Invention

[0005] To overcome the shortcomings of existing technologies, this invention proposes a high-performance microservice differentiated domain communication method based on adaptive strategies, applicable to different application scenarios in microservice development architectures. This method can divide services into different domains for communication based on different service communication needs in microservice development architectures through domain allocation strategies, annotation configuration rules, and other technologies, effectively improving service communication performance.

[0006] The objective of this invention is achieved through the following technical solutions.

[0007] A high-performance microservice differentiated domain communication method based on adaptive strategies includes:

[0008] In the client, dynamic proxies and annotation configuration rules are used to pass the information of the server-side methods that need to be called locally to the different domain servers pointed to by the domain allocation strategy, namely the local domain server or the remote domain server.

[0009] On the server side, the service provider provides API services that need to be published to the outside world according to the annotation configuration rules and the service center, thereby realizing the communication and interaction between the local domain server and the client, or the service communication and interaction between the remote domain server and the client.

[0010] Furthermore, the client's domain allocation strategy is as follows: When the client and server need to communicate, the system first checks whether the client only has local domain nodes in its configuration file. If only local domain nodes exist, the service communication adopts the local domain communication mode. Otherwise, it checks whether the client's annotation configuration rules only contain local domain annotations. If only local domain annotations exist, the service communication adopts the local domain communication mode. Otherwise, it automatically detects the domain mode and determines whether to use the local domain communication mode or the remote domain communication mode.

[0011] Furthermore, the automatic detection domain allocation strategy of the automatic detection domain mode consists of the following four parts in descending order of priority: judgment of the same region between the client and the server, judgment of the same subnet, judgment of network latency, and judgment of network hop count;

[0012] ① Same region judgment: If the region information of the client and the server are the same, it is determined that the client and the server are in the same region. At this time, it is determined that the client and the server use the local domain communication mode. Otherwise, proceed to the next step of same subnet judgment.

[0013] ② Same subnet determination: When the result of the bitwise AND operation between the client IP and the subnet mask is equal to the result of the bitwise AND operation between the server IP and the subnet mask, it is determined that the client and server IP addresses are in the same subnet. At this time, it is determined that the client and server are using local domain communication mode. Otherwise, proceed to the next step of network latency determination.

[0014] ③ Network latency judgment: When the network latency between the client and the server is less than or equal to the set network latency threshold, it is determined that the client and the server are using local domain communication mode; otherwise, the next step of network hop count judgment is performed.

[0015] ④ Network hop count determination: When the network hop count between the client and the server is less than or equal to the set network hop count threshold, it is determined that the client and the server are using local domain communication mode; otherwise, it is determined that the client and the server are using remote domain communication mode.

[0016] Furthermore, the annotation configuration rules for both the local domain server and the remote domain server adopt the annotation configuration rules for the microservice differentiated domain communication method server; the annotation configuration rules for the client are to add auto-detect domain annotations and local domain annotations to the annotation configuration of the client class in the microservice differentiated domain communication method client annotation configuration rules, and convert these two types of annotations into the corresponding auto-detect domain class structure and local domain client class structure;

[0017] The parameters of the automatic detection domain annotation include a network latency threshold and a network hop count threshold, which are used to determine the network latency level and the network hop count in the automatic detection domain allocation strategy, respectively.

[0018] The parameters of the local domain annotation include: local address, registration port number, service port number, Socket prefix, and Socket suffix. In the automatic domain allocation detection strategy, when the client and server are detected to be in local domain communication mode, the parameters in the local domain annotation are applied. In addition, the local domain annotation can be configured as a separate annotation for the client class. When the local domain annotation appears alone, it has higher priority than the automatically detected domain annotation, and in this case, the client and server are considered to be in local domain communication mode.

[0019] The parameter types of the automatic detection domain class structure correspond one-to-one with the parameter types of the automatic detection domain annotation, and the parameter types of the local domain client class structure correspond one-to-one with the parameter types of the local domain annotation.

[0020] Furthermore, the configuration file adds an auto-detection domain node to the microservice differentiated domain communication method configuration file. The auto-detection domain node contains attribute parameters that correspond one-to-one with the annotation configurations and class structures added in the client annotation configuration rules.

[0021] Compared with the prior art, the beneficial effects of the technical solution of the present invention are:

[0022] The high-performance microservice differentiated domain communication method proposed in this invention, based on an adaptive strategy, features high-performance service communication. Based on an automatic detection and allocation strategy for service communication domains, this method exhibits strong adaptability and can be applied to data communication between different services in various application scenarios, significantly improving the performance of service data communication in microservice development architectures. Addressing the communication needs between different services in a microservice development architecture, this invention can quickly allocate communication domains and facilitate service communication within different domains. Its service communication domain partitioning demonstrates good adaptability, effectively enhancing service communication performance.

[0023] This invention presents a high-performance microservice differentiated domain communication method based on an adaptive strategy. It adaptively divides communication domains for different services. The technology used for service communication, whether assigned to a local domain or a remote domain, can be any existing service communication technology, including but not limited to AF_UNIX domain communication, Google's remote procedure call technology gRPC domain communication, and microservice communication technology based on remote procedure call (Remote Procedure Call EXplore, RPCX). Attached Figure Description

[0024] Figure 1 This is a schematic diagram of the high-performance microservice differentiated domain communication method based on adaptive strategies of the present invention.

[0025] Figure 2 This is a flowchart of the domain allocation strategy in this invention.

[0026] Figure 3 This is a schematic diagram of the annotation configuration rules for the client in this invention.

[0027] Figure 4 The automatic detection domain class structure and local domain client class structure are examples of the present invention. Detailed Implementation

[0028] The present invention will now be further described with reference to the accompanying drawings.

[0029] This invention proposes a high-performance microservice differentiated domain communication method (Adaptive Remote Procedure Call, RPC-AD) based on an adaptive strategy, which is used for high-performance service communication in microservice development architectures under different application scenarios.

[0030] like Figure 1 As shown, the overall architecture of the high-performance microservice differentiated domain communication method based on adaptive strategy of the present invention consists of three key substructures: client communication branch, local domain server communication branch, and remote domain server communication branch.

[0031] Based on this architecture, this invention introduces a domain allocation strategy in the client, enabling it to adaptively differentiate between domains. This allows the client to automatically use different communication modes for communication with the server based on the server's domain. Specifically, in the client, dynamic proxies and annotation configuration rules are used to pass the information of the server-side methods that need to be called locally to the different domain servers pointed to by the domain allocation strategy, i.e., the local domain server or the remote domain server.

[0032] On the server side, service providers, based on annotation configuration rules and the service center, provide API services (APIs—Application Programming Interfaces) that need to be published externally, thereby enabling communication and interaction between the local domain server and the client, or between the remote domain server and the client. The server-side annotation configuration rules are used to disguise and control the publicly published API service information. When developers do not want others to know the true information of the publicly published API service, they can change information such as the service name on the server through annotation configuration, thus ensuring information security by changing the publicly disclosed service name. The server-side service center has functions such as controlling startup and shutdown, and obtaining service port numbers. Both the local domain server and the remote domain server adopt the existing microservice differentiated domain communication method (RPCM—Remote Procedure Call Multiple, hereinafter referred to as RPCM) server-side annotation configuration rules. In the RPC-AD method of this invention, after the service communication is assigned to a domain, it is either a local domain service communication or a remote domain service communication according to the domain to which it belongs. That is, the AF_UNIX domain communication model is used in the local domain service communication, and the gRPC domain communication model is used in the remote domain service communication. Its communication principle is consistent with the existing technology RPCM.

[0033] 1. Client-side domain allocation strategy

[0034] To achieve adaptability for communication with differentiated domain services, this invention proposes a client domain allocation strategy. The domain allocation strategy process is as follows: Figure 2 As shown. When the client and server need to communicate, the system first checks whether the client only has local domain nodes in its configuration file. If only local domain nodes exist, the service communication adopts the local domain communication mode. Otherwise, it needs to further determine whether the client's annotation configuration rules only contain local domain annotations. If only local domain annotations exist, the service communication adopts the local domain communication mode. Otherwise, it needs to automatically detect the domain mode and determine whether to use the local domain communication mode or the remote domain communication mode.

[0035] The RPC-AD method of this invention prioritizes user-manually configured network communication modes. If the user has manually configured a network communication mode, i.e., a local domain communication mode, then the user-manually configured network communication mode will be used directly. The RPC-AD method of this invention can also exist in the form of a configuration file. When the user has enabled a local domain communication node in the configuration file, the RPC-AD method of this invention will also prioritize the user-manually configured network communication mode. When both configuration files and annotation-based configuration methods exist, the configuration file method will be used first.

[0036] When the user has not configured a local domain annotation or a local domain node in the configuration file, the RPC-AD method of this invention automatically detects the domain mode, determining whether to use local domain communication mode or remote domain communication mode. The automatic domain allocation strategy for automatic domain mode detection consists of the following four parts in descending order of priority: judgment of the same region between the client and the server, judgment of the same subnet, judgment of network latency, and judgment of network hop count.

[0037] ① Judgment of the same area

[0038] The same region determination is achieved by obtaining region information through service centers such as Consul and etcd. If the region information of the client and the server is the same, such as the same container identification information, the same deployment metadata, or the same tag, then the client and the server are determined to be in the same region. In this case, it is determined that the client and the server are using the local domain communication mode. Otherwise, the next step of determining the same subnet is performed.

[0039] The determination of the same region is shown in formula (1):

[0040] (1)

[0041] In the formula, SameRegion indicates whether the client and server are in the same region. 1 indicates that the client and server are in the same region, that is, the client and server are in the same local region. 0 indicates that the client and server are not in the same region, and in this case, it is necessary to determine whether they are in the same subnet. and These represent the deployment domain information (i.e., region information) in the client and server respectively. If they are the same, then... =1, if different then =0.

[0042] ② Same subnet judgment

[0043] The subnet determination uses the subnet mask, and a bitwise AND operation is used to determine whether the client and server IP addresses are in the same subnet. If the result of the bitwise AND operation between the client's IP address and the subnet mask equals the result of the bitwise AND operation between the server's IP address and the subnet mask, then the client and server IP addresses are determined to be in the same subnet, and local area communication mode is used between them. Otherwise, the next step, network latency determination, is performed.

[0044] The determination of the same subnet is shown in formula (2):

[0045] (2)

[0046] In the formula, SameSubnet indicates whether the client and server IP addresses are in the same subnet. 1 indicates they are in the same subnet, meaning the client and server are in the same local domain; 0 indicates they are not in the same subnet, in which case network latency needs to be checked. mask represents the subnet mask. This indicates that a bitwise AND operation is performed between the client IP address and the subnet mask. This indicates that a bitwise AND operation is performed on the server IP and subnet mask. If the results of the two bitwise AND operations are equal, it means that the client and the server are in the same local domain; otherwise, a network latency check is required.

[0047] ③ Network latency assessment

[0048] Network latency assessment uses network latency detection terminology to judge network performance, especially when the client and server are not in the same region or subnet. Low latency usually means they are in the same local area or a nearby network. When the network latency between the client and server is less than or equal to the set network latency threshold, it is determined that the client and server are using local area communication mode; otherwise, the next step, network hop count assessment, is performed.

[0049] Network latency is determined as shown in formula (3):

[0050] (3)

[0051] In the formula, SameLatency represents the network latency used to determine whether the client and server are in the local domain. SameLatency=1 indicates that the client and server are in the local domain, and SameLatency=0 requires network hop count determination. The set network latency threshold, For network latency, when the network latency is less than or equal to the set network latency threshold, ,otherwise In the RPC-AD method of this invention, the default settings are as follows: The threshold is also made available to developers, meaning that this threshold can be configured in annotation configuration rules and configuration files, and developers can configure the network latency threshold themselves.

[0052] ④ Network hop count determination

[0053] The network hop count determination is to determine whether the network hop count between the client and the server is less than or equal to the set network hop count threshold. If the network hop count between the client and the server is less than or equal to the set network hop count threshold, it is determined that the client and the server are using local domain communication mode (i.e., the client and the server belong to the same local domain). Otherwise, it is determined that the client and the server are using remote domain communication mode (i.e., the client and the server belong to the same remote domain).

[0054] The network hop count is determined as shown in formula (4):

[0055] (4)

[0056] In the formula, SameHopCount represents the network hop count. When SameHopCount=1, it means that the client and the server belong to the same local domain. When SameHopCount=0, it means that the client and the server belong to a remote domain. This represents the network hop count between the client and the server. This represents the set network hop count threshold. When the number of network hops between the client and the server is less than or equal to the set network hop count threshold, [the server will respond accordingly]. ,otherwise In the PRC-AD method of this invention, the default settings are as follows: Similar to network latency, the threshold is also made available to developers. This threshold can be configured in annotation configuration rules and configuration files, allowing developers to set the network hop count threshold themselves.

[0057] In the RPC-AD method of this invention, the four methods of automatically detecting domain allocation strategies also have priority design. Priority 1 is same-region judgment. If the client and server belong to the same region, they can be considered to belong to the local domain. This judgment method is designed as the first priority because the region usually represents the physical network distance, and the service registration system can explicitly provide region information. Priority 2 is same-subnet judgment. Same subnet means that the client and server are in the same local area network, and the latency is usually very low. This judgment follows the region judgment and can provide a more accurate network relationship. If the client and server are in the same subnet, there is usually no need to consider latency and hop count issues, so this method is designed as the second priority. Priority 3 is network latency judgment. Network latency detection is used to judge network performance, especially when the client and server are not in the same region and subnet. Low latency usually means that they are in the same wide area network or a network that is close to each other, so latency judgment is designed as the third priority. Priority 4 is network hop count judgment. Network hop count judgment is used to judge the network path length of the client and server and to determine whether they communicate through multiple intermediate devices. If the hop count is high, it indicates that the network distance between the client and the server is far. Therefore, this method is mainly suitable for further refining the judgment of the network path, and it usually only comes into play when other methods (such as same area judgment, same subnet judgment, network latency judgment) cannot determine the path.

[0058] Therefore, the priority design of the automatic detection domain allocation strategy is shown in formula (5):

[0059] (5)

[0060] In the formula, Domain represents the domain to which the client and server belong, whether it is a local domain or a remote domain. If If it returns directly to the local domain, otherwise it checks the next condition; if If the condition is not met, return directly to the local domain; otherwise, check the next condition. If the network latency is less than or equal to the threshold, return to the local domain; otherwise, check the next condition. If the network hop count is low, the system returns to the local domain; otherwise, it is determined to be a remote domain.

[0061] 2. Client-side annotation configuration rules

[0062] The specific details of the client-side annotation configuration rules are as follows: Figure 3 As shown, in the initial stage, relevant information is annotated in the form of annotations, including client annotations, method annotations, auto-detection domain annotations, and local domain annotations. In order to improve program performance and development convenience, the above annotations are converted into corresponding class structures one by one during the runtime stage, namely client class structure, method class structure, auto-detection domain class structure, and local domain client class structure.

[0063] The client annotation configuration rules are to add auto-detect domain annotations and local domain annotations to the annotation configuration of the client class in the existing RPCM client annotation configuration rules, and convert these two types of annotations into the corresponding auto-detect domain class structure and local domain client class structure.

[0064] The parameters of the automatic detection domain annotation include a network latency threshold and a network hop count threshold. As mentioned above, these thresholds are used to determine network latency and hop count in the automatic detection domain allocation strategy, respectively. Developers can add an automatic detection domain annotation to the client class and set the network latency and hop count thresholds in their parameters to control the network latency and hop count determinations in the automatic detection domain allocation strategy. These parameters are optional; if not set by the developer, the RPC-AD method configuration values ​​of this invention can default to these two parameters.

[0065] The parameters of the local domain annotation include: local address, registration port number, service port number, Socket prefix, and Socket suffix. In the automatic domain allocation detection strategy, when the client and server are detected to be in local domain communication mode, the parameters in the local domain annotation are applied. These parameters are also optional; they can be set by the developer or pre-configured by the method. If the developer does not set them, the RPC-AD method configuration values ​​of this invention can default to the parameters set by the local domain annotation. Furthermore, the local domain annotation can be configured independently as an annotation for the client class. When the local domain annotation appears alone, its priority is higher than the automatically detected domain annotation, indicating that the client and server are in local domain communication mode.

[0066] The parameter types of the automatically detected domain class structure are the same as those of the automatically detected domain annotations, and they correspond one-to-one, both being network latency threshold and network hop count threshold. The parameter types of the local domain client class structure are the same as those of the local domain annotations, and they correspond one-to-one, both being local address, registration port number, service port number, Socket prefix, and Socket suffix, such as... Figure 4 The example shown illustrates this. The methods within the class structure are standard GetSet methods, used to assign and retrieve values ​​to properties within this class structure.

[0067] 3. Configuration file

[0068] The operation mechanism of the client's annotation configuration rules in the RPC-AD method of this invention is the same as that of existing RPCM. Annotation configuration is static. To improve the flexibility of the RPC-AD program, a configuration file design is added. Developers can set corresponding parameters in the configuration file to control the parameters of RPC-AD. The configuration file of the RPC-AD method of this invention adds an automatic detection domain node to the existing RPCM configuration file, corresponding to the annotation configuration. The automatic detection domain node contains attribute parameters that correspond one-to-one with the annotation configurations and class structures added in the client's annotation configuration rules (specifically, the automatic detection domain node contains network latency attributes and network hop count attributes, as well as five local domain client sub-nodes: local address, registration port number, service port number, Socket prefix, and Socket suffix). This facilitates the mapping and conversion between the configuration file and the class structures in the annotation configuration rules. As shown in the previous section, the configuration file has higher priority than the annotation configuration settings. An example of the configuration file structure is shown below:

[0069] <?xml version=”1.0” encoding=”UTF-8” ?>

[0070] <rpc-ad>

[0071] <automaticdetectiondomain latencynum="””" hopnum="””">

[0072] <domainclient localaddress="” / tmp”" registerport="”100001”" serverport="”100002”" socketprefix="””" sockersuffix="”” / ">

[0073] < / domainclient> < / automaticdetectiondomain>

[0074] OR

[0075] <domainclient localaddress="” / tmp”" registerport="”100001”" serverport="”100002”" socketprefix="””" sockersuffix="”” / ">

[0076] <mclient localClassName="””" remoteServerName="””" remoteServerAddress="””remoteServerPort=””" / >

[0077] <mmethod localMethodName="””" remoteMethodName="””" / >

[0078] <mserver serverClass="””" / >

[0079] < / domainclient>

[0080] The client pseudocode example in the RPC-AD method of this invention is shown below:

[0081] 1 Input: Request data Data; configuration file address profilePath;

[0082] 2 Output: ResultClass

[0083] 3 if ( profilePath != null ) {

[0084] 4 ConfigurationRules =getAnnotationConfigurationRules ( profilePath);}

[0085] 5 else {

[0086] 6 ConfigurationRules=traverseAnnotationConfigurationRules();}

[0087] 7 DomainClientStructure=convert(ConfigurationRules);

[0088] 8 MClientAnnotationStructure=convert(ConfigurationRules);

[0089] 9 MethodAnnotationStructure=convert(ConfigurationRules);

[0090] 10 if ( DomainClientStructure is exist ){

[0091] 11 ObjectRegistry(DomainClientStructure, MClientAnnotationStructure,MethodAnnotationStructure);

[0092] 12 ResultClass=ClientStub.sendByLocal(Data);}

[0093] 13 else{

[0094] 14 AutomaticDetectionDomainRules=checkRegion() or checkSubnet orcheckLatency(latencyNum) or checkHopCount(hopNum);

[0095] 15 utomaticDetectionDomainStructure=convert(AutomaticDetectionDomainRules);

[0096] 16 if(DomainType(AutomaticDetectionDomainStructure) LocalDomain){

[0097] 17 ResultClass=ClientStub.sendByLocal(Data);}

[0098] 18 else{

[0099] 19 ResultClass=ClientStub.sendByRemote(Data);}}

[0100] The first line of input is the request data Data and the optional configuration file address profilePath. Developers can omit the configuration file parameter. If no parameter is provided, the RPC-AD method of this invention will use the annotation configuration rule settings.

[0101] The second line outputs the class information ResultClass returned from the server;

[0102] Line 3 checks if the profile path parameter exists. If it does not exist, line 4 retrieves annotation configuration rule information. If the profile path parameter exists, line 6 converts the profile and retrieves annotation configuration rule information.

[0103] Line 7 converts the annotation configuration rules to the local domain client class structure;

[0104] Line 8 converts the annotation configuration rules to the client-side annotation class structure;

[0105] Line 9 converts annotation configuration rules to a method annotation class structure;

[0106] Line 10 determines whether the developer has provided a local domain client class structure. If so, it means that the developer requires the RPC-AD method of this invention to use the local domain communication mode. Then, line 11 registers the local domain object, namely the local domain client class structure, client annotation class structure, and method annotation class structure.

[0107] Line 12 uses the local domain communication mode to call the server class. The parameter is the requested data Data, and the server class information is returned.

[0108] If the developer has not set the local domain client class structure in line 13, then line 14 executes the automatic domain detection policy, the function to detect the same area, the function to detect the same subnet, the function to detect network latency (the parameter is the latency value, optional; if the developer does not fill in this value, then the RPC-AD method of this invention will give a default latency value), and the function to detect network hop count (the parameter is the hop count, optional; if the developer does not fill in this value, then the RPC-AD method of this invention will give a default hop count).

[0109] Line 15 converts the auto-detect domain strategy to an auto-detect domain class structure, which is then used as a parameter for the DomainType() function in line 16 to determine whether to execute on a local or remote domain. If it is determined to be a local domain, line 17 executes the call to the server class using local domain communication mode, with the request data as the parameter, and returns server information. Otherwise, line 19 executes the call to the server class using remote domain communication mode, with the request data as the parameter, and returns server information.

[0110] The server-side pseudocode of the RPC-AD method of this invention is consistent with the existing RPCM technology.

[0111] Although the functions and working processes of the present invention have been described above in conjunction with the accompanying drawings, the present invention is not limited to the specific functions and working processes described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of the present invention without departing from the spirit and scope of the claims, and all of these are within the protection scope of the present invention.

Claims

1. A high-performance microservice differentiated domain communication method based on an adaptive strategy, characterized in that, include: In the client, dynamic proxies and annotation configuration rules are used to pass the information of the server-side methods that need to be called locally to the different domain servers pointed to by the domain allocation strategy, namely the local domain server or the remote domain server. The client's domain allocation strategy is as follows: When the client and server need to communicate, the system first checks whether the client only has local domain nodes in its configuration file. If only local domain nodes exist, the service communication adopts the local domain communication mode. Otherwise, it checks whether the client's annotation configuration rules only contain local domain annotations. If only local domain annotations exist, the service communication adopts the local domain communication mode. Otherwise, it automatically detects the domain mode and determines whether to use the local domain communication mode or the remote domain communication mode. On the server side, the service provider provides API services that need to be published to the outside world according to the annotation configuration rules and the service center, thereby realizing communication and interaction between the local domain server and the client, or between the remote domain server and the client.

2. The high-performance microservice differentiated domain communication method based on adaptive strategy according to claim 1, characterized in that, The automatic detection domain allocation strategy of the automatic detection domain mode consists of the following four parts in descending order of priority: judgment of the same region between the client and the server, judgment of the same subnet, judgment of network latency, and judgment of network hop count. ① Same region judgment: If the region information of the client and the server are the same, it is determined that the client and the server are in the same region. At this time, it is determined that the client and the server use the local domain communication mode. Otherwise, proceed to the next step of same subnet judgment. ② Same subnet determination: When the result of the bitwise AND operation between the client IP and the subnet mask is equal to the result of the bitwise AND operation between the server IP and the subnet mask, it is determined that the client and server IP addresses are in the same subnet. At this time, it is determined that the client and server are using local domain communication mode. Otherwise, proceed to the next step of network latency determination. ③ Network latency judgment: When the network latency between the client and the server is less than or equal to the set network latency threshold, it is determined that the client and the server are using local domain communication mode; otherwise, the next step of network hop count judgment is performed. ④ Network hop count determination: When the network hop count between the client and the server is less than or equal to the set network hop count threshold, it is determined that the client and the server are using local domain communication mode; otherwise, it is determined that the client and the server are using remote domain communication mode.

3. The high-performance microservice differentiated domain communication method based on adaptive strategy according to claim 1, characterized in that, The annotation configuration rules for both the local domain server and the remote domain server adopt the annotation configuration rules for the microservice differentiated domain communication method server. The annotation configuration rules for the client are to add auto-detect domain annotations and local domain annotations to the annotation configuration of the client class in the microservice differentiated domain communication method client annotation configuration rules, and convert these two types of annotations into the corresponding auto-detect domain class structure and local domain client class structure. The parameters of the automatic detection domain annotation include a network latency threshold and a network hop count threshold, which are used to determine the network latency level and the network hop count in the automatic detection domain allocation strategy, respectively. The parameters of the local domain annotation include: local address, registration port number, service port number, Socket prefix, and Socket suffix; In the automatic detection domain allocation strategy, when the client and server are in local domain communication mode, the parameters in the local domain annotation are applied. In addition, the local domain annotation can be configured as a separate annotation for the client class. When the local domain annotation appears alone, it has higher priority than the automatic detection domain annotation. At this time, it is determined that the client and server are in local domain communication mode. The parameter types of the automatic detection domain class structure correspond one-to-one with the parameter types of the automatic detection domain annotation, and the parameter types of the local domain client class structure correspond one-to-one with the parameter types of the local domain annotation.

4. The high-performance microservice differentiated domain communication method based on adaptive strategy according to claim 1, characterized in that, The configuration file adds an auto-detection domain node to the microservice differentiated domain communication method configuration file. The auto-detection domain node contains attribute parameters that correspond one-to-one with the annotation configurations and class structures added in the client annotation configuration rules.

Images