Let's use dubbo to understand the nature of rpc calls.
The rpc module of dubbo is centered on Invocation and Result, and the extension interfaces are Protocol, Invoker and Exporter. Protocol is the service domain, it is the main function entry exposed and referenced by Invoker, and it is responsible for the life cycle management of Invoker. Invoker is the entity domain, it is the core model of Dubbo, other models rely on it, or convert to it, it represents an executable body, and can initiate invoke calls to it, it may be a local implementation, or it may be Is a remote implementation, and possibly a cluster implementation.
The invoker interface provides two methods.
Class<T> getInterface(); Get the invoked interface
Result invoke(Invocation invocation) throws RpcException; Executing the invocation
description rpc has two things. First, locate which interface to call, and second, initiate the call and return the result.
It is worth noting that the invoker needs the information provided by the Invocation, and the Invocation supports a local invoker. The invoker does not participate in the serialization of the Invocation. Invocation is converted into a request object and passed through the network and serialized and deserialized.
rpccontext is a static utility class that saves the context of a single call through threadlocal.
The exposure and reference of the Protocol payload invoker.
A refer invoker will have an export invoker. If the referenced service does not exist, you need to set <dubbo:consumer check="false" />
to expose the service
sequence
. The rpc module of dubbo that refers to the service sequence also abides by the overall design principles of dubbo Using Microkernel + Plugin mode, Microkernel is only responsible for assembling Plugin.
The invoker is the core model. The server exposes the invoker object as an Exporter object, and writes the url description into the registry, and the registry pushes it to the consumer. The consumer is converted into an invoker object through the url.