What is RPC framework?

To answer the first question: What is an RPC framework? RPC can be summed up in one sentence: Remote Procedure Call framework



So what is a remote call?

Usually we call a PHP method, such as a function called localAdd(10, 20). The implementation of localAdd is either user-defined or native to the PHP library.

Remote invocation means that the implementation of the called method is not locally executed, but somewhere remote.

 

Nelson first pointed out in his paper that the program to realize RPC included five theoretical model parts:

User 

User-stub 

RPCRuntime 

Server-stub 

Server

The relationship between these five parts is shown in the figure below:

Here the User is the Client. When User wants to make a remote call, it actually calls user-stub locally. User-stub is responsible for encoding the invoked interfaces, methods, and parameters using the agreed protocol specification and transmitting them to the remote instance through the local RPCRuntime instance. After receiving the request, the remote RPCRuntime instance sends it to the Server-Stub for decoding and invokes the request to the local Server. The call result is returned to the User. For example, A (client) calls the remoteAdd method provided by B (Server) : First, A TCP connection is established between A and B; A then serializes the method name to be called (remoteAdd in this case) and the method parameters (10, 20) into A byte stream and sends it; B takes the byte stream sent by A, deserializes the target method name, method parameters, and then executes the corresponding method call (possibly localAdd) and returns the result 30; A receives the result of the remote call and prints 30. The RPC framework encapsulates these details and exposes the user to a simple and user-friendly API. The benefits of remote calls are decoupled: When the server needs to change the implementation within the method, the client is completely unaware of it and does not need to make any changes. This approach is often used when working across departments and companies, and the provider of this approach is often referred to as service exposure. What is the difference between RPC and Socket? From the above brief explanation, it seems that RPC and Socket are similar. Both call remote methods, both are client/server mode, I also wrote a previous article: the details of socket so that they are different? RPC (remote procedure call) uses client/server mode to enable two processes to communicate with each other. Socket is one of the communication means often adopted by RPC. RPC is implemented on the basis of socket, which requires more network and system resources than socket. In addition to Socket, RPC also has other communication methods, such as HTTP, operating system pipeline technology to achieve the call to remote programs. In Microsoft Windows, RPC uses named pipes to communicate. What is the difference between RPC and REST? RPC is based on client/server mode and calls remote methods. REST is based on CLIENT /server mode and calls remote methods. What is the difference between RPC and REST? Both REST APIS and RPC encapsulate functions as interfaces on the Server and expose them to the Client. However, REST APIS are based on THE HTTP protocol. REST aims to provide an HTTP request with methods such as POST/GET/PUT/DELETE in the HTTP protocol and a readable URL. RPC, on the other hand, can be non-HTTP, so if you have two back-end languages calling each other, you get better performance with RPC (without HTTP headers and all that stuff) and should be easier to configure. If the front end is calling the back end via AJAX, then REST APIS are better (because HTTP is unavoidable anyway).

 

Local procedure call

RPC calls remote functions as if they were local. Before looking at RPC, let’s look at how local calls are called. Suppose we want to call Multiply to compute the result of lvalue * rvalue:

int Multiply(int l, int r) {
    int y = l * r;
    return y;
}
 
int lvalue = 10;
int rvalue = 20;
int l_times_r = Multiply(lvalue, rvalue);
Copy the code

So in line 8, we actually do the following:

Push the values of lvalue and rvalue into the Multiply function, take the values 10 and 20 from the stack, assign them to L and R, execute line 2, calculate L * r, and store the result in Y, push the value of y, and then return line 8 from Multiply, Fetching the return value 200 from the stack and assigning it to l_times_r are the five steps to perform the local call.

New problems with remote procedure calls

When called remotely, the body of the function we need to execute is on a remote machine, that is, Multiply is executed in another process. This raises several new questions:

