Fabric架构
Fabric网络
Fabric模块
Fabric交易流
根据Hyperledger Fabric 1.0架构，Fabric交易的整个生命周期可以分为7个阶段。我们可以从一个简单的例子分析下Fabric交易的7个阶段，然后读者可以清晰的理解每个环节，每个处理过程，这可以帮助开发人员理解Fabric的架构体系，只有深刻理解了Fabric的架构设计原理，在开发过程中遇到问题才能快速解决。
如下图反应了交易的整个生命周期以及交易于账本的交互。
第一阶段
在交易的第一阶段，客户端应用发起智能合约A的一个交易请求给背书节点E0。智能合约A配置的背书策略要求只需要E0,E1和E2签名。其他节点不包含在策略的要求中，因此可以不签名。注意图中的红色和蓝色小矩形块分别代表不同的子链或者叫通道，这个通道是1.0架构引入的新概念，用来实现各条业务链的数据隔离，保护交易的隐私性，避免像比特币那样的交易对所有人都公开。
如图所示，这里说明一下，图中的C代表共识网络（Consensus Network）,黄色的圆角矩形表示在peer上部署的智能合约。如E0，E1，E2上部署了A，B两个智能合约，E3上部署了A，D两个智能合约，而E4，E5上部署了Y，Z两个智能合约。
第二阶段
背书节点E0使用 MSP（MSP=Member Service Provider）验证签名，判断是否客户端应用被正确授权可以执行发起交易请求。背书节点获取交易请求中的参数（链代码）作为输入参数，然后E0会与交易对应ChainCode所属的docker实例通信，并为其提供模拟执行的State Database的读写集，也就是说ChainCode会执行完智能合约中的业务逻辑，但是并不会在stub.PutState的时候写数据库，ChainCode所属的docker实例执行完ChainCode后产生交易执行结果，然后将执行结构返回给E0。这个执行结果包括下列数据：响应值，读集合和写集合。不过，这个时候，并不会更新账本。这些值的集合，连同背书节点的签名和一个YES/NO 的陈述一起放到 proposal response 中返回给客户端应用（图中的Client App）。
第三阶段
客户端应用验证背书节点签名，然后继续发送背书请求给E1和E2，过程跟与E0的交互时一样。
第四阶段
背书节点E1和E2发送背书处理结果给客户端应用。客户端应用收集完所有背书节点的签名后，检查是否指定的背书策略已经满足。根据 Fabric 的架构设计，即使应用选择不检查交易的背书反馈，或者继续发送一个没有经过背书处理的交易，在commit交易的验证阶段，这个背书策略仍然会被peer 强制执行。
第五阶段
客户端应用将交易和响应信息封装到一个事务消息（transaction message）中，然后广
播到共识网络（这里的共识网络又称为排序服务Ordering Service，后续统一称为共识网络）。交易中包含读写集，背书节点签名和通道 ID。
共识网络节点不会关注交易细节和交易消息的具体内容，只是简单地从网络中接收来自所有通道的交易，然后按通道按时间顺序排序，处理的结果是一个Batch的交易，也就是一个区块，这个区块的产生有两种情况，一种情况是区块中的交易很多，区块的大小达到了配置文件中配置的大小，而另一种情况是区块中的交易很少，没有达到配置的大小，那么共识网络节点就会等，等到大小足够大或者超时时间。这些设置是在configtx.yaml中配置的。
开发人员如果要自定义出块的时间和每个区块内交易的数量，可以参考文档：
https://link.zhihu.com/?target=https%3A//github.com/hyperledger/fabric/blob/release/sampleconfig/configtx.yaml
主要的相关的配置项如下：
# Batch
Timeout: The amount of time to wait before creating a batch.
BatchTimeout: 2s
# Batch Size:
Controls the number of messages batched into a block.
BatchSize:
# Max Message
Count: The maximum number of messages to permit in a
# batch.
MaxMessageCount:
10
# Absolute Max Bytes: The absolute
maximum number of bytes allowed for
# the serialized messages in a batch.
If the "kafka" OrdererType is
# selected, set 'message.max.bytes' and
'replica.fetch.max.bytes' on the
# Kafka brokers to a value that is
larger than this one.
AbsoluteMaxBytes: 10 MB
# Preferred Max Bytes: The preferred
maximum number of bytes allowed for
# the serialized messages in a batch. A
message larger than the
# preferred max bytes will result in a
batch larger than preferred max
# bytes.
PreferredMaxBytes: 512 KB
# Max
Channels is the maximum number of channels to allow on the ordering
# network.
When set to 0, this implies no maximum number of channels.
MaxChannels:
0
这里主要的配置项是BatchTimeout和MaxMessageCount。
BatchTimeout是配置多久产生一个区块，默认是2秒，通常在项目实践中，我们发现交易量并不大，如果配置的时间过小就会产生很多空的区块，配置时间太长，则发现等待产生区块的时间太长。具体时间由交易频率和业务量决定。我们实际项目中，通常配置在30秒。
MaxMessageCount是配置在一个区块中允许的交易数的最大值。默认值是10。交易数设置过小，导致区块过多，增加orderer的负担，因为要orderer要不断的打包区块，然后deliver给通道内的所有peer,这样还容易增加网络负载，引起网络拥堵。我们实际项目中通常配置500，不过具体还应该看业务情况，因为如果每个交易包含的数据的size如果太大，那么500个交易可能导致一个区块太大，因此需要根据实际业务需求权衡。
读者可能有一个疑问，这里有2个参数可以配置区块的出块策略，那么究竟那个因素优先发生作用呢？实际上根据Fabric设计的出块策略，BatchTimeout和MaxMessageCount的任何一个参数条件满足，都会触发产生新的区块。举个例子，假设我们配置了出块时间BatchTimeout为30秒，块内交易最大数量MaxMessageCount为500。第一种情况，当出块时间为20秒(时间上还没达到出块要求)，但是交易数已经累积到500个了，这个时候也会触发新的区块产生。第二种情况，交易数才1个，但是出块时间已经30秒了，这个时间也会触发新的区块产生，尽管这个新的区块里只有一个交易。
Fabric的这种出块策略设计相比还是比较灵活的，可配置的。相比而言，在比特币中，大家都知道出块机制是固定的，就是每隔10分钟（600秒）产生一个区块，就一个陌生，不可更改。而以太坊类似，也是基于事件的出块策略，只是时间更短，每15秒产生一个区块。因此，Fabric的出块策略在设计上还是比较进步的。
第六阶段
共识服务节点将打包的区块广播道同一个通道的所有peer，通过Fabric提供的deliver RPC服务，共识服务节点和peer节点之间的通信细节，我们在稍后详细介绍。必须说明的是，E4和E5不在同样的通道上（或者说不属于同样的子账本），因此E4,E5不会收到任何更新消息。另外，共识网络节点只是涉及到排序交易和打包区块，不会执行智能合约。
第七阶段
Peers收到共识网络发来的区块后，会先进行以下校验：
n 再次验证区块中的交易以确保背书策略满足。
n 检查区块的数据是否正确。
n 对每个交易进行验证，确保自从读集合数据在交易执行生成后，读集合变量对应的账本的状态没有变化，也就是验证交易中的读写数据集是否与State Database的数据版本一致。
验证通过后，区块中的交易打上合法和非法交易的标签，然后添加区块到通道对应的链上，同时把所有验证通过的交易的读写集中的写的部分写入状态数据库State Database。对于每个合法交易，写集合被提交到当前的状态数据库。同时，一个区块事件产生并发出，通知客户应用，交易已经不可更改的添加到了链上，也是告诉应用客户端，交易是合法还是非法。
另外对于区块链，本身是文件系统，不是数据库，所有也会有把区块中的数据在LevelDB中建立索引。
