区块链技术 | Fabric架构演变之路

Hyperledger Fabric是目前主流的开源联盟链产品之一，自2016年5月12日开辟代码仓库之日起，已有快4年的时间了，产品趋于稳定，功能也越来越完善，正在适配不同业务场景下的需求。

纵观Fabric的发布历程，在v0.6.1-preview版本至v1.0.0的版本迁移过程中架构发生了明显的变化，在v1.0.0之后每个小版本中加入了一些新的feature，来支持不同的业务场景以及完善相应的功能。接下来从个人角度来谈谈Fabric架构变迁过程中的一点思考。

Fabric v0.6

v0.6版本的技术架构在整个发展过程中停留的时间较短，相对目前v1.x版本来说，不太稳定，适合做poc阶段的测试。

在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：事件订阅发布组建，用于接收交易及区块事件。

在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节点和链码容器的一个双向通信完成相应的交互的。

在这张图中包含了VP和NVP 2种角色，NVP在这里会分担VP的部分工作，接收来自客户端发过来的交