CN110557357A

CN110557357A - remote procedure call protocol self-adaption method, related device and server

Info

Publication number: CN110557357A
Application number: CN201810554879.2A
Authority: CN
Inventors: 李书旭; 魏哲
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2018-05-31
Filing date: 2018-05-31
Publication date: 2019-12-10
Anticipated expiration: 2038-05-31
Also published as: WO2019228515A1; CN110557357B; CN115426391A

Abstract

The embodiment of the application provides a remote procedure call protocol self-adaption method, a related device and a server, wherein the method comprises the following steps: the client sends a first request message to a registry, and the registry stores a communication address and a supported communication protocol of a service end where each service in a plurality of services is located; the client receives a communication address of the first server and a supported communication protocol sent by the registration center; the client selects a first communication protocol supported by both the client and the first service end from communication protocols supported by the client and communication protocols supported by the first service end according to a preset selection strategy; the client calls the first service according to the first communication protocol and the communication address of the first service end. By adopting the embodiment of the application, the appropriate communication protocol can be adaptively selected for calling between services.

Description

Remote procedure call protocol self-adaption method, related device and server

Technical Field

the present application relates to the field of computer technologies, and in particular, to a remote procedure call protocol adaptation method, a related apparatus, and a server.

Background

Remote Procedure Call (RPC) is a common communication mechanism and development method for a distributed system, and allows a developer to Call a Remote service as a local service, and a caller is transparent to details such as network communication, parameter coding, and the like, even without sensing the deployment location of the Remote service. RPC provides powerful remote calling capability and simultaneously does not lose the semantic simplicity of local calling, thereby being widely applied in the field of distributed computing, in particular to a service architecture. The individual services in a distributed system typically discover each other by naming the services. Fig. 1 is a schematic diagram of a RPC in a prior art, where the RPC includes a service consumer (consumer), a service provider (provider), a service operation container (container), a registry (registry), and a monitoring center (monitor), and a flow of the RPC includes:

1. the service operation container starts, loads and operates a service provider;

2. After the service provider starts, the service provider registers the service available by itself to the registration center, and the registered information includes but is not limited to: information such as an Internet Protocol Address (IP) and a port exposed to the outside;

3. The service consumer subscribes to the service required by the service consumer after starting, which can be called target service.

4. The registry transmits the registration information of the service provider providing the target service to the service consumer, and if the information of the target service is changed, the registry transmits the changed information to the service consumer.

5. The service consumer selects one service provider from the service providers fed back by the registration center to call the target service based on a load balancing algorithm, and selects another service provider to call the target service if the call fails.

6. the service consumer and the service provider accumulate the calling times and calling time of each service in the memory, and send the statistical data to the monitoring center according to the preset time period so as to control the calling condition of each service.

at present, a service consumer needs to communicate based on a communication protocol when invoking a service from a service provider, and it is currently practiced that at least one communication protocol is configured on the service consumer in advance for each service, and when a communication protocol supported by a certain service provider is updated (for example, upgraded), the service consumer cannot perceive the communication protocol, which may cause that the service consumer cannot subsequently invoke a service provided by the certain service normally by using the updated communication protocol. That is, the communication protocol in the prior art may be configured in such a way that the service consumer cannot normally invoke the service from the service provider.

disclosure of Invention

The embodiment of the application discloses a remote procedure call protocol self-adaption method, a related device and a server, which can self-adaptively select a proper communication protocol for calling between services.

In a first aspect, an embodiment of the present application provides a remote procedure call protocol adaptive method, where the method includes:

the method comprises the steps that a client sends a first request message to a registry, and the registry stores a communication address of a service end where each service in a plurality of services is located and a supported communication protocol; the first request message is used for requesting a communication address of a first service end where a first service in the plurality of services is located and a communication protocol supported by the first service end;

the client receives the communication address of the first server and the supported communication protocol sent by the registry;

The client selects a first communication protocol supported by both the client and the first server from communication protocols supported by the client and communication protocols supported by the first server according to a preset selection strategy;

And the client calls the first service according to the first communication protocol and the communication address of the first service end.

by executing the method, the client sends a first request message to the registry, the registry sends the communication address and the supported communication protocol of the first service end to the client according to the first request message, then the client screens out the first communication protocol supported by both the client and the first service end according to a preset selection strategy, and then the client calls the first service according to the first communication protocol and the communication address of the first service end. In the process, the client can adaptively select a proper communication protocol to communicate with the first service end according to the selection strategy, and the selection scheme of the communication protocol is optimized.

in yet another alternative, the method includes: and the client updates the selection strategies, and different selection strategies have different specified screening rules. Thus, when that type of protocol is required, a corresponding selection policy may be selected first, and then the required communication protocol may be selected by the selection policy.

in yet another optional scenario, after the client invokes the first service according to the first communication protocol and the communication address of the first service, the method further includes: and the client receives change information of the first service end, which is sent by the registry, wherein the change information comprises a communication address and/or a supported communication protocol. In this way, even if the information relating to the first service is changed, the client can still smoothly call the first service.

in a second aspect, an embodiment of the present application provides a remote procedure call protocol adaptation method, where the method includes:

the method comprises the steps that a client sends a first request message to a registry, and the registry stores a communication address of a service end where each service in a plurality of services is located and a supported communication protocol; the first request message is used for requesting a communication address of a first service end where a first service in the plurality of services is located, and the first request message carries a communication protocol supported by the client;

The client receives a first communication protocol and a communication address of the first service end, which are sent by the registry, wherein the first communication protocol is supported by both the client and the first service end;

by executing the method, the client sends a first request message to the registry, the registry determines a first communication protocol supported by both the client and the first service according to the first request message and information registered to the registry by each service, then sends the first communication protocol and a communication address of the first service to the client, and then the client calls the first service according to the first communication protocol and the communication address of the first service. In the process, the registry can adaptively select a proper communication protocol according to the selection strategy for the client to communicate with the first server, so that the selection scheme of the communication protocol is optimized.

in a third aspect, an embodiment of the present application provides a remote procedure call protocol adaptive method, where the method includes:

a registry receives a first request message sent by a client, wherein the registry stores a communication address and a supported communication protocol of a service end where each service in a plurality of services is located; the first request message is used for requesting a communication address of a first service end where a first service in the plurality of services is located and a communication protocol supported by the first service end;

the registry sends the communication address of the first server and the supported communication protocol to the client; the communication protocol supported by the first service end is used for determining a first communication protocol, and the first communication protocol is supported by both the client and the first service end; the first communication protocol and the communication address of the first service end are used for the client to call the first service from the first service end.

In another optional scheme, before the registration center receives the first request message sent by the client, the method further includes: the registry receives the communication address of the first service end and the supported communication protocol sent by the first service end; the registry stores the communication address of the first service end and the supported communication protocol. It can be understood that the first service registers the related information of the first service to the registry, so that the registry can provide the information of the first service to other services, so that the other services can smoothly call the first service.

in yet another optional scenario, after the registering center sends the communication address of the first server and the supported communication protocols to the client, the method further includes: the registry receives change information of the first service end sent by the first service end, wherein the change information comprises a communication address and/or a supported communication protocol; and the registry sends the change information of the first service terminal to the client terminal. In this way, even if the information relating to the first service is changed, the client can still smoothly call the first service.

in a fourth aspect, an embodiment of the present application provides a remote procedure call protocol adaptive method, where the method includes:

A registry receives a first request message sent by a client, wherein the registry stores a communication address and a supported communication protocol of a service end where each service in a plurality of services is located; the first request message is used for requesting a communication address of a first service end where a first service in the plurality of services is located, and the first request message carries a communication protocol supported by the client;

The registry determines a communication protocol supported by a communication address of the first service end, and selects a first communication protocol supported by both the first service end and the client from the communication protocol supported by the first service end and the communication protocol supported by the client according to a preset selection strategy;

And the registry sends the first communication protocol and the communication address of the first service end to the client, and the first communication protocol and the communication address of the first service end are used for the client to call the first service from the first service end.

in yet another alternative, the method includes: and the registry updates the selection strategies, and different selection strategies have different specified screening rules. That is, the selection policy is centrally maintained by the registry, so that when the criteria of the selection policy need to be transformed, it can be implemented by modifying the selection policy directly at the registry, and then whichever service requests the supported communication protocol of the first service can obtain the communication protocol satisfying the latest criteria from the registry. Namely, the selection strategy is centrally maintained in the registry, so that the maintenance cost is greatly reduced.

in a fifth aspect, an embodiment of the present application provides a client, where the client includes:

A communication unit, configured to send a first request message to a registry, where the registry stores a communication address and a supported communication protocol of a service end where each of a plurality of services is located; the first request message is used for requesting a communication address of a first service end where a first service in the plurality of services is located and a communication protocol supported by the first service end;

the communication unit is further configured to receive a communication address of the first server and a supported communication protocol sent by the registration center;

The processing unit is used for selecting a first communication protocol supported by both the client and the first service terminal from the communication protocols supported by the client and the communication protocols supported by the first service terminal according to a preset selection strategy;

the processing unit is further configured to invoke the first service according to the first communication protocol and the communication address of the first service end.

it can be seen that, a client sends a first request message to a registry, the registry sends a communication address and a supported communication protocol of a first service end to the client according to the first request message, then the client screens out the first communication protocol supported by both the client and the first service end according to a preset selection policy, and then the client calls the first service according to the first communication protocol and the communication address of the first service end. In the process, the client can adaptively select a proper communication protocol to communicate with the first service end according to the selection strategy, and the selection scheme of the communication protocol is optimized.

In yet another alternative, the processing unit is further configured to update the selection policy, where different selection policies specify different filtering rules. Thus, when that type of protocol is required, a corresponding selection policy may be selected first, and then the required communication protocol may be selected by the selection policy.

In yet another optional scheme, the communication unit is further configured to receive change information of the first service end sent by the registry after the processing unit invokes the first service according to the first communication protocol and the communication address of the first service end, where the change information includes the communication address and/or the supported communication protocol. In this way, even if the information relating to the first service is changed, the client can still smoothly call the first service.

In a sixth aspect, an embodiment of the present application provides a client, where the client includes:

A communication unit, configured to send a first request message to a registry, where the registry stores a communication address and a supported communication protocol of a service end where each of a plurality of services is located; the first request message is used for requesting a communication address of a first service end where a first service in the plurality of services is located, and the first request message carries a communication protocol supported by the client;

The communication unit is further configured to receive a first communication protocol and a communication address of the first service end, where the first communication protocol is a communication protocol supported by both the client and the first service end;

and the processing unit is used for calling the first service according to the first communication protocol and the communication address of the first service end.

it can be seen that, a client sends a first request message to a registry, the registry determines, according to the first request message and information that each server is registered in the registry, a first communication protocol supported by both the client and the first server, and then sends the first communication protocol and a communication address of the first server to the client, and then the client invokes the first service according to the first communication protocol and the communication address of the first server. In the process, the registry can adaptively select a proper communication protocol according to the selection strategy for the client to communicate with the first server, so that the selection scheme of the communication protocol is optimized.

