1. 什么是RPC框架

RPC(Remote Procedure Call，远程过程调用)是一种计算机通信协议，允许调用不同进程空间的程序。RPC 的客户端和服务器可以在一台机器上，也可以在不同的机器上。程序员使用时，就像调用本地程序一样，无需关注内部的实现细节。

不同的应用程序之间的通信方式有很多，比如浏览器和服务器之间广泛使用的基于 HTTP 协议的 Restful API。与 RPC 相比，Restful API 有相对统一的标准，因而更通用，兼容性更好，支持不同的语言。HTTP 协议是基于文本的，一般具备更好的可读性。但是缺点也很明显：

• Restful 接口需要额外的定义，无论是客户端还是服务端，都需要额外的代码来处理，而 RPC 调用则更接近于直接调用。
• 基于 HTTP 协议的 Restful 报文冗余，承载了过多的无效信息，而 RPC 通常使用自定义的协议格式，减少冗余报文。
• RPC 可以采用更高效的序列化协议，将文本转为二进制传输，获得更高的性能。
• 因为 RPC 的灵活性，所以更容易扩展和集成诸如注册中心、负载均衡等功能。

2. RPC框架要解决什么问题

我们可以想象下两台机器上，两个应用程序之间需要通信，那么首先，需要确定采用的传输协议是什么？如果这个两个应用程序位于不同的机器，那么一般会选择 TCP 协议或者 HTTP 协议；那如果两个应用程序位于相同的机器，也可以选择 Unix Socket 协议。传输协议确定之后，还需要确定报文的编码格式，比如采用最常用的 JSON 或者 XML，那如果报文比较大，还可能会选择 protobuf 等其他的编码方式，甚至编码之后，再进行压缩。接收端获取报文则需要相反的过程，先解压再解码。

解决了传输协议和报文编码的问题，接下来还需要解决一系列的可用性问题，例如，连接超时了怎么办？是否支持异步请求和并发？

如果服务端的实例很多，客户端并不关心这些实例的地址和部署位置，只关心自己能否获取到期待的结果，那就引出了注册中心(registry)和负载均衡(load balance)的问题。简单地说，即客户端和服务端互相不感知对方的存在，服务端启动时将自己注册到注册中心，客户端调用时，从注册中心获取到所有可用的实例，选择一个来调用。这样服务端和客户端只需要感知注册中心的存在就够了。注册中心通常还需要实现服务动态添加、删除，使用心跳确保服务处于可用状态等功能。

再进一步，假设服务端是不同的团队提供的，如果没有统一的 RPC 框架，各个团队的服务提供方就需要各自实现一套消息编解码、连接池、收发线程、超时处理等“业务之外”的重复技术劳动，造成整体的低效。因此，“业务之外”的这部分公共的能力，即是 RPC 框架所需要具备的能力

3. 动手实现

3.1 服务端与消息编码

客户端与服务端的通信需要协商一些内容，例如 HTTP 报文，分为 header 和 body 2 部分，body 的格式和长度通过 header 中的 Content-Type 和 Content-Length 指定，服务端通过解析 header 就能够知道如何从 body 中读取需要的信息。对于 RPC 协议来说，这部分协商是需要自主设计的。为了提升性能，一般在报文的最开始会规划固定的字节，来协商相关的信息。比如第1个字节用来表示序列化方式，第2个字节表示压缩方式，第3-6字节表示 header 的长度，7-10 字节表示 body 的长度。

3.2 高性能客户端

对 net/rpc 而言，一个函数需要能够被远程调用，需要满足如下五个条件：

• the method’s type is exported.
• the method is exported.
• the method has two arguments, both exported (or builtin) types.
• the method’s second argument is a pointer.
• the method has return type error.
  简单来说T,T1,T2，MethodName都是公开的，且方法的第二个参数是指针，返回值有error

func (t *T) MethodName(argType T1, replyType *T2) error

3.3 服务注册

服务注册往往需要通过反射机制来实现
部分代码如下：

3.3.1 定义结构体methodType

func (t *T) MethodName(argType T1, replyType *T2) error

对应于可以被远程调用的方法

type methodType struct {// 反射的方法本身method    reflect.Method// 参数类型 T1ArgType   reflect.Type// 返回值类型 T2ReplyType reflect.Type// 服务调用的次数numCalls  uint64
}

