本文微信公众号 月牙寂道长 文章链接为：https://mp.weixin.qq.com/s/sMZC79DLS3ITTly8cSHwZw

本文图片可能不太清晰，看清晰版本的，可以看原文链接微信公众号链接。

以太坊go-ethereum源码的模块划分非常清晰，所以其各个模块，几乎是相互独立的。

有一个以太坊的架构图：

图片来自：https://blog.csdn.net/s_lisheng/article/details/77990523

（已得到原作者转载许可）

以太坊源码分析---go-ethereum之MPT(Merkle-Patricia Trie) 是讲解其中Trie模块

以太坊源码分析---go-ethereum之event 是讲解event模块的

此次分析的是事件rpc模块

代码结构如下

github.com/ethereum/go-ethereum/rpc

版本为go-ethereum-1.8.9

其分层架构图为：

应用层：rpc server，rpc client

表示层：数据的编码 json

会话层：建立、终止、管理会话链接（http、inproc、ipc、subscription、websocket）

有了这个分层架构图，我们就可以分层进行源码分析了。

server

先从示例代码开始看，主要是看server的主要功能流程

github.com/ethereum/go-ethereum/rpc/server_test.go

上面准备了一个struct，有8个方法。

其中Echo，EchoWitchCtx、Sleep、Rets、Subscription为5个callback

其中Subscription又为subscription

79：创建了一个server

80：创建了一个service

82：关键步骤：将service注册到server中。 RegisterName

86：server中的service是2个，这个后面解释

90：从server中取出service

95：callbacks为5个。说明rpc方法的注册是要遵循标准的，并不是什么方法都是可以注册为callback

99：subscription为1个。

那么下面开始根据流程介绍

github.com/ethereum/go-ethereum/rpc/types.go

rpc函数

40：服务的类型

41：rpc方法

42：参数

43：是否有ctx。可以参考test中的函数Echo，EchoWitchCtx

45：标识是否为subscribe。可以参考test中的函数Subscription

66：services的合集

67：callback的合集

68：Subscription callback的合集

50：service的名字

51：服务的类型

52：callback的合集

53：Subscription callback的合集

72：service的合集

74：run标志位

github.com/ethereum/go-ethereum/rpc/server.go

初始化创建server

47-51：创建新的server结构体

55：创建RPCService结构体

56：将rpcservice注册到server中。这是第一个注册的服务，名字为“rpc”。

这也是为什么在test中service数量为2的原因

const MetadataApi = "rpc"

RPCService结构体其实就是Server的封装

关键步骤RegisterName

80-82：判断server中的services是否初始化了，没有则初始化

84：初始化一个service

85：获取要注册的service的类型（type）

86：获取要注册的service中的value（其中包含了方法）

95：关键步骤：根据reflect获取到的value，进行遍历过滤出callback和Subscription

96-108：根据service的name，查找是否已经存在在server中，如果存在，则刷新callback和Subscription

111：初始化service的name

112：初始化service的callbacks和Subscriptions

118：将service注册到server中

那么注册流程就是如此的。其中函数suitableCallbacks就不深入分析了。

那rpc服务注册好了，怎么提供服务呢？

这里面就涉及到了应用层与表示层之间的衔接

github.com/ethereum/go-ethereum/rpc/types.go

应用层与表示层的衔接是通过这个interface做到的

github.com/ethereum/go-ethereum/rpc/json.go

json提供了两个方法NewCode与NewJsonCodec来构建基于json的ServerCodec

表示层与会话层是如何连接的呢

以上可以查找到

http、inproc、ipc的衔接过程

以上是websocket的衔接过程

我们以http为例

github.com/ethereum/go-ethereum/rpc/http.go

创建httpserver

以上是httpserver的入口ServerHttp

184-187：ctx的准备

190：创建了一个jsonCodec

194：进入到server的处理流程 ServeSingleRequest

github.com/ethereum/go-ethereum/rpc/server.go

这里提供了两个入口。其中关键的参数为ServerCodec

ServeCodec

ServeSingleRequest

两者最大的差别在于参数SingleShot为true还是false。表明的是，一次是单个Request还是多个Request。

下面进入到server的入口

131-141：当服务退出后，资源释放。其中139，将codec释放掉

144 ：ctx

153-159：将codec放入到set中

继续

163：从codec中读取request

164-173：判断读取过程是否有错误，有，则退出

177-189：判断server是否正常运行，不是，则退出

最终的流程到了这里

191-198：singleshot，指的是单个request。

    其中batch为单个request包含了多个req

201-207：是多个requests的处理

exec是执行rpc的最终地方

334：关键步骤：handle执行rpc函数的地方，并返回Response。

337：将Response通过codec写入，返回给调用者

344：subscribe的回调函数执行

execbatch与exec不同的地方就是，一次性有多个request，遍历执行。

最终的执行rpc函数地方handle

最终的地方在这里

296-309：准备rpc call的参数

312：执行rpc函数

看看Response是怎么返回给用户的

github.com/ethereum/go-ethereum/rpc/json.go

调用了encode

而encoder的参数是io.ReadWriteCloser

github.com/ethereum/go-ethereum/rpc/http.go

回到http入口，初始化的时候，将body传入了NewJSONCodec中。

到此server的流程全部打通

client

client的流程相对会简单一些

github.com/ethereum/go-ethereum/rpc/client.go

入口为Dial

针对不同类型的，有不同的入口

还是以http为例

github.com/ethereum/go-ethereum/rpc/http.go

构建了一个Client

client构建好了，就要调用Call了

199：http模式下调用的sendhttp

301：非http模式下调用send

92：doRequest是关键步骤

99：读取Response

97：解码Response

110：将结果返回

132：将请求用json编码

140：关键步骤：client.Do，这里就是最终构建发送http链接请求的地方

144：状态码返回检查

147：返回resp

client的流程相对要简单的多，就不继续细化分析。

龚浩华

月牙寂道长

QQ 29185807

2018年09月06日

如果你觉得本文对你有帮助，可以转到你的朋友圈，让更多人一起学习。

第一时间获取文章，可以关注本人公众号：月牙寂道长，也可以扫码关注