in a seventh aspect, an embodiment of the present application provides a registry, including:

The communication unit is used for receiving a first request message sent by a client, and the registration center stores the communication address and the supported communication protocol of a service end where each service in a plurality of services is located; the first request message is used for requesting a communication address of a first service end where a first service in the plurality of services is located and a communication protocol supported by the first service end;

The communication unit is further configured to send a communication address and a supported communication protocol of the first server to the client; the communication protocol supported by the first service end is used for determining a first communication protocol, and the first communication protocol is supported by both the client and the first service end; the first communication protocol and the communication address of the first service end are used for the client to call the first service from the first service end.

In yet another optional scheme, before the communication unit receives the first request message sent by the client: the communication unit is further configured to receive a communication address of the first service end and a supported communication protocol sent by the first service end; and the processing unit is used for storing the communication address of the first service end and the supported communication protocol. It can be understood that the first service registers the related information of the first service to the registry, so that the registry can provide the information of the first service to other services, so that the other services can smoothly call the first service.

in yet another optional scheme, after the communication unit sends the communication address of the first server and the supported communication protocol to the client, the communication unit is further configured to: receiving change information of the first service end, which is sent by the first service end, wherein the change information comprises a communication address and/or a supported communication protocol; and sending the change information of the first service terminal to the client terminal. In this way, even if the information relating to the first service is changed, the client can still smoothly call the first service.

in an eighth aspect, an embodiment of the present application provides a registry, including:

The communication unit is used for receiving a first request message sent by a client, and the registration center stores the communication address and the supported communication protocol of a service end where each service in a plurality of services is located; the first request message is used for requesting a communication address of a first service end where a first service in the plurality of services is located, and the first request message carries a communication protocol supported by the client;

the processing unit is used for determining a communication protocol supported by a communication address of the first service end, and selecting a first communication protocol supported by both the first service end and the client from the communication protocol supported by the first service end and the communication protocol supported by the client according to a preset selection strategy;

The communication unit is further configured to send the first communication protocol and the communication address of the first service end to the client, where the first communication protocol and the communication address of the first service end are used for the client to invoke the first service from the first service end.

In yet another alternative, the processing unit is further configured to update the selection policy, where different selection policies specify different filtering rules. That is, the selection policy is centrally maintained by the registry, so that when the criteria of the selection policy need to be transformed, it can be implemented by modifying the selection policy directly at the registry, and then whichever service requests the supported communication protocol of the first service can obtain the communication protocol satisfying the latest criteria from the registry. Namely, the selection strategy is centrally maintained in the registry, so that the maintenance cost is greatly reduced.

in yet another optional scheme, before the communication unit receives the first request message sent by the client: the communication unit is further configured to receive a communication address of the first service end and a supported communication protocol sent by the first service end; the processing unit is further configured to store the communication address of the first service end and the supported communication protocol. It can be understood that the first service registers the related information of the first service to the registry, so that the registry can provide the information of the first service to other services, so that the other services can smoothly call the first service.

in a ninth aspect, an embodiment of the present application provides a server, where the server is configured to execute the client described in the fifth aspect, or any possible implementation manner of the sixth aspect.

In a tenth aspect, an embodiment of the present application provides a server, where the server is configured to execute the registry described in the seventh aspect, or any possible implementation manner of the seventh aspect, or the eighth aspect, or any possible implementation manner of the eighth aspect.

by implementing the embodiment of the application, the client sends a first request message to the registry, the registry sends the communication address of the first server and the supported communication protocol to the client according to the first request message, then the client screens out the first communication protocol supported by both the client and the first server according to a preset selection strategy, and then the client calls the first service according to the first communication protocol and the communication address of the first server. In the process, the client can adaptively select a proper communication protocol to communicate with the first service end according to the selection strategy, and the selection scheme of the communication protocol is optimized.

Drawings

the drawings used in the embodiments of the present application are described below.

FIG. 1 is a diagram of a RPC scene in the prior art;

FIG. 2 is a schematic diagram of a distributed software architecture of an RPC provided in an embodiment of the present application;

FIG. 3 is a flowchart illustrating a remote procedure call protocol adaptation method according to an embodiment of the present disclosure;

Fig. 4 is a scene schematic diagram of micro services in a cloud native scene provided by an embodiment of the present application;

FIG. 5 is a schematic diagram illustrating a scenario of a communication protocol supported between services according to an embodiment of the present application;

FIG. 6 is a flowchart illustrating a remote procedure call protocol adaptation method according to an embodiment of the present application;

Fig. 7 is a schematic structural diagram of a client according to an embodiment of the present application;

Fig. 8 is a schematic structural diagram of a client according to an embodiment of the present application;

fig. 9 is a schematic structural diagram of a server provided in an embodiment of the present application;

Fig. 10 is a schematic structural diagram of a registry according to an embodiment of the present application;

Fig. 11 is a schematic structural diagram of a registry according to an embodiment of the present application;

Fig. 12 is a schematic structural diagram of a server according to an embodiment of the present application.

Detailed Description

the embodiments of the present application will be described below with reference to the drawings.

Referring to fig. 2, fig. 2 is a schematic diagram of a distributed software architecture of a PRC provided in an embodiment of the present application, where the software architecture includes a service administration framework 201 and a plurality of application ends, only 3 application ends are taken as an example in fig. 2 for illustration, and the 3 application ends are sequentially denoted as an application end 202, an application end 203, and an application end 204. The service administration framework 201 includes a registration center for receiving and maintaining registration information registered by each application, for example, the registration information may include information such as IP, port, supported communication protocol, name and/or identification of available service of the application. The registry is also used for sending information such as IP, port and supported communication protocol of the application end where the corresponding service is located to the application end with demand. Optionally, the registry may include a protocol adaptation module, configured to determine a communication protocol for two application terminals that need to communicate.

