Fabric v0.6版本与v1.x版本 架构差异很大，故分两个版本讲
Fabric v0.6版本
在Fabric v0.6中采用的共识算法是PBFT算法（Practical Byzantine Fault Tolerance）,可以在信任程度较低的场景下避免拜占庭问题。但是由于算法本身特性限制，n>=3f+1，才能容忍一个拜占庭节点，因此在v0.6版本下，vp节点数量至少是4个。在v0.6版本中，节点角色分为VP(Validating Peer)、NVP(None validating Peer)以及用于签发证书的Membership节点3种。当然Fabric从第一个版本v0.6.0-preview开始就采用基于docker的运行时环境，为部署减少了许多麻烦，屏蔽了操作系统的差异。当然最主要的一点也许是由于Chaincode的设计机制导致的，整套生产环境的链码的部署和运行都是基于docker的，也许是出于docker稳定以及相对安全的运行环境的考量。Fabric的智能合约设计理论上可以支持任何开发语言(目前支持 Go, Node.js, Java)，只要实现了相应的接口。因为它是基于Peer节点和链码容器的一个双向通信完成相应的交互的。
Fabric v0.6版本，相对于1.0版本的架构来说，这种设计来说，区块链角色相对对称，相对于1.0-1.4版本来说，不存在中心化的Kafka的存在，在实际场景中拥有更合理对等的节点设计。
Fabric v1.x
Fabric在1.0版本的时候，架构进行了重构，相比于v0.6版本来说，有了颠覆性的变革，功能模块进行了结偶，具有了更好的可伸缩性、性能，进行了channel级别的安全隔离，共识算法可插拔，具备了更高的可操作性，具备了更丰富的功能，给开发者更好的体验，v0.6版本中的Membership也升级为了一个独立的Fabric CA项目。
这种设计的优势在于可以将前后无关联的交易以及不同Channel中的交易进行并行执行，提高交易的执行速度。在v0.6版本中是无法做到并行执行的，0.6中是统一进行排序打包，然后按序执行交易，即使交易前后是无关的。
Kafka共识
在v1.0-v1.4版本中，生产环境只有基于分布式消息队列Kafka的排序打包方式，Orderer作为生产者将交易统一发送至每个通道Channel对应的Topic的Partition当中进行全局统一地排序，同时每个排序节点基于同样的切块规则从Kafka中将区块切下推送Deliver至与之连接的Leader Peer（在网络环境良好的情况下，每个组织只有一个leader），Leader Peer收到区块后，会将区块通过Gossip协议广播至组织内其余节点。
多通道技术（Muti-channel）
一个Fabric网络中能够运行多个账本，每个通道间的逻辑相互隔离不受影响，如下图所示，每种颜色的线条代表一个逻辑上的通道，每个Peer节点可以加入不同的通道，每个通道都拥有独立的账本、世界状态、链码以及Kafka中的Topic，通道间消息是隔离的，互不影响的。
每个Peer节点可以配置加入到多个不同的通道,不同业务的交易存储在不同的通道对应的节点中
系统链码
- ESCC：用于为链码执行结果进行背书。
- VSCC：用于对接收到的区块中的交易进行校验。
存储
- File System 即传统的文件系统: 区块存储部分
- Level DB : 记录 Block的索引, 世界状态的存储
配置文件
Fabric网络在启动之前，需要提前生成一些用于启动的配置文件，主要包括MSP相关文件（msp/）、TLS相关文件（tls/）、系统通道初始区块（orderer.genesis.block）、新建应用通道交易文件（businesschannel.tx）、锚节点配置更新交易文件Org1MSPanchors.tx和Org2MSPanchors.tx）等。
