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 发布！
