从零开始实现一个RPC框架（一）

前言
在上一篇文章中我们先列举了大致的需求，定义了消息协议。这次我们着手搭建基本的RPC框架，首先实现基础的方法调用功能。

功能设计

RPC调用的第一步，就是在服务端定义要对外暴露的方法，在grpc或者是thrift中，这一步我们需要编写语言无关的idl文件，然后通过idl文件生成对应语言的代码。而在我们的框架里，出于简单起见，我们不采用idl的方式，直接在代码里定义接口和方法。这里先规定对外的方法必须遵守以下几个条件：

1. 对外暴露的方法，其所属的类型和其自身必须是对外可见（Exported）的，也就是首字母必须是大写的
2. 方法的参数必须为三个，而且第一个必须是context.Context类型
3. 第三个方法参数必须是指针类型
4. 方法返回值必须是error类型
5. 客户端通过"Type.Method"的形式来引用服务方法，其中Type是方法实现类的全类名，Method就是方法名称

为什么要有这几个规定呢，具体的原因是这样的：因为java中的RPC框架场用到的动态代理在go语言中并不支持，所以我们需要显式地定义方法的统一格式，这样在RPC框架中才能统一地处理不同的方法。所以我们规定了方法的格式：

• 方法的第一个参数固定为Context，用于传递上下文信息
• 第二个参数是真正的方法参数
• 第三个参数表示方法的返回值，调用完成后它的值就会被改变为服务端执行的结
• 方法的返回值固定为error类型，表示方法调用过程中发生的错。

这里我们需要注意的是，服务提供者在对外暴露时并不需要以接口的形式暴露，只要服务提供者有符合规则的方法即可；而客户端在调用方法时指定的是服务提供者的具体类型，不能指定接口的名称，即使服务提供者实现了这个接口。
contet.Context
context是go语言提供的关于请求上下文的抽象，它携带了请求deadline、cancel信号的信息，还可以传递一些上下文信息，非常适合作为RPC请求的上下文，我们可以在context中设置超时时间，还可以将一些参数无关的元数据通过context传递到服务端。
实际上，方法的固定格式以及用Call和Go来表示同步和异步调用都是go自带的rpc里的规则，只是在参数里增加了context.Context。不得不说go自带的rpc设计确实十分优秀，值得好好学习理解。

接口定义

client和server

首先是面向使用者的RPC框架中的客户端和服务端接口：

type RPCServer interface {
        //注册服务实例，rcvr是receiver的意思，它是我们对外暴露的方法的实现者，metaData是注册服务时携带的额外的元数据，它描述了rcvr的其他信息
        Register(rcvr interface{}, metaData map[string]string) error
        //开始对外提供服务
        Serve(network string, addr string) error
}
type RPCClient interface {      
        //Go表示异步调用
        Go(ctx context.Context, serviceMethod string, arg interface{}, reply interface{}, done chan *Call) *Call
        //Call表示异步调用
        Call(ctx context.Context, serviceMethod string, arg interface{}, reply interface{}) error
        Close() error
}
type Call struct {
	ServiceMethod string      // 服务名.方法名
	Args          interface{} // 参数
	Reply         interface{} // 返回值（指针类型）
	Error         error       // 错误信息
	Done          chan *Call  // 在调用结束时激活
}

selector和registery

这次先实现RPC调用部分，这两层暂时忽略，后续再实现。

codec

接下来我们需要选择一个序列化协议，这里就选之前使用过的messagepack。之前设计的通信协议分为两个部分：head和body，这两个部分都需要进行序列化和反序列化。head部分是元数据，可以直接采用messagepack序列化，而body部分是方法的参数或者响应，其序列化由head中的SerializeType决定，这样的好处就是为了后续扩展方便，目前也使用messagepack序列化，后续也可以采用其他的方式序列化。
序列化的逻辑也定义为接口：

type Codec interface {
   Encode(value interface{}) ([]byte, error)
   Decode(data []byte, value interface{}) error
}

