Fabric源码分析

orderer模块的设计与实现

这一块参考《fabric源码分析与深入解读》做了部分总结，加深理解。当时想了解一下kafka共识，之后发现只有和orderer联系起来才能真正的理解可插拔的共识机制。这里提前先说一些要点：

1. orderer模块主要用到kingpin第三方包来执行配置命令，而peer模块主要用viper/cobra第三方包来执行配置命令。
2. order只做broadcast和deliver。broadcast主要是peer节点向order节点发送消息；deliver主要是order节点发送消息。
3. grpc分为客户端和服务端。对于grpc连接orderer来说，peer是客户端，orderer为服务端。
4. peer节点中的ledger的gossip服务起来之后就建立了与orderer的Deliver服务的连接，之后当orderer帐本中存在block数据之后，就开始主动向leader的Deliver客户端发送block数据，这个推送一直持续，Leader的Deliver客户端收到block流之后会使用gossip服务向自身和其他peer节点散播这些block数据。

数据流向

思维脑图

详情可以用xmind打开百度网盘连接 链接：https://pan.baidu.com/s/1HymBWX5sib_2rR_DRmqL1Q 提取码：hb92

fabric中使用kafka的基本目的是在多个peer结点同时向orderer服务发送消息时，能通过kafka形成一个串行的消息队列（队列中消息序号唯一，至此kafka的作用就算完成了），然后供cutter进行封装成一批批消息（即block），再将block写入orderer的ledger，也就形成了块链，最后供区域内各个peer结点中的leader获取orderer的ledger中的数据，然后由leader将数据在的区域中的各个peer结点间共享，形成了区块链。

---

流言算法gossip

Gossip算法又被称为反熵（Anti-Entropy），熵是物理学上的一个概念，代表杂乱无章，而反熵就是在杂乱无章中寻求一致，这充分说明了Gossip的特点：在一个有界网络中，每个节点都随机地与其他节点通信，经过一番杂乱无章的通信，最终所有节点的状态都会达成一致。每个节点可能知道所有其他节点，也可能仅知道几个邻居节点，只要这些节可以通过网络连通，最终他们的状态都是一致的，当然这也是疫情传播的特点。
gossip数据传输协议
peer结点“撬动”gossip以可测量的方式去广播（broadcast）账本和频道数据。gossip消息传送是是持续的，而且在频道中的每个peer不间断的从其它的peer那里接收当前的和一贯的（也就是格式等前后一致）账本数据（ledger data）。每个传播的消息都被签名过，因此“拜占庭的参与者”发送虚假的消息会很容易被识别，把消息发到消息不想到达的目标的分发行为会被阻止。peer会被延迟，网络参与者或者其他造成block丢失的原因所影响，但这些丢失block的peer最终将通过联系持有这些丢失block的peer异步更新到当前账本状态。（只有leader节点才会启动deliverservice模块）

以gossip为基础的数据传播协议在Fabric网络上执行三个基础的功能：

1. 通过持续性的识别有效成员peer和检测那些已经下线的peer，管理peer的发现（discovery）和频道成员关系。
2. 在频道上所有的peer之间传播账本数据。任何持有与频道其他peer结点不同步的数据的peer识别丢失的block并通过拷贝正确的数据来同步自身。
3. 通过允许账本数据以peer点对peer点（peer-to-pe