In addition, each application may include a service 2001, a programming framework 2002, and a distributed communication layer 2003, and after one application obtains the registration information of another application, the programming framework 2002 in the one application may control the service 2001 in the one application to call the service 2001 in the another application. The calling process is supported by the distributed communication layer 2003 in the one application and the distributed communication layer 2003 in the other application as communication. In fig. 2, the distributed communication layers of the respective application terminals are connected to each other, and are connected to the registry. Each programming framework 2002 may include a serialization/deserialization module and a protocol adaptation module (optional), and the communication protocol used in communicating between the one application and the other application may be determined by the protocol adaptation module in the one application or in the registry.

The above distributed software framework may be deployed on one server or one distributed server cluster. In addition, in the above distributed software framework, an application end calling a service may be referred to as a client, an application end providing a service may be referred to as a server, and an application end may serve as a client of one service or a server of another service. For example, the application 202 may provide service 1, the application 203 may provide service 2, and the application 204 may provide service 3, if the application 202 can invoke service 2 from the application 203, and the application 203 can invoke service 3 from the application 204, then the application 203 is a server for service 2, and the application 203 is a client for service 3.

Referring to fig. 3, fig. 3 is a remote procedure call protocol adaptation method provided by an embodiment of the present application, which may be implemented based on the distributed software architecture shown in fig. 2, and includes, but is not limited to, the following steps:

Step S300: each server registers information of the service provided by itself with the registry.

Specifically, assuming that each server includes a server a, the server a is taken as an example to be described below, and the server a registers information such as a name and/or an identifier of a service that the server a can provide, an IP, a port, and a supported communication protocol of the server a in the registration center. After the services that can be provided by each service are registered in the registration center, the registration center knows which services can be provided by each service, and the communication addresses and the supportable communication protocols of each client, that is, the registration center stores the communication addresses and the supportable communication protocols of the service where each service in the plurality of services is located. In the embodiment of the application, two different service terminals may provide the same service; additionally, a server may support one or more communication protocols.

The features of the service are illustrated below in conjunction with a Cloud native (Cloud native) scenario. As shown in fig. 4, the scenario illustrates a micro service based on a Java service development and execution framework, a micro service based on a C service development and execution framework, and a micro service based on a GO service development and execution framework, which all belong to the services described above. In the embodiment of the present application, each micro service may be defined by using an Interface Description Language (IDL) as a contract, and a compiling tool is provided to generate an Interface code corresponding to C, JAVA, or GO language according to an IDL file. For example, an instance of a service defining a service name of HelloService may be as follows:

Further examples of generating corresponding Java interface code using the compilation tool may be as follows:

After the above example is executed, the hello service becomes a micro-service based on the C service development operation framework. Micro-services based on a Java service development and operation framework, micro-services based on a C service development and operation framework, micro-services based on a GO service development and operation framework and the like can be obtained based on the same principle. If all the microservices based on the C service development operation framework support a high-performance private Protocol A based on Transmission Control Protocol (TCP) Transmission Protocol serialization; supporting a high-performance private protocol B based on Netty transmission and ProtoBuf serialization among all micro-services based on a JAVA service development operation framework; supporting a TCP-based transmission private protocol C among various micro services based on a GO service development operation framework; all the services listed above support a target interworking protocol (for example, HTTP protocol) for interworking, which may be denoted as inter way, and the characteristics of the various types of services are summarized in the table, and a communication protocol scheme that can be used for communication between the various types of services is shown in fig. 5, as can be seen from fig. 5:

1. the C language based services may interwork with the C language based services using proprietary protocol a.

2. The Java language based services may interwork with the Java language based services using proprietary protocol B.

3. the services based on the GO language may interwork with the services based on the GO language using a private protocol C.

4. any two of the services based on the C language, the services based on the Java language and the services based on the GO language can be intercommunicated by using a target intercommunicating protocol.

TABLE 1

service name	Type of service	Supported interworking protocol
			Microservice 1	C language service	Private protocol A, target interworking protocol
Microservice 2	c language service	private protocol A, target interworking protocol
			Microservice 3	C language service	Private protocol A, target interworking protocol
Microservice 4	Java language service	Private protocol B, target interworking protocol
			Microservice 5	Java language service	Private protocol B, target interworking protocol
microservice 6	Java language service	Private protocol B, target interworking protocol
			Microservice 7	GO language services	Private protocol C, target interworking protocol
Microservice 8	GO language services	Private protocol C, target interworking protocol
			Microservice 9	GO language services	private protocol C, target interworking protocol

The above description has introduced the features of each service, and the following examples illustrate the registration of the service a with the registry:

{

"instanceId":"65537",

"ServiceName":"HelloService",

"endpoints":

["A://156.103.2.144:22225","InterWay://156.103.2.144:22226",],

…

}

As can be seen from the above example, the identifier of the registered service is 65537, and the name of the registered service is helloeservice. The server a can support a private protocol a, and when the private protocol a is used for communication, the communication address of the server a includes an IP address 156.103.2.144 and a port 22225; server a also supports a target interworking protocol, and when communicating using the target interworking protocol, the communication address of server a includes IP address 156.103.2.144 and port 22226.

step S301: the client sends a first request message to the registry.

specifically, the first request message is used to request a communication address of a first service end where a first service of the plurality of services is located and a communication protocol supported by the first service end. The first service is a service that the client needs to call.

step S302: the registry receives a first request message sent by a client.

