Blog.csdn.net/top_code/ar…

Remote Procedure Call (RPC) allows one computer to Call a program on another computer to get results without additional programming in the code, just like local calls.

Nowadays, with the increasing magnitude of Internet applications, the capacity of a single computer is limited, so it needs to use scalable computer clusters to complete the application. Distributed applications can use RPC to complete the call between machines.

There are three main roles in the RPC framework: Provider, Consumer, and Registry. As shown below:



Node roles:

* Server: The service provider that exposes the service.

* Client: service consumer that invokes the remote service.

* Registry: A Registry for service registration and discovery.

RPC Call flow Basic RPC flow chart:



A complete RPC call flow (synchronous call, asynchronous call separately) is as follows:

1) Service consumer (Client) invocation invokes the service in a local invocation mode;

2) After receiving the call, the Client stub is responsible for assembling methods and parameters into a message body capable of network transmission;

3) The client stub finds the service address and sends the message to the server.

4) The Server Stub decodes the message after receiving it.

5) The Server Stub invokes the local service according to the decoding result;

6) The local service executes and returns the result to the server stub;

7) The Server Stub packages the returned result into a message and sends it to the consumer;

8) The Client stub receives the message and decodes it.

9) The service consumer gets the final result.

The goal of the RPC framework is to encapsulate steps 2 through 8 and make these details transparent to the user.

Service registration & discovery



After startup, the service provider will register the machine IP, port and the service list to the registry.

Service consumers obtain the address list of service providers from the registry when they start up, which can realize soft load balancing and Failover.

1. Dynamic proxy Generation of client stub and server stub requires Java dynamic proxy technology. We can use the native dynamic proxy mechanism of JDK and some open source bytecode tool frameworks such as CgLib and Javassist.

To be able to transfer and receive Java objects over the network, we need to serialize and deserialize them. * Serialization: The process of converting Java objects into byte[], which is the process of coding; * Deserialization: The process of converting byte[] into a Java object;

Java’s native serialization mechanism can be used, but it is very inefficient. Some open source, mature serialization techniques such as Protobuf, Thrift, Hessian, Kryo, Msgpack are recommended

See jVM-Serializers for performance comparisons

3. NIO currently many RPC frameworks are directly based on The IO communication framework of NetTY, such as Alibaba HSF, Dubbo and Hadoop Avro. It is recommended to use NetTY as the underlying communication framework.

4. Service registry Available technologies: * Redis * Zookeeper * Consul * Etcd

Programming practice BASED on Netty4 + Zookeeper + Protostuff + Spring to achieve a simple, efficient RPC framework Mango: github.com/TiFG/mango…

Open source excellent RPC framework Alibaba Dubbo: github.com/alibaba/dub… Sina weibo Motan:https://github.com/weibocom/motan gRPC:github.com/grpc/grpc RPCX: https://github.com/smallnest/rpcx Apache Thrift: thrift.apache.org/ — — — — — — — — — — — — — — — — — — — — – the author: Ricky_Fung sources: the original CSDN: Blog.csdn.net/top_code/ar… Copyright notice: This article is the blogger’s original article, reprint please attach the blog link!