以太坊RPC服务和比特币差不太多，所以一两个月前看的时候就没记录下来。最近因为项目需要在以太坊上做点东西，发现有些竟然有点忘了，于是赶紧记录下来。
RPC服务数据结构及时序数据流向图如下：
结构图总体摘要
APIS对象保存了系统所有定义和配置的service对象，startRPC启动时会将这些service对象的所有函数反射出来，保存到各种网络连接服务器(http, websocket, ipc)的server.services函数集对象里，供网络处理层调用。 当有新的连接时，会启动一个新的go router通过ServeRequest监听连接，等待并读取请求数据。当有请求数据时，会从services取对应的函数执行。
时序图如下
该时序图中，APIs接口收集和json rpc请求收到后的处理逻辑没有详细描述，将在下面单独说明
APIs服务接口收集
API收集流程不好看清，主要是里面的变量service的命名太复杂了。Service(工厂)，Service(大写，对象)和service(函数集):
APIs服务接口保存在node.apis，保存的是对象Service。它由两个“工厂Service”生成
1）node对象是一个“工厂Service”，apis函数返回“对象Service”数组
比如PrivateAdminAPI.AddPeer相当于定义了一个admin.AddPeer api
2)外部注册的“工厂Service”构造函数
外部注册的“工厂Service”构造函数是用来返回“工厂Service”
目前只注册了一个“工厂service”构造函数
如果是LightSync模式该构造函数会返回LightEthereum对象，否则是Ethereum对象，这两个对象应该都要有APIs函数
JSON RPC请求处理流程
比如用户通过geth命令行执行了如下命令
geth命令程序会将这条命令转化为如下json rpc调用
curl --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0xba4416..", "latest"],"id":1}' localhost:3534
从上面的时序图可知，收到JSON RPC请求后，readRequest会被唤醒，继续执行
readRequest返回时，jsoncodec已经解释了json数据，比如上面的命令就解释出namespace="eth", method="balance"，并保存在req对象中，然后返回到上一层serveRequest,然后的流程如下：
serveRequest->exec->handle->callb
/********************************
* 本文来自CSDN博主"爱踢门"
* 转载请标明出处:http://blog.csdn.net/itleaks
******************************************/
EOS技术交流群，EOS开发群，以太坊技术群:787804520
公众号: