Hyperledger Fabric是目前支流的开源联盟链产品之一，自2016年5月12日开拓代码仓库之日起，已有快3年的工夫了，产品趋于稳定，性能也越来越欠缺，正在适配不同业务场景下的需要。
纵观Fabric的公布历程，在v0.6.1-preview版本至v1.0.0的版本迁徙过程中架构产生了显著的变动，在v1.0.0之后每个小版本中退出了一些新的feature，来反对不同的业务场景以及欠缺相应的性能。接下来从集体角度来谈谈Fabric架构变迁过程中的一点思考。
Fabric v0.6
v0.6版本的技术架构在整个倒退过程中停留的工夫较短，绝对目前v1.x版本来说，不太稳固，适宜做poc阶段的测试。
下图是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：事件订阅公布组建，用于接管交易及区块事件。
在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的解决交易的压力，能够晋升共识的性能。
下图为Fabric v0.6的交易流程图
应用程序须要先向Membership申请E-cert，通过E-cert去申请T-cert，由T-cert对应的私钥进行签名客户端交易发送至VP节点进行三阶段共识，实现之后各个节点会通过Chaincode按程序执行区块中的交易，并更新账本。
小结
Fabric v0.6版本可能因为1.0架构重构的起因，没有持续保护推动，然而绝对于1.0版本的架构来说，这种设计来说，区块链角色绝对对称，绝对于1.0-1.4版本来说，不存在中心化的Kafka的存在，在理论场景中领有更正当对等的节点设计。
Fabric v1.x
Fabric在1.0版本的时候，架构进行了重构，相比于v0.6版本来说，有了颠覆性的改革，功能模块进行了结偶，具备了更好的可伸缩性、性能，进行了channel级别的平安隔离，共识算法可插拔，具备了更高的可操作性，具备了更丰盛的性能，给开发者更好的体验，v0.6版本中的Membership也降级为了一个独立的Fabric CA我的项目。
Fabric v1.x版本中，对节点进行了性能的拆分，明确了各个节点的指摘，将背书的信赖假如和排序的信赖假如进行了拆分。变动最大的中央在于，在共识流程中将交易的执行进行了提前，由Endorser节点进行模仿执行，并进行背书，排序节点Orderer会对所有的交易进行对立的打包排序，将其分发给Committer节点。这种设计的劣势在于能够将前后无关联的交易以及不同Channel中的交易进行并行执行，进步交易的执行速度。在v0.6版本中是无奈做到并行执行的，0.6中是对立进行排序打包，而后按序执行交易，即便交易前后是无关的。下图也很好地体现了Fabric v1.x中的一个网络拓扑。
下图是Fabric v1.x版本的架构图
在v1.x版本中，次要分为Fabric CA、Endorser、Committer、Orderer、Application等角色。
Fabric CA：负责保护整个Fabric网络中的证书，次要包含签发、撤消、续签证书等操作。
Endorser：负责对客户端发过来的交易提案进行背书。
Comitter：负责对区块进行有效性校验并将区块写入账本。
Orderer：负责对所有的交易进行全局惟一的排序打包工作。
Application：用于发送交易提案，收集响应，封装交易发送至Orderer排序服务节点。
在1.0及当前的版本中，客户端利用会先向Fabric CA申请用户所须要的Fabric中的准入证书，用于签名提案以及交易，而后由客户端（Application）端生成一个提案（Proposal）(个别应用程序会借助于目前Fabric提供的一系列SDK生成Proposal)发送至背书节点进行模仿执行并进行背书，背书节点Endorser会进行相应的校验，而后将提案交由对应的链码Chaincode进行模仿执行，之后背书节点Endorser会对执行后果进行背书,将背书的Response返回至客户端程序Application，随之，客户端程收集到合乎背书策略的提案响应（Proposal Response）之后，将其封装成一个交易Transaction，调用排序节点Orderer的Broadcast接口，进行发送交易至Orderer，在v1.0-v1.4版本中，生产环境只有基于分布式音讯队列Kafka的排序打包形式，Orderer作为生产者将交易对立发送至每个通道Channel对应的Topic的Partition当中进行全局对立地排序，同时每个排序节点基于同样的切块规定从Kafka中将区块切下推送Deliver至与之连贯的Leader Peer（在网络环境良好的状况下，每个组织只有一个leader），Leader Peer收到区块后，会将区块通过Gossip协定播送至组织内其余节点。每个Committer在收到区块之后会对区块进行校验，包含签名、背书策略以及读写集的校验，在校验无误的状况下进行commit，提交到账本，同时更新世界状态，同时订阅了相应事件的应用程序会收到来自Event Hub的音讯告诉。
下图是一个Fabric v1.x的简化版本的交易流程。
此外，在v1.0之后，Fabric强调了组织的概念，在Peer节点的层级上，每个组织须要配置一个或者多个Anchor Peer节点，来代表组织在整个区块链网络启始之处与别的组织替换节点信息，使得每个节点都可能把握整个网络的节点信息。
同时，在v1.0之后，Fabric退出了多通道技术（Muti-channel），使得一个Fabric网络中可能运行多个账本，每个通道间的逻辑互相隔离不受影响，如下图所示，每种色彩的线条代表一个逻辑上的通道，每个Peer节点能够退出不同的通道，每个通道都领有独立的账本、世界状态、链码以及Kafka中的Topic，通道间音讯是隔离的，互不影响的。
在Fabricv1.x中，多通道技术是用于在业务逻辑层面做的一个全局的，用于隔离不同业务的通道，使得不同业务的交易存储在不同的通道对应的节点中，通道技术的实现次要在Orderer中实现，Orderer对来自不同通道的交易做辨别，同时在Peer节点中会采纳MSP对不同通道的音讯做校验，用于判断音讯是否属于某个通道，通过Orderer以及Peer相结合，造成一个逻辑上的通道技术。
在背书和提交校验阶段，Fabric提出了2个零碎链码，ESCC和VSCC：
- ESCC：用于为链码执行后果进行背书。
- VSCC：用于对接管到的区块中的交易进行校验。
在存储方面，v1.0也进行了优化，存储的设计分为2个局部，一个局部是区块的存储，采纳的是File System即传统的文件系统，这里设计成采纳文件存储的起因在于：区块链中的区块是一直向后追加的，即一直append的，不存在随机写的状况，如果采纳Key-Value数据库可能会存在数据压缩或者相干的索引算法的耗费，在这种场景下，File System会优于K-V数据库，因而不论是Orderer还是Peer，对于区块存储局部，均采纳File System进行存储，对于Block的索引，则采纳Level DB进行存储保护，会依据BlockHash、BlockNumber、TxId等作为Key进行存储，而Value则是区块或者交易所在的Segment号+offset(偏移)，用于疾速依据Key来定位所须要的区块或者交易。
此外，对于世界状态的存储，这里指State DB，在v1.0当前能够用Level DB或者Couch DB进行存储，依据存储的数据的复杂程度，以及链码的业务逻辑能够抉择不同的数据库，比方须要针对Json数据进行索引则能够采纳Couch DB来进行存储，如果是一般的Key-Value则能够采纳Level DB进行存储。
下图是Fabric v1.0当前的存储的设计图。
Fabric v1.0之后的CA，从Fabric v0.6到v1.0，Fabric CA是从Membership这个模块所衍生进去的，承当整个Fabric网络数字证书的签发、续签以及撤消等工作，作为一个独立的服务存在。同时Fabric CA反对多级CA，以保障根CA的相对平安，同时存储局部也是可插拔的，能够抉择MySQL、LDAP、Postgres等，能够采纳HA Proxy做负载平衡。
Fabric v1.1
Fabric v1.1版本次要的新个性包含：
Fabric CA的CRL
区块以及交易的事件推送
减少了所有组建间的双向TLS通信
Node.js Chaincode链码的反对
Chaincode API新增了creator identity
性能绝对v1.0有了显著的晋升
Fabric v1.2
Fabric v1.2开始有了比拟大的feature开始呈现：
Private Data Collections：这个个性不得不说在隐衷爱护上解决了不少我的项目的痛点，也缩小了许多我的项目为了隐衷爱护在业务层做的简单设计。
Service Discovery：服务发现这个个性，使得客户端领有了更多的灵活性和可操作性，能够动静感知整个Fabric网络的变动。
Pluggable endorsement and validation：可插拔的背书及校验机制，采纳了Go Plugin机制来实现，防止了之前须要从新编译源代码的操作，晋升了灵活性。
Fabric v1.3
Fabric v1.3中，同样减少了非常有用的feature：
基于Identity Mixer的MSP Implementation：基于零常识证实实现的身份的匿名和不可链接，这个feature代替了v0.6版本中的T-cert。
key-level endorsement policies：更细粒度的背书策略，细化到具体的key-value，更加灵便，不仅限于一个链码程序作背书。
新增Java Chaincode：至此，v1.3之后反对了Go、Node.js、Java 三种Chaincode，为开发者提供了更多的抉择。
Peer channel-based event services：Channel级别的事件订阅机制，早在v1.1版本中曾经亮相了，在v1.3版本中正式公布，至此，旧的Event Hub正式宣告弃用。
Fabric v1.4
Fabric v1.4是一个里程碑式的版本，是首个LTS的版本（Long Term Support的版本）：
可操作性和可维护性的晋升：
凋谢日志级别设置的接口
凋谢节点衰弱状态的查看接口
凋谢节点数据指标的收集接口
改良了Node SDK的编程模型，简化开发者的代码复杂度，使得SDK更加易用
Private Data的加强：
对于后续增加的容许拜访节点可能获取之前的隐衷数据
增加客户端层面的隐衷数据的权限管制，不须要增加链码逻辑
总结
对于Fabric的架构变迁，从v0.6版本到v1.0版本有了绝对较大的变动，而v1.0至v1.4之间，也收集了来自业界的不少需要，进行了欠缺，减少了许多实用的性能，目前v1.4版本后续的小迭代会对目前存在的bug进行fix，而新的大feature则会在将来的v2.0版本中公布，敬请期待吧！更多区块链技术探讨，增加小助手18458407117（vx）退出技术交换群与咱们共话前沿～