Fabric通过组件化来分离各个实体，如节点和orderers，orderer提供了ordering服务，节点维持了账本和世界状态(world state)，同时链码的执行是独立于ordering服务，这种设计的主要目的是为了显著提高可扩展性。但是这种设计就需要一种通信方式来保证各个节点间的消息传播是可信，可扩展的并且是支持拜赞庭容错。用任何中心化通信方式都不能解决可信分布式问题，所以在区块链中使用基于点对点的数据传播基础架构，这种架构更适合于区块链的动态化和分布式特性。
数据传播基础架构约定了在区块链网络中数据只能在它相关的管道里进行传输，不在这个管道的成员节点接收不到这个管道的数据，这种约定或是限制让Fabric可以支持多管道的传输方式，同时能保证整个系统即使在少量节点的情况下也可以运行良好。但是ordering服务和节点分离机制同样也带来了在拜赞庭环境下更为复杂的数据传播和验证问题。所以引入了Gossip，在Fabric中gossip的主要目的是：
-
使得在一个管道内的所有节点都有相同的账本，同时避免所有的节点都连接到ordering服务上，缓解ordering服务的压力
-
当有新的节点加入，同步账本的操作可以独立于ordering服务
在Fabric里，所有经过共识之后的有序交易序列需要通知给所有的节点，让这些节点更新节点状态和账本信息。这种情况下，就要去ordering服务和节点之间有连接，并且可以传播已排序的交易信息。当然不是所有的节点都会连接到ordering服务上，连接到ordering服务的节点是选举出来的，被选举出来的节点通过标准的Deliver协议和ordering服务连接。这些节点负责分发接收到的交易数据到其他各个节点上。每个联盟或是组织都会选择一个Leader节点，由Leader节点连接ordering服务，并传播接收到的交易信息。
上述的数据传播方案要在状态转换，同步机制上起到关键作用。首先，对于由于某些情况下没有收到完整的交易的节点，基于gossip的状态同步机制要能保证这些节点在条件允许的情况下可以同步节点缺失的交易数据。其次，为了支持当系统运行一段时间后有新的节点加入情况，系统要提供一个基于反熵的状态同步，通过它可以在节点之间传输大数据量。
多管道的支持
管道的创建是用来定义信息分享的范围，并与账本相关连。每个交易都关联到某个管道，这个管道明确的定义了哪些节点是可以接收同步这个交易的。当管道被创建后，客户端SDK可以指示属于组织内的哪些节点加入到新创建的管道内。这些刚加入的节点通过gossip在全组织内广播。
为了使得gossip在多管道内可以正常工作，需要管道内的所有节点维护这个管道内的成员关系，通俗的说，就是管道内的每个节点都需要知道管道内的其他所有节点。对于新加入的节点，ordering服务需要确保该节点确实属于这个组织。作为Leader节点，则有义务和责任把从ordering接受来的消息分发给其他节点。Gossip组件是在管道中的成员关系创建好后才工作，这样保证了通过gossip网络传播的每一笔交易都在特定的成员关系群中传播，而不会传播到其他管道去。为了实现上述功能，当一个节点加入到一个管道后，客户端SDK会为这个节点提供该管道的最新配置来识别有哪些节点也加入了这个管道。如果是一个新的管道，配置信息为创世纪块。
当一个组织从一个管道上移除，客户端sdk会发送配置交易的背书申请，当背书签名后，交易将发送给ordering服务。每个gossip组件都会把消息发给那些没有被移除的节点。一开始，节点自己是不知道是否被移除的，在一段时间内没有接收到从其他节点发来的alive消息，才会知道原来自己已经被移除了这个组织。
覆盖完整的区块链知识体系，从入门到源码，这里有真正想要的区块链技术，欢迎大家关注微信号：蜗牛讲技术。扫下面的二维码
