fabric v0.6
下图是Fabric v0.6版本的架构图
在v0.6版本中，主要分为Membership、Consensus、Chaincode、Ledger、P2P、Event Stream等核心模块。
- Membership：负责签发相应的E-cert、T-cert、TLS-cert等证书。会员注册、⾝身份保护、 内容保密、交易审计功 能，以保证平台访问的安全性。
- Consensus：负责整个区块链的共识，统一交易顺序，保证区块链的一致性。
- Chaincode：即链码（Fabric中的智能合约），用于执行区块链网络中的交易。
- Ledger：用于存储Transaction log以及交易中的Key-Value。
- P2P：基于Google的Grpc框架的底层网络通信层。
- Event Stream：事件订阅发布组建，用于接收交易及区块事件。贯穿于其他各个组件中间，为各个组件间的异步通信提供了技术实现
- 区块服务（Blockchain Services）：负责节点间的共识管理、账本的分布式计算、账本的存储以及节 点间的P2P协议功能的实现，是区块链的核⼼心组成部分，为区块 链的主体功能提供了底层⽀支撑。
在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的智能合约设计理论上可以支持任何开发语言，只要实现了相应的接口。因为它是基于Peer节点和链码容器的一个双向通信完成相应的交互的。
下图是一张Fabric v0.6版本的网络拓扑图
在这张图中包含了VP和NVP 2种角色，NVP在这里会分担VP的部分工作，接收来自客户端发过来的交易进行校验同时将交易请求转发至共识节点VP，由VP节点进行真正的共识，将交易写入区块。在这里NVP可以分担共识节点VP的处理交易的压力，可以提升共识的性能。
只有VP节点有投票权，也就是说VP节点达成共识，则整个Fabric网络达成共识；
NVP节点只有查询权利，没有共识权利
下图为Fabric v0.6的交易流程图
应用程序需要先向Membership申请E-cert，通过E-cert去申请T-cert，由T-cert对应的私钥进行签名客户端交易发送至VP节点进行三阶段共识，完成之后各个节点会通过Chaincode按顺序执行区块中的交易，并更新账本。
部分源码目录
bddtests：行为驱动开发
core：核心库，组件核心逻辑
devenv：开发环境，Vagrant
docs：相关文档
events：事件监听机制
examples：例子
images：docker镜像打包
peer：peer节点入口
proposals : 新功能提案
protos：grpc（protobuffer + rpc）；jsonrpc（json + rpc）
fabric0.6交易处理流程及调用关系分析
小结
Fabric v0.6版本可能由于1.0架构重构的原因，没有继续维护推进，但是相对于1.0版本的架构来说，这种设计来说，区块链角色相对对称，相对于1.0-1.4版本来说，不存在中心化的Kafka的存在，在实际场景中拥有更合理对等的节点设计。
