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）退出技术交换群与咱们共话前沿～