1. 基本概念

PRC 远程过程调用 Remote Procedure Call，其就是一个节点请求另外一个节点提供的服务。当两个物理分离的子系统需要建立逻辑上的关联时，RPC 是牵线搭桥的常见技术手段之一。除 RPC 之外，常见的多系统数据交互方案还有分布式消息队列、HTTP 请求调用、数据库和分布式缓存等。

• 本地过程调用：
  如果要将本地的对象进行相关操作，可以定义一个方法，然后将相关对象传入，然后对其对象进行更新，然后由函数返回更新后的函数对象。

• 远程过程调用：
  在上述过程中，如果其定义的函数是在另外一个服务器端，并且执行的函数体也是在另外一台远程服务器上，那么这个过程就称之为远程过程调用。

2. 调用过程

其调用过程如下所示：

1. 首先客户端需要告诉服务器端，需要调用的函数，然后这里的函数和进程 ID 存在一个映射，客户端远程调用的时候，需要查询一下函数，找到对应的 ID，然后执行对应函数的代码。
2. 客户端需要把本地参数传递给远程函数，在本地调用的过程中，会通过把参数转换为字节码，然后再传递给服务端，最后服务端再转换为自身可以读取的格式，这是一个序列化和反序列的过程。
3. 转换完成数据以后，在进行传输的过程一般是使用 HTTP，Socket 协议进行传输。

除去 RPC 调用以外，还有 RESTful API 进行调用。RESTful API 调用其示例图如下图所示：
​

在上图中，一个服务 A 如果访问另外一个服务器下的 B，这个过程采用的就是 RESTful API 进行数据的传输。并且两个过程的数据会进行序列化和反序列化炒作。
​

两种方式进行对比而言，

• RPC 通信代价比较低，因为 RPC 是直接基于 TCP 进行调用的，并且传输的数据都是基于 TCP 进行的，所以效率更高，更优。但是由于是基于 TCP 的所以实现起来更为的复杂，更为的难以维护。
• 而 RESTful API 由于是直接基于 HTTP 的所以实现更为简单，维护更为容易。
• RPC 快，效率高，但是不够通用，就好比地方方言，HTTP通用是普通话，但是效率不够高，传输的字节内容冗余多。
• REST 相对更规范，更标准，更通用，简单易用，维护性和扩展性都比较好。
• RPC+Protobuf 采用的是 TCP 做传输协议，REST 直接使用 HTTP 做应用层协议，这种区别导致 REST 在调用性能上会比 RPC+Protobuf 低。

Go 语言中常用的 API 风格是 RPC 和 REST，常用的媒体类型是 JSON、XML 和 Protobuf。在 Go API 开发中常用的组合是 gRPC+Protobuf 和 REST+JSON。

其实业界普遍采用的做法是，内部系统之间调用用 RPC，对外用 REST，因为内部系统之间可能调用很频繁，需要 RPC 的高性能支撑。对外用 REST 更易理解，更通用些。当然以现有的服务器性能，如果两个系统间调用不是特别频繁，对性能要求不是非常高，REST 的性能完全可以满足。

HTTP 调用其实也是一种特殊的 RPC。

HTTP1.0 协议时，HTTP 调用还只能是短链接调用，一个请求来回之后连接就会关闭。HTTP1.1 在 HTTP1.0 协议的基础上进行了改进，引入了 KeepAlive 特性可以保持 HTTP 连接长时间不断开，以便在同一个连接之上进行多次连续的请求，进一步拉近了 HTTP 和 RPC 之间的距离。

当 HTTP 协议进化到 2.0 之后，Google 开源了一个建立在 HTTP2.0 协议之上的通信框架直接取名为 gRPC，也就是 Google RPC。

3. 解决问题

总之，RPC 解决掉了在分布式系统之中，服务之间调用的问题。让服务在远程调用的时候，能够像本地调用一样非常方便，并且让调用者感知不到远程调用的具体逻辑。
​
RPC 只是对底层通信和交互协议的一个封装，便于上层使用。

4. 调用流程

一般来说调用过程如下所示：

1. 调用者，以本地调用方式发起调用。
2. Client stub 客户端收到调用以后，将会把被调用的方法名，参数进行打包编码成为特定的格式，包装成为能够被网络传输的消息体。
3. Client stub 将消息体通过网络发送给服务端。
4. Server stub 将会收到通过网络接收到的消息后按照相应的格式进行拆分，获取方法名称和及其调用传入的参数。
5. 被调用者 Server 本地调用执行后将会把结果返回给 Server stub。
6. Server stub 将会将返回值打包编码成为消息，然后通过网络发送给客户端。
7. Client stub 收到消息以后，将会进行拆分，然后返回给 CLient。
8. Client 最终获得本地 RPC 调用结果。

RPC 传输控制

对于消息数据的传输，主要有 HTTP 传输和 TCP 传输，一般来说 RPC 使用 TCP 进行传输，因为 TCP其要优于 HTTP 传输。
​
传输过程如下图所示：
​
传输的时候一般通过 Socket 接口进行传输，也有使用 HTTP 作为底层的传输的结果，但是使用 HTTP 传输的比较少。
​

其过程如下：

1. Server 发起创建套接字请求。
2. 创建套接字后绑定相关端口
3. 监听链接
4. 进入接收连接状态中。
5. Client 端创建套接字
6. Client 端和 Server 端刚刚建立完成的 Socket 进行连接的建立。
7. Server 端进行读取，Client 进行数据写。
8. Client 端进行数据读取，
9. 双方交换完数据以后，关闭连接。

​
Server 端代码示例：

import socket

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.bind(("localhost", 8080))
sock.listen(1)  # 监听客户端连接
while True:
    conn, addr = sock.accept()  # 接收一个客户端连接
    print(conn.recv(1024))
    conn.sendall(b"world")  # 将响应发送到发送缓冲 send buffer
    conn.close()

输出结果

b'hello'

Client 端代码示例：

import socket

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect(("localhost", 8080))
sock.sendall(b"hello")  # 将消息输出到发送缓冲 send buffer
print(sock.recv(1024))
sock.close()

输出结果

b'world'

问题：客户端疯狂发送请求，但是服务器不读不处理，会发生什么？

• 如果接收和发送队列没有设置大小，服务器处理能力弱，tcp 会动态调整直至耗尽整个内存；
• 设置了大小，socket 缓冲区满，那么 socket 会出现阻塞，不接受发送端的消息；
• 如果发送的请求 size 大于发送和接收队列之和，那么会一直阻塞下去；

5. 远程调用时序图

1. 本地 RPCTest 类，将会调用 ServiceProducer 在服务端注册并启动 Server。
2. Server 将会调用 register 和 start 进行初始化应用。
3. RPCTest 将会通过 Client 调用本地方法。
4. Client 将会调用远程服务器方法 ServiceProducer 并传入本地阐述，将消息发送给 Server端。
5. Server 端放过反射，压入 ServerTask。
6. ServerTask 将会远程执行方法。
7. 最后调用栈，调用完成以后，将结果返回给 Server。
8. Server 通过网络传输信息到 Client。
9. Client 把结果最终返回给 RPCTest。