In particular, the first request message may include a service name and/or Identification (ID) of the first service, such that the registry may first determine the first service based on the service name and/or identification after parsing the first request message. Then, the registry determines a service end capable of providing the first service according to the information registered in the registry, and in the embodiment of the application, the service end capable of providing the first service may be referred to as the first service end. After the first service end is determined, the communication address of the first service end, for example, information such as IP and port, and the communication protocol supported by the first service end may be further determined.

for example, if the service name carried in the first request message is hello service, then hello service is the first service, so the registry can determine, from the stored information, that the identifier of the first service requested by the first request message is "65537", and can determine that the first service end (endpoints) providing the first service is [ "a: // 156.103.2.144: 22225 "," Inter: // 156.103.2.144: 22226 "], i.e. it is determined that the first service supports the private protocol a and the target interworking protocol Inter, and when the private protocol a is adopted to communicate with the first service, the IP address of the first service is 156.103.2.144, and the port is 22225; when communicating with the first server using the target interworking protocol, the IP address of the first server is 156.103.2.144 and the port is 22226.

Step S303: and the registry sends the communication address of the first server and the supported communication protocol to the client.

step S304: and the client receives the communication address of the first server and the supported communication protocol sent by the registration center.

specifically, the client may receive the communication addresses and the supported communication protocols of one or more first servers, and when the communication addresses and the supported communication protocols of one first server are received, the client performs step S305 for the one first server; when the communication addresses and the supported communication protocols of the plurality of first servers are received, the client performs step S305 only for one of the first servers (the selection rule of the one first server is not limited here).

Step S305: and the client selects a first communication protocol supported by both the client and the first service terminal from the communication protocols supported by the client and the communication protocols supported by the first service terminal according to a preset selection strategy.

Specifically, the client knows which communication protocols are supported by the client, and also knows the communication protocol supported by the first service according to the feedback of the registration center, so that the client can firstly determine the communication protocols supported by both the client and the first service, and then screen out the first communication protocol from the determined communication protocols according to a preset selection policy. It is understood that there may be more than one communication protocol supported by both the client and the first server, and therefore the client needs to select one communication protocol for communication according to the selection policy. Wherein the selection policy specifies according to what rules the communication protocol is selected, e.g. specifies selecting a more secure communication protocol; as another example, provision is made for selecting the communication protocol with the highest transmission efficiency; and so on.

For example, if the client supports the private protocol a and the target interworking protocol, and the first server also supports the private protocol a and the target interworking protocol, the communication protocols supported by both the client and the first server include the private protocol a and the target interworking protocol, at this time, a communication protocol needs to be selected from the private protocol a and the target interworking protocol as the first communication protocol according to a selection policy, and which of the finally selected communication protocols is specifically determined by the selection policy, for example, if the communication protocol specifies that a communication protocol with a higher security level is selected, the selected communication protocol is the private protocol a; if the communication protocol specifies that a communication protocol with better compatibility (e.g., capable of supporting more types of object communication) is selected, the selected communication protocol is the target interworking protocol. In addition, after the adopted communication protocol is determined, a more detailed address may be matched according to the determined communication protocol, for example, if the communication protocol a is adopted, the communication address that may be matched to the first service end includes: IP address 156.103.2.144 and port 22225. If the target interworking protocol is adopted, the communication address which can be matched to the first service end comprises: IP address 156.103.2.144 and port 22226.

Optionally, the client may update the selection policy as needed, and different selection policies specify different filtering rules. It will be appreciated that the actual choice of operation may vary over time, for example, sometimes requiring a more secure communication protocol, sometimes requiring a more transport efficient communication protocol, and sometimes requiring a more interoperable communication protocol. The developer can ensure that the communication protocol meeting the corresponding characteristics is screened out by changing the selection strategy.

step S306: the client calls the first service according to the first communication protocol and the communication address of the first service end.

Specifically, the client may establish a communication connection with the first service end according to the communication address of the first service end, and the client invokes the first service from the first service end after the communication connection is established. Optionally, when the client establishes communication with the first service end based on the first communication protocol, the client sends a hello request message to the first service end, and accordingly, the first service end sends the hello reply message to the client after receiving the hello request message, thereby implementing the call of the client to the first service end. The HelloRequest message is briefly introduced as follows: if the first service is hello service, the client executes the following program codes in advance:

In the above code, the first line (line1) is used to define the service to be called as hello service, the second line (line2) is used to specify a hello request message to send a request for calling hello service, the third line (line3) is used to fill the hello request message with the required relevant parameters, and the fourth line (line4) is used to send the hello request message by using sayHello method.

For example, when the first communication protocol is determined to be the private protocol a and the communication address of the first service end is "156.103.2.144: 22225 ", the client attempts to communicate with the communication address" 156.103.2.144: 22225' establishes socket connection, serializes msg _ hello message in HelloRequest message according to proprietary protocol A format, and sends message. Accordingly, the first server listens for the address "156.103.2.144: 22225 ' obtains the message sent by the client, judges to use the communication protocol ' A ' according to the address, deserializes the message according to the communication protocol ' A ', and calls the first service.

In this embodiment, when information of the first server is changed (for example, a type or a version of a supported communication protocol, a communication address, and the like are changed), the first server sends the change information to the registry. The client can subscribe the change information of the first service end to the registration center, and correspondingly, the registration center sends the change information to the client after determining that the related information of the first service is changed, so that the client can timely acquire the latest information of the first service, and the client can call the first service. The related information of the first service includes the type or version of the communication protocol supported by the first service end where the first service is located, the communication address, and the like.