Call ID mapping. How do we tell the remote machine that we want to call Multiply instead of Add or FooBar? In local calls, the body of a function is specified directly by a function pointer. When we call Multiply, the compiler automatically calls its corresponding function pointer for us. However, in remote calls, function Pointers are not available because the address Spaces of the two processes are completely different. Therefore, in RPC, all functions must have an ID of their own. This ID is uniquely determined in all processes. The client must attach this ID when making a remote procedure call. Then we need to maintain a table of {function <–> Call ID} on the client side and on the server side. The tables do not have to be identical, but the same function must have the same Call ID. When the client needs to make a remote Call, it looks up the table, finds the corresponding Call ID, and passes it to the server. The server also looks up the table, determines the function that the client needs to Call, and then executes the code for that function. Serialization and deserialization. How do clients pass parameter values to remote functions? In local calls, we simply push the arguments onto the stack and let the function read from the stack itself. However, in remote procedure calls, the client and server are different processes and cannot pass parameters through memory. Sometimes the client and server even use different languages (such as C++ on the server and Java or Python on the client). In this case, the client needs to convert the parameter into a byte stream, pass it to the server, and then convert the byte stream into a format that it can read. This process is called serialization and deserialization. Similarly, the value returned from the server also needs to be serialized through deserialization. Network transmission. Remote calls are often used over a network, where clients and servers are connected. All data needs to travel over the network, so there needs to be a network transport layer. The network transport layer passes the Call ID and serialized parameter bytes to the server, which then passes the serialized Call result back to the client. Anything that can do both can be used as a transport layer. Therefore, the protocol it uses is actually unlimited, as long as it can complete the transfer. While most RPC frameworks use TCP, UDP works as well, and gRPC uses HTTP2. Java’s Netty also falls into this category. Therefore, to achieve an RPC framework, in fact, only need to achieve the above three points are basically completed.

Call ID mappings can use function strings directly or integer ids. A mapping table is generally just a hash table.

Serialization Deserialization can be written yourself, or it can use things like Protobuf or FlatBuffers.

Network transport libraries can write their own sockets, or use ASio, ZeroMQ, Netty and so on.

What are the popular RPC frameworks in Dachang?

1. Google GPRC

github.com/grpc/grpc

Github.com/google/prot…

doc.oschina.net/grpc

 

2. Facebook thrift

Thrift originated on Facebook, which submitted Thrift as an open source project to the Apache Foundation in 2007.

thrift.apache.org/

thrift.apache.org/lib/

thrift.apache.org/lib/cpp

Github.com/apache/thri…

 

3. Tencent Tars

Tencent micro service framework Tars introduction

Github.com/TarsCloud/T…

Github.com/TarsCloud/T…

Github.com/TarsCloud/T…

Github.com/Tencent/phx… , formerly Svrkit

Github.com/loveyacper/… Enthusiastic former Tencent tycoon DIY, C++ implementation

 

4. Baidu BRPC

BRPC, also known as Bidu-RPC, is a “remote procedure call” network framework developed by Baidu. C + + implementation.

github.com/brpc/brpc

 

Golang’s RPCX

RPCX is a distributed RPC service framework similar to Alibaba Dubbo and Weibo Motan, based on Golang NET/RPC implementation. Claimed to be the best Go language RPC service governance framework, fast, easy to use but powerful, performance is much higher than Dubbo, Motan, Thrift and other frameworks, is twice the performance of gRPC.

rpcx.io/

Github.com/smallnest/r…

 

6, Sogou SRPC

Sogou is based on Workflow’s proprietary RPC framework, implemented in C++

github.com/sogou/srpc — RPC based on Sogou C++ Workflow

Github.com/sogou/workf… — Sogou’s C++ Asynchronous Programming Engine

www.zhihu.com/people/liyi…

 

Other niche open source C++ RPC

2. Casocklib: Protobuf + ASio more perfect implementation 3. Eventrpc: Protobuf + libevent more perfect implementation

www.exit1.org/Event-RPC/ 4. Evproto: simple implementation of protobuf + libevent

Github.com/chenshuo/ev…

Github.com/chenshuo/ev… Febird: the same idl-free c++ RPC implements its own serialization and network IO. 6. LibHttp, XMLRPC are xml-wrapped RPC

7.rest_rpc

Github.com/topcpporg/r…

8.muduo_rpc

Github.com/chenshuo/mu…

Github.com/chenshuo/mu…

9.other

Github.com/IronsDu/gay…

Github.com/guangqianpe…

Github.com/hjk41/tinyr…

Github.com/button-chen…

Github.com/persistents… A Protocol buffer-based RPC implementation

www.cnblogs.com/persistents… A Protocol buffer-based RPC implementation

 

java rpc

Java, write RPC framework together

Blog.csdn.net/linuu/artic…