protocol

确定好了序列化协议之后，我们就可以定义消息协议相关的接口了。协议的设计参考上一篇文章：从零开始实现一个RPC框架（零）

接下来就是协议的接口定义：

//Messagge表示一个消息体
type Message struct {
	*Header //head部分, Header的定义参考上一篇文章
	Data []byte //body部分
}

//Protocol定义了如何构造和序列化一个完整的消息体
type Protocol interface {
	NewMessage() *Message
	DecodeMessage(r io.Reader) (*Message, error)
	EncodeMessage(message *Message) []byte
}

根据之前的设计，所以交互都通过接口进行，这样方便扩展和替换。

transport

协议的接口定义好了之后，接下来就是网络传输层的定义：

//传输层的定义，用于读取数据
type Transport interface {
	Dial(network, addr string) error
	//这里直接内嵌了ReadWriteCloser接口，包含Read、Write和Close方法
	io.ReadWriteCloser 
	RemoteAddr() net.Addr
	LocalAddr() net.Addr
}
//服务端监听器定义，用于监听端口和建立连接
type Listener interface {
	Listen(network, addr string) error
	Accept() (Transport, error)
	//这里直接内嵌了Closer接口，包含Close方法
	io.Closer
}

具体实现

各个层次的接口定义好了之后，就可以开始搭建基础的框架了，这里不附上具体的代码了，具体代码可以参考github链接
，这里大致描述一下各个部分的实现思路。

Client

代码实现

客户端的功能比较简单，就是将参数序列化之后，组装成一个完整的消息体发送出去。请求发送出去的同时，将未完成的请求都缓存起来，每收到一个响应就和未完成的请求进行匹配。

发送请求的核心在Go和send方法，Go的功能是组装参数，send方法是将参数序列化并通过传输层的接口发送出去，同时将请求缓存到pendingCalls中。而Call方法则是直接调用Go方法并阻塞等待知道返回或者超时。

接收响应的核心在input方法，input方法在client初始化完成时通过go input() 执行。input方法包含一个无限循环，在无限循环中读取传输层的数据并将其反序列化，并将反序列化得到的响应与缓存的请求进行匹配。

注：send和input方法的命名也是从go自带的rpc里学来的。

Server

代码实现

服务端在接受注册时，会过滤服务提供者的各个方法，将合法的方法缓存起来。

服务端的核心逻辑是serveTransport方法，它接收一个Transport对象，然后在一个无限循环中从Transport读取数据并反序列化成请求，根据请求指定的方法查找自身缓存的方法，找到对应 的方法后通过反射执行对应的实现并返。执行完成后再根据返回结果或者是执行发生的异常组装成一个完整的消息，通过Transport发送出去。

服务端在反射执行方法时，需要将实现者作为执行的第一个参数，所以参数比方法定义中的参数多一个。

codec和protocol

这两个部分就比较简单了，codec基本上就是使用messagepack实现了对应的接口；protocol的实现就是根据我们定义的协议进行解析。

线程模型

在执行过程中，除了客户端的用户线程和服务端用来执行方法的服务线程，还分别增加了客户端轮询线程和服务端监听线程，大致的示意图如下：

这里的线程模型比较简单，服务端针对每个建立的连接都会创建一个线程（goroutine），虽说goroutine很轻量，但是也不是完全没有消耗的，后续可以再进一步进行优化，比如把读取数据反序列化和执行方法拆分到不同的线程执行，或者把goroutine池化等等。

结语

到此我们的RPC框架已经具备了雏形，能够支持基础的RPC调用了。实际上整个框架就是参考go自带的rpc的结构，客户端和服务端的线程模型和go自带的rpc一样，只是自己定义了序列化和消息协议，而且实现的过程中保留了扩展的接口，方便后续进行完善和扩展。下一步的规划是实现过滤器链，以便后续实现服务治理相关的功能。