order service是fabric中独有的一个概念，它主要用于对收到的数据进行排序，打包区块，并通过共识算法，分发到各个节点中去。所以fabric中的共识算法则是在order节点中体现。如需系统的学习fabric，可以参考视频教程

值得我们多说一句的是orderer admin可以维护联盟的信息，联盟的信息保存在orderer的system channel 中。如何创建联盟，可以参考我写的其他博客。

那么order service是如何处理接收到的数据的？

1、客户端将请求发送给peer节点，peer节点进行背书，将背书后的提案返回给客户端。

2、此阶段客户端将背书提案的tx提交给order节点，order会根据tx排序并打包成区块。

3、此阶段将打包好的区块分发到连接到order的peer节点，并非所有的peer都必须链接到order，peer之间共享账本可以通过gossip方式进行区块共享传递。每一个peer独立的对接收到区块做校验，来验证是否正确的背书，如果验证不通过，就不会更新world state。

orderer service的实现有一下几种，但是无论是哪一种共识，都不会产生分叉，因为进行打包区块的操作，是由固定的order节点进行操作的，同一时刻只有一个order节点在进行打包区块，而比特币因为存在同一时刻，有两个节点同时计算出hash值的概率，所以存在分叉，在fabric打包区块的设置中，触发打包区块有两个参数尤为重要，一个为batchsize，此参数是用于控制每个区块里可以存储的数据的条数，当达到这一配置的时候自动打包成一个区块，还有一个是timeout，当收到第一条数据达到这个时间的时候就会打包区块，那么在此timeout时间内的数据会同时打包到区块中。

solo 模式

单节点此种方式使用于测试开发环境，因为此种方式无法提高系统的吞吐量，同时无法与order节点之间进行容错。

kafka模式

kafka也是一种cft容错的一种基于zk实现leader-folower模式。kafka半去中心化。

raft模式

raft模式基于raft协议实现的共识算法，打包区块有leader节点进行。

需要注意的是对于一个智能合约的开发者来说，order共识算法的实现是透明的，同时fabric是支持可插拔式的修改共识算法。

本文由博客一文多发平台
OpenWrite 发布！