上一篇中提及，想理解Peer节点完成的事情，就要分析这几个server的工作原理。那gRPC远程调用成为一个绕不过去的坎，笔者最近抽空便对其进行了简要梳理。
gRPC是做什么的呢？
“gRPC 是一个高性能、开源和通用的 RPC 框架，面向移动和 HTTP/2 设计。gRPC 基于 HTTP/2 标准设计，带来诸如双向流、流控、头部压缩、单 TCP 连接上的多复用请求等特性。这些特性使得其在移动设备上表现更好，更省电和节省空间占用。” 这便是官方给出的grpc介绍。
说说自己的理解吧：grpc其实是google自己研发的一套远程过程调用框架。在分布式应用中，各异构的程序组件之间进行互相调用，从而协同完成任务。这就牵扯到分布式通信之间的消息通信机制，以及方法的调用。google使用proto buffer来定义消息的报文以及服务，通过服务的客户端与服务端通信完成rpc调用。
这在官方文档里其实有基本的介绍：http://doc.oschina.net/grpc?t=60133。
那么fabric是如何使用gRPC来完成peer节点的工作呢？管中窥豹，我们就以events事件为线索来说明基本的定义原理吧。
在fabric源码结构中，src/protos/peer/events.proto是用来定义事件的通信服务的。在定义了.proto文件后，就可以通过protoc命令把协议文件转换成go语言版本的协议定义，命名为events.pb.go。
使用命令如下：protoc --go_out=plugins=grpc:. events.proto
proto文件中主要有两类关键字：message和service。message是定义的消息构成，类似于程序中的结构体，生成的go语言协议也确实是这么转换的，定义为struct；service是定义的rpc调用，这是整个协议的关键部分。
events协议分析
在events协议中定义了两个服务：Events和Deliver。定义如下图：
events和deliver服务定义
值得注意的是，不要以service作为整体去理解服务，而应该拆分为每个rpc调用作为一个分析单元。因为在生成go语言的协议时，其定义是按rpc调用维度去定义的。比如Deliver是一个服务，但是里边却有两个调用：Deliver和DeliverFiltered。
先大概介绍每个调用的功能：
Chat：事件传输机制，双方通过事件通知对方有哪些事情发生。
Deliver与DeliverFiltered：传输区块信息。
那么转换成go版本的协议是怎样的呢？以Chat调用为例，我们分析下。
客户端代码分析
eventClient
eventschatclient
client端分为两部分：
1. eventsClient结构体实现了EventsClient接口，外部调用者通过NewEventsClient可以获得客户端对象；利用这个对象调用Chat与服务端建立通道连接，并返回eventsChatClient；
2. eventsChatClient可以理解为与服务端建立的通道的客户端对象，这个对象实现了Send和Recv方法，用于写入请求或者读取返回结果。
服务端代码分析
eventsServer
eventChatServer
eventserviceDesc
服务端也分为两部分：
1. eventsServer是定义rpc调用的接口，服务端的外部调用者使用按自己的功能需求去实现接口中的Chat函数。并通过RegisterEventsSever将server对象注册到grpc启动的服务器当中。
2. eventsChatServer是与客户端建立通道的服务端对象，这个对象实现了Send和Recv方法，用于读取请求或者写入返回结果给客户端。
值得一提的是，_Event_Chat_Handler是通过反射机制来调用服务端定义的Chat的。
以上便是gRPC运行的原理，使用方法就是上述的客户端和服务端分别要做两件事情：外部生成客户端对象（或服务器端对象）；两端都要实现各自的Chat接口，但是客户端默认已生成，可以直接获取ChatClient对象，服务端并没有具体实现，需要外部调用者根据功能来实现。具体的操作都要利用其Recv和Send函数来完成消息读取与写入。
Events消息
Chat调用之间的消息如何流转呢？从定义可看出，请求时使用了SignedEvents，返回结果使用了Events。他们之间又是什么关系呢？
其实SignedEvents是把Events进行了封装，并多添加了一个signature字段，是客户端的一个签名，服务端可以利用签名确定里边的Events确实是发送者本人并且没有被篡改。服务端返回时使用Events，它不需要标明自己身份。
协议中定义的其他消息：FilteredBlock，Register等等，都是为Event消息服务的，可以鉴别出这个事件具体是哪种类型的事件。
今天暂且分析至此吧，下次专门梳理之前的6种server分别是哪些组件之间建立的rpc调用。梳理清楚后，整个peer框架应该就能理顺了。
网友评论