in the method described in fig. 3, a client sends a first request message to a registry, the registry sends a communication address and a supported communication protocol of a first server to the client according to the first request message, then the client screens out the first communication protocol supported by both the client and the first server according to a preset selection policy, and then the client invokes the first service according to the first communication protocol and the communication address of the first server. In the process, the client can adaptively select a proper communication protocol to communicate with the first service end according to the selection strategy, and the selection scheme of the communication protocol is optimized.

Referring to fig. 6, fig. 6 is a remote procedure call protocol adaptation method provided by an embodiment of the present application, which may be implemented based on the distributed software architecture shown in fig. 2, and includes, but is not limited to, the following steps:

Step S600: each server registers information of the service provided by itself with the registry.

Specifically, step S600 may refer to step S300, which is not described herein.

Step S601: the client sends a first request message to the registry.

Specifically, step S601 may refer to step S301, which is not described herein again.

step S602: the registry receives a first request message sent by a client.

Specifically, in step S602, refer to step S302, and in addition, the first request message also carries information of a communication protocol supported by the client, for example, the form of http:// xxx? protocol ═ a, inter way ", and it can be known that the client supports the private protocol a and the target interworking protocol inter way according to the carried information.

Step S603: and the registry determines the communication protocol supported by the communication address of the first service end, and selects the first communication protocol supported by both the first service end and the client from the communication protocol supported by the first service end and the communication protocol supported by the client according to a preset selection strategy.

Specifically, the registry can determine the communication protocols supported by the client and the communication protocols supported by the first server according to the information registered by each server in the registry and the information carried in the first request message, so that the registry can first determine the communication protocols supported by both the client and the first server, and then screen out the first communication protocol from the determined communication protocols according to a preset selection policy. It is understood that there may be more than one communication protocol supported by both the client and the first server, and thus the registry needs to select one communication protocol for communication according to the selection policy. Wherein the selection policy specifies according to what rules the communication protocol is selected, e.g. specifies selecting a more secure communication protocol; as another example, provision is made for selecting the communication protocol with the highest transmission efficiency; and so on.

for example, if the client supports the private protocol a and the target interworking protocol, and the first server also supports the private protocol a and the target interworking protocol, the communication protocols supported by both the client and the first server include the private protocol a and the target interworking protocol, at this time, a communication protocol needs to be selected from the private protocol a and the target interworking protocol as the first communication protocol according to a selection policy, and which of the finally selected communication protocols is specifically determined by the selection policy, for example, if the communication protocol specifies that a communication protocol with a higher security level is selected, the selected communication protocol is the private protocol a; if the communication protocol provides for selecting a communication protocol with better compatibility (e.g., more types of object communication can be supported), the selected communication protocol is the target interworking protocol. In addition, after the adopted communication protocol is determined, a more detailed address may be matched according to the determined communication protocol, for example, if the communication protocol a is adopted, the communication address that may be matched to the first service end includes: IP address 156.103.2.144 and port 22225. If the target interworking protocol is adopted, the communication address which can be matched to the first service end comprises: IP address 156.103.2.144 and port 22226.

Optionally, the registry may update the selection policy as needed, and different selection policies specify different filtering rules. It will be appreciated that developers may have different ideas on the choice of communication protocols over time, for example, sometimes requiring a more secure communication protocol, sometimes requiring a more transport efficient communication protocol, and sometimes requiring a more interworking performance communication protocol. The developer can ensure that the communication protocol meeting the corresponding characteristics is screened out by changing the selection strategy. In addition, because the selection strategy is deployed on the registration center, when a developer wants to change the selection strategy, the developer can directly change the selection strategy on the registration center to ensure that all the subsequent service calling processes use the new selection strategy, and the maintenance cost is low.

Step S604: and the registry sends the first communication protocol and the communication address of the first service end to the client.

Step S605: and the client receives a first communication protocol and a communication address of the first service end, which are sent by the registry.

Step S606: and the client calls the first service according to the first communication protocol and the communication address of the first service end.

Specifically, step S306 may be referred to in step S606, and is not described herein again.

In the method described in fig. 6, a client sends a first request message to a registry, the registry determines, according to the first request message and information that each server is registered in the registry, a first communication protocol supported by both the client and the first server, then sends the first communication protocol and a communication address of the first server to the client, and then the client invokes the first service according to the first communication protocol and the communication address of the first server. In the process, the registry can adaptively select a proper communication protocol according to the selection strategy for the client to communicate with the first server, so that the selection scheme of the communication protocol is optimized. In addition, the selection strategy is deployed on the registration center, and the maintenance cost is low.

The method of the embodiments of the present application is set forth above in detail and the apparatus of the embodiments of the present application is provided below.

Referring to fig. 7, fig. 7 is a schematic structural diagram of a client 70 according to an embodiment of the present disclosure, where the client may include a communication unit 701 and a processing unit 702. Corresponding to fig. 2, the communication unit 701 is configured to perform operations required to be performed by the distributed communication layer 2003 in fig. 2, and the processing unit 702 is configured to perform operations required to be performed by the service 2001 and the programming framework 2002 in fig. 2. The communication unit 701 and the processing unit 702 are described in detail as follows.

the communication unit 701 is configured to send a first request message to a registry, where the registry stores a communication address and a supported communication protocol of a service end where each service in the multiple services is located; the first request message is used for requesting a communication address of a first service end where a first service in the plurality of services is located and a communication protocol supported by the first service end;

The communication unit 701 is further configured to receive a communication address of the first server and a supported communication protocol sent by the registry;

the processing unit 702 is configured to select, according to a preset selection policy, a first communication protocol supported by both the client and the first server from a communication protocol supported by the client and a communication protocol supported by the first server;

The processing unit 701 is further configured to invoke the first service according to the first communication protocol and the communication address of the first service end.

In yet another alternative, the processing unit 702 is further configured to update the selection policy, where different selection policies specify different filtering rules.

In yet another optional scenario, the communication unit 701 is further configured to receive change information of the first service end sent by the registry after the processing unit 702 invokes the first service according to the first communication protocol and the communication address of the first service end, where the change information includes the communication address and/or the supported communication protocol.

it should be noted that the implementation of each unit may also correspond to the corresponding description of the method embodiment shown in fig. 3.

Referring to fig. 8, fig. 8 is a schematic structural diagram of a client 80 according to an embodiment of the present disclosure, where the client may include a communication unit 801 and a processing unit 802. Corresponding to fig. 2, the communication unit 801 is configured to perform operations required to be performed by the distributed communication layer 2003 in fig. 2, and the processing unit 802 is configured to perform operations required to be performed by the service 2001 and the programming framework 2002 in fig. 2. The communication unit 801 and the processing unit 802 are described in detail below.

The communication unit 801 is configured to send a first request message to a registry, where the registry stores a communication address and a supported communication protocol of a service end where each service in the plurality of services is located; the first request message is used for requesting a communication address of a first service end where a first service in the plurality of services is located, and the first request message carries a communication protocol supported by the client;

The communication unit 801 is further configured to receive a first communication protocol and a communication address of the first service end, where the first communication protocol is a communication protocol supported by both the client and the first service end;

The processing unit 802 is configured to invoke the first service according to the first communication protocol and the communication address of the first service end.

In yet another optional scheme, the communication unit is further configured to receive change information of the first service end sent by the registry after the processing unit invokes the first service according to the first communication protocol and the communication address of the first service end, where the change information includes the communication address and/or the supported communication protocol.

In yet another alternative, the processing unit 802 is further configured to update the selection policy, where different selection policies specify different filtering rules.

In yet another optional scenario, the communication unit 801 is further configured to receive change information of the first service end sent by the registry after the processing unit invokes the first service according to the first communication protocol and the communication address of the first service end, where the change information includes the communication address and/or the supported communication protocol.

It should be noted that the implementation of each unit may also correspond to the corresponding description of the method embodiment shown in fig. 6.

Referring to fig. 9, fig. 9 is a server 90 provided in an embodiment of the present application, where the server 90 includes a processor 901, a memory 902, and a communication interface 903, and the processor 901, the memory 902, and the communication interface 903 are connected to each other through a bus.

the memory 902 includes, but is not limited to, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), or a portable read-only memory (CD-ROM), and the memory 902 is used for related instructions and data.

the processor 901 may be one or more Central Processing Units (CPUs), and in the case that the processor 901 is one CPU, the CPU may be a single-core CPU or a multi-core CPU.

the processor 901 is configured to read instructions stored in the memory 902 to perform operations performed by the processing unit in the example shown in fig. 7 or 8, and the communication interface 903 is configured to perform operations performed by the communication unit in the embodiment shown in fig. 7 or 8. That is, the server is used for the client in fig. 7 or fig. 8.

Referring to fig. 10, fig. 10 is a schematic structural diagram of a registry 100 according to an embodiment of the present application, where the registry may include a communication unit 1001 and a processing unit 1002. The communication unit 1001 and the processing unit 1002 are described in detail as follows.

the communication unit 1001 is configured to receive a first request message sent by a client, where the registry stores a communication address and a supported communication protocol of a server where each of a plurality of services is located; the first request message is used for requesting a communication address of a first service end where a first service in the plurality of services is located and a communication protocol supported by the first service end;

the communication unit 1001 is further configured to send a communication address and a supported communication protocol of the first server to the client; the communication protocol supported by the first service end is used for determining a first communication protocol, and the first communication protocol is supported by both the client and the first service end; the first communication protocol and the communication address of the first service end are used for the client to call the first service from the first service end.

In yet another alternative, before the communication unit 1001 receives the first request message sent by the client:

The communication unit 1001 is further configured to receive a communication address of the first service end and a supported communication protocol sent by the first service end;

the processing unit 1002 is configured to store a communication address and a supported communication protocol of the first service end.

In yet another optional scheme, after the communication unit 1001 sends the communication address of the first server and the supported communication protocol to the client, the method is further configured to:

Receiving change information of the first service end, which is sent by the first service end, wherein the change information comprises a communication address and/or a supported communication protocol;

and sending the change information of the first service terminal to the client terminal.

Referring to fig. 11, fig. 11 is a schematic structural diagram of a registry 110 according to an embodiment of the present application, where the registry may include a communication unit 1101 and a processing unit 1102. The communication unit 1101 and the processing unit 1102 are described in detail below.

The communication unit 1101 is configured to receive a first request message sent by a client, where the registry stores a communication address and a supported communication protocol of a service end where each service in the multiple services is located; the first request message is used for requesting a communication address of a first service end where a first service in the plurality of services is located, and the first request message carries a communication protocol supported by the client;

The processing unit 1102 is configured to determine a communication protocol supported by a communication address of the first service end, and select, according to a preset selection policy, a first communication protocol supported by both the first service end and the client from the communication protocol supported by the first service end and the communication protocol supported by the client;

the communication unit 1101 is further configured to send the first communication protocol and the communication address of the first service end to the client, where the first communication protocol and the communication address of the first service end are used for the client to invoke the first service from the first service end.

In yet another alternative, the processing unit 1102 is further configured to update the selection policies, where different selection policies specify different filtering rules.

in yet another alternative, before the communication unit 1101 receives the first request message sent by the client:

The communication unit 1101 is further configured to receive a communication address and a supported communication protocol of the first service end sent by the first service end;

the processing unit 1102 is further configured to store a communication address and a supported communication protocol of the first service end.

In yet another optional scheme, after the communication unit 1101 sends the communication address of the first server and the supported communication protocol to the client, the communication unit is further configured to:

Referring to fig. 12, fig. 12 is a server 120 according to an embodiment of the present application, where the server 120 includes a processor 1201, a memory 1202, and a communication interface 1203, and the processor 1201, the memory 1202, and the communication interface 1203 are connected to each other through a bus.

The memory 1202 includes, but is not limited to, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), or a portable read-only memory (CD-ROM), and the memory 1202 is used for related instructions and data.

The processor 1201 may be one or more Central Processing Units (CPUs), and in the case that the processor 1201 is one CPU, the CPU may be a single-core CPU or a multi-core CPU.

The processor 1201 is configured to read instructions stored in the memory 1202 to perform operations performed by the processing unit in the example shown in fig. 10 or 11, and the communication interface 1203 is configured to perform operations performed by the communication unit in the embodiment shown in fig. 10 or 11. That is, the server is used for the registry in fig. 10 or fig. 11.

it should be noted that the server 90 may be a single server or a server cluster, and the server 120 may be a single server or a server cluster. In addition, the server 90 and the server 120 may be two different servers (or server clusters) or may be the same server (or server cluster).

in summary, the client sends the first request message to the registry, the registry determines, according to the first request message and information that each server is registered in the registry, the first communication protocol supported by both the client and the first server, and then sends the first communication protocol and the communication address of the first server to the client, and then the client invokes the first service according to the first communication protocol and the communication address of the first server. In the process, the registry can adaptively select a proper communication protocol according to the selection strategy for the client to communicate with the first server, so that the selection scheme of the communication protocol is optimized. In addition, the selection strategy is deployed on the registration center, and the maintenance cost is low.

one of ordinary skill in the art will appreciate that all or part of the processes in the methods of the above embodiments may be implemented by hardware related to instructions of a computer program, which may be stored in a computer-readable storage medium, and when executed, may include the processes of the above method embodiments. And the aforementioned storage medium includes: various media capable of storing program codes, such as ROM or RAM, magnetic or optical disks, etc.

Claims

1. A remote procedure call protocol adaptation method, comprising:

2. The method according to claim 1, characterized in that it comprises:

And the client updates the selection strategies, and different selection strategies have different specified screening rules.

3. The method according to claim 1 or 2, wherein after the client invokes the first service according to the first communication protocol and the communication address of the first service end, the method further comprises:

And the client receives change information of the first service end, which is sent by the registry, wherein the change information comprises a communication address and/or a supported communication protocol.

4. a remote procedure call protocol adaptation method, comprising:

5. The method of claim 4, wherein after the client invokes the first service according to the first communication protocol and the communication address of the first service, further comprising:

6. a remote procedure call protocol adaptation method, comprising:

7. The method of claim 6, wherein before the registry receives the first request message sent by the client, the method further comprises:

The registry receives the communication address of the first service end and the supported communication protocol sent by the first service end;

The registry stores the communication address of the first service end and the supported communication protocol.

8. the method according to claim 6 or 7, wherein after the registry sends the communication address of the first service end of the APEXMOTORSPORTS and the supported communication protocol to the client, the method further comprises:

The registry receives change information of the first service end sent by the first service end, wherein the change information comprises a communication address and/or a supported communication protocol;

And the registry sends the change information of the first service terminal to the client terminal.

9. a remote procedure call protocol adaptation method, comprising:

10. the method of claim 9, wherein the method comprises:

and the registry updates the selection strategies, and different selection strategies have different specified screening rules.

11. The method according to claim 9 or 10, wherein before the registry receives the first request message sent by the client, the method further comprises:

12. The method according to any one of claims 9-11, wherein after the registry sends the communication address of the first server and the supported communication protocols to the client, the method further comprises:

13. A client, comprising:

14. the client of claim 13, wherein:

The processing unit is further configured to update the selection policy, where different selection policies specify different filtering rules.

15. The client according to claim 13 or 14, wherein the communication unit is further configured to receive change information of the first service end sent by the registry after the processing unit invokes the first service according to the first communication protocol and the communication address of the first service end, where the change information includes a communication address and/or a supported communication protocol.

16. a client, comprising:

17. the client according to claim 16, wherein the communication unit is further configured to receive change information of the first service end sent by the registry after the processing unit invokes the first service according to the first communication protocol and the communication address of the first service end, where the change information includes the communication address and/or the supported communication protocol.

18. a registry, comprising:

19. The registry of claim 18 wherein the communication unit, prior to receiving the first request message from the client:

The communication unit is further configured to receive a communication address of the first service end and a supported communication protocol sent by the first service end;

And the processing unit is used for storing the communication address of the first service end and the supported communication protocol.

20. the registry of claim 18 or 19, wherein after the communication unit sends the communication address of the first server and the supported communication protocol to the client, the registry is further configured to:

21. a registry, comprising:

22. The registry of claim 21 wherein:

23. The registry of claim 21 or 22 wherein, before the communication unit receives the first request message sent by the client:

The processing unit is further configured to store the communication address of the first service end and the supported communication protocol.

24. The registry of any one of claims 21-23 wherein after the communication unit sends the communication address of the first server and the supported communication protocol to the client, the registry is further configured to:

25. a server, characterized in that the server is adapted to run the client of any of claims 13-17.

26. A server, characterized in that the server is adapted to run a registry according to any of claims 18-24.