3.3.2 定义结构体service

type service struct {// name 即映射的结构体的名称name   string// typ 是结构体的类型typ    reflect.Type// rcvr 即结构体的实例本身，保留 rcvr 是因为在调用时需要 rcvr 作为第 0 个参数rcvr   reflect.Value// 存储映射的结构体的所有符合条件的方法method map[string]*methodType
}

3.3.3 完成构造函数 newService

入参是任意需要映射为服务的结构体实例

// rcvr 是任意的实例
func newService(rcvr interface{}) *service {s := new(service)s.rcvr = reflect.ValueOf(rcvr)s.name = reflect.Indirect(s.rcvr).Type().Name()s.typ = reflect.TypeOf(rcvr)if !ast.IsExported(s.name) {log.Fatalf("rpc server: %s is not a valid service name", s.name)}s.registerMethods()return s
}func (s *service) registerMethods() {s.method = make(map[string]*methodType)// 遍历类中的每个方法，筛选出符合条件的方法for i := 0; i < s.typ.NumMethod(); i++ {method := s.typ.Method(i)mType := method.Typeif mType.NumIn() != 3 || mType.NumOut() != 1 {continue}if mType.Out(0) != reflect.TypeOf((*error)(nil)).Elem() {continue}argType, replyType := mType.In(1), mType.In(2)if !isExportedOrBuiltinType(argType) || !isExportedOrBuiltinType(replyType) {continue}s.method[method.Name] = &methodType{method:    method,ArgType:   argType,ReplyType: replyType,}log.Printf("rpc server: register %s.%s\n", s.name, method.Name)}
}
// 判断是否是暴露的类型
func isExportedOrBuiltinType(t reflect.Type) bool {return ast.IsExported(t.Name()) || t.PkgPath() == ""
}

3.4 超时处理

超时处理是 RPC 框架一个比较基本的能力，如果缺少超时处理机制，无论是服务端还是客户端都容易因为网络或其他错误导致挂死，资源耗尽，这些问题的出现大大地降低了服务的可用性。因此，我们需要在 RPC 框架中加入超时处理的能力。

3.4.1 客户端处理超时的地方

• 与服务端建立连接，导致的超时
• 发送请求到服务端，写报文导致的超时
• 等待服务端处理时，等待处理导致的超时（比如服务端已挂死，迟迟不响应）
• 从服务端接收响应时，读报文导致的超时

3.4.2 服务端处理超时的地方

• 读取客户端请求报文时，读报文导致的超时
• 发送响应报文时，写报文导致的超时
• 调用映射服务的方法时，处理报文导致的超时

3.5 负载均衡

假设有多个服务实例，每个实例提供相同的功能，为了提高整个系统的吞吐量，每个实例部署在不同的机器上。客户端可以选择任意一个实例进行调用，获取想要的结果。那如何选择呢？取决了负载均衡的策略。对于 RPC 框架来说，我们可以很容易地想到这么几种策略：

• 随机选择策略 - 从服务列表中随机选择一个。
• 轮询算法(Round Robin) - 依次调度不同的服务器，每次调度执行 i = (i + 1) mode n。
• 加权轮询(Weight Round Robin) - 在轮询算法的基础上，为每个服务实例设置一个权重，高性能的机器赋予更高的权重，
• 也可以根据服务实例的当前的负载情况做动态的调整，例如考虑最近5分钟部署服务器的 CPU、内存消耗情况。
• 哈希/一致性哈希策略 - 依据请求的某些特征，计算一个 hash 值，根据 hash 值将请求发送到对应的机器。一致性 hash 还可以解决服务实例动态添加情况下，调度抖动的问题。一致性哈希的一个典型应用场景是分布式缓存服务。

3.6 服务发现与注册中心

注册中心的位置如上图所示。注册中心的好处在于，客户端和服务端都只需要感知注册中心的存在，而无需感知对方的存在。更具体一些：

服务端启动后，向注册中心发送注册消息，注册中心得知该服务已经启动，处于可用状态。一般来说，服务端还需要定期向注册中心发送心跳，证明自己还活着。
客户端向注册中心询问，当前哪天服务是可用的，注册中心将可用的服务列表返回客户端。
客户端根据注册中心得到的服务列表，选择其中一个发起调用。