HyperLeger Fabric开发（三）——HyperLeger Fabric架构

Fabric区块链网络包括客户端（Client），网络节点（Peer），CA（Certificate Authority）节点和排序节点（Orderer）。

客户端的主要作用是与Fabric区块链交互，实现对区块链的操作。区块链操作分为管理类和链码类的两种，管理类操作包括启停节点和配置网络等；链码类操作主要是链码的生命周期管理，如安装、实例化以及调用链码。最常用的客户端是命令行客户端（CLI），此外是用Fabric SDK开发的应用客户端。用户通过不同的客户端使用Fabric网络的功能。

Peer节点是区块链去中心化网络中的对等节点，按照功能主要分为背书节点（Endorser）和确认节点（Committer，记账节点）。背书节点主要对交易提案进行校验、模拟执行和背书；确认节点主要负责检验交易的合法性，并更新和维护区块链数据和账本状态。在实际部署中，背书节点和确认节点既可以部署在同一物理节点上，也可以分开部署。

排序节点（Orderer）主要职责是对各个节点发来的交易进行排序。在并发的情况下，各个节点交易的先后时序需要通过排序节点来确定并达成共识。排序节点按照一定规则确定交易顺序后，发给各个记账节点，把交易持久化到区块链的账本中。排序节点支持互相隔离的多个通道，使得交易只发送给相关的记账节点（Peer）。

CA节点主要给Fabric网络中的成员提供基于数字证书的身份信息，可以生成或取消成员的×××书（certificate）。在成员身份明确的基础上，Fabric可以实现权限控制的管理。

Fabric网络的组件往往归属于不同的组织，在组织之间形成对等的去中心化网络。每个组织通常拥有自己的客户端、网络节点和CA节点，并且可以根据需要创建一个或多个不同的类型节点。排序节点不属于某个组织的实体，属于组织共同维护的节点。

Fabric区块链的架构设计如下：

HyperLeger Fabric v1.0版本的架构包括三大部分:身份管理（Identity）、账本和交易（Ledger | Transactions），智能合约（Smart Contact）。

为了方便应用开发，Fabric提供不同的SDK，对服务端的链码开发，目前提供 Go 、 Java 或者Node.js语言的SDK；对客户端应用开发，目前提供Node.js、Java语言、Go语言版本的SDK。Fabric提供了RESTAPI，对于开发者，可以通过CLI快速去测试链码，或者去查询交易状态。在区块链网络里，节点和链码会发送事件来触发一些监听动作，方便与其它外部系统的集成。

Fabric使用建立在HTTP/2上的P2P协议来管理分布式账本，采取可插拔的方式来根据具体需求来设置共识协议，比如PBFT，Raft，PoW和PoS等。

Fabric网络的数据以分布式账本的形式存储。账本由一系列有顺序和防篡改的记录组成，记录包含着数据的全部状态改变。账本中的数据项以键值对的形式存放，账本中所有的键值对构成了账本的状态，称为世界状态（World State）。

每个通道中有唯一的账本，通道的账本由通道中所有成员共同维护，每个记账节点上都保存所属通道的账本的一个副本，因而是分布式账本。对账本的访问需要通过链码实现对账本键值对的增加、删除、更新和查询等操作。

账本由区块链和状态数据库两部分组成。

区块链是一组不可更改的有序的区块（数据块），记录着全部交易的日志。每个区块中包含若干个交易的数据，不同区块所包含的交易数量可以不同。区块之间用哈希链（Hashed-link）关联：每个区块头包含本区块所有交易的哈希值，以及上一个区块头的哈希值。链式结构可以确保每个区块的数据不可更改，以及每个区块之间的顺序关系不可更改。因此，区块链的区块只可以添加在链的尾部。

状态数据库记录了账本中所有键值对的当前值，相当于对当前账本的交易日志做了索引。链码执行交易的时候需要读取账本的当前状态，从状态数据库可以迅速获取键值的最新状态。

如果没有状态数据库，要获得某个键值时，需要遍历整个区块链中和该键值相关的交易，效率非常低，因此，读取状态数据库可以认为是快速定位和访问某个键值的方法。另外，当状态数据库出现故障的时候，可以通过遍历账本重新生成。

当一个区块附加到区块链尾部的时候，如果区块中的有效交易修改了键值对，则会在状态数据库中作相应的更新，确保区块链和状态数据库始终保持一致。

区块链的数据块以文件形式保存在各个节点中。状态数据库可以是各种键值数据库，Fabric缺省使用LevelDB ，同时支持CouchDB选项。CouchDB除了支持键值数据外，也支持JSON格式的文档模型，能够做复杂的查询。

业务通道，即共识网络或区块链网络，由不同的节点构成。节点是区块链的通信实体，是一个逻辑概念，不同类型的节点可以运行在同一台物理服务器上。节点可能部署在云上或者本地，可能来自不同的公司或者组织。排序服务提供了供Peer节点订阅的主题（如发布-订阅消息队列），每个主题是一个通道。Peer节点可以订阅多个通道，并且只能访问自己所订阅通道上的交易。

在区块链网络中有两种类型的节点：Peer节点和Orderer节点。

Peer节点：链码部署在Peer节点（背书节点）上，对账本进行读写操作。一个Peer节点可以充当多种角色，如背书节点（endorser），确认节点（committer）。一个区块链网络中会有多个Peer节点。

Orderer节点：对交易进行排序，批量打包交易，生成区块，发给Peer节点（记账节点）。一个区块链网络中会有多个Orderer节点，共同提供排序服务。排序服务可以以多种不同的方式实现，从一个中心化的服务（被用于开发和测试，如Solo）到分布式协议（如Kafka）。

排序服务提供了通向客户端和Peer节点的共享通信通道，提供了包含交易的消息广播服务（broadcast和deliver）。客户端可以通过通道向通道内的所有节点广播（broadcast）消息，通道可以向连接到通道的所有节点投递(deliver)消息。

排序服务支持多通道。客户端和Peer节点可以连接到一个具体的通道，并通过通道发送和接收消息。多通道使得Peer节点可以基于应用访问控制策略来订阅任意数量的通道；应用程序在指定Peer节点的子集中架设通道，Peer节点组成提交到该通道交易的相关者集合，而且只有通道内的Peer节点可以接收包含相关交易的区块，与其它交易完全隔离，实现数据隔离和保密。

此外，Peers的子集将私有块提交到不同的账本上，允许它们保护这些私有交易，与其它Peer子集的账本隔离开来。应用程序根据业务逻辑决定将交易发送到1个或多个通道。

Peer 1，2和N订阅红色通道，并共同维护红色账本；Peer 1和N订阅蓝色通道并维护蓝色账本；Peer 2和peer N在黑色通道上并维护黑色账本。每个通道都有一个相关的账本，通常，不涉及所有Peer节点的账本为子账本，另一种是系统账本，即全账本。

目前通道分为系统通道（System Channel）和应用通道（Application Channel）。排序节点通过系统通道来管理应用通道，用户的交易信息通过应用通道传递。

通道由排序服务节点负责管理，同时排序服务节点还负责对通道中的交易进行排序。在通道中一般包含有若干成员（组织），若两个网络实体的×××书能够追溯到同一个根CA，则认为这两个实体属于同一组织。此外，通道中的每个组织都会有一个或以上的锚节点，锚节点负责与其它组织交换共享账本的数据。

创建通道的时候定义了成员，只有通过成员MSP验证的实体，才能够加入到通道并访问通道数据。

Fabric v1.0的交易流程如下：

区块链的账本由Peer节点维护，并不是由排序服务集群维护，所以，只有Peer节点（背书节点和确认节点）包含完整的区块链信息，而排序服务集群只负责对交易进行排序，只保留处理过程中的一部分区块链信息。Hyperledger Fabric网络中的节点是一个逻辑的概念，并不一定是一个台物理设备，但对于生产环境，为了系统架构的解耦，提高扩展性以及通过主机隔离提高安全性，Peer节点不能和排序服务节点部署在一台机器上，而背书节点和确认节点可以部署在同一台机器上。背书节点校验客户端的签名，然后执行智能合约代码模拟交易。交易处理完成后，对交易信息签名，返回给客户端。客户端收到签名后的交易信息后，发给排序服务节点排序。排序服务节点将交易信息排序打包成区块后，广播发给确认节点，写入区块链中。

客户端应用程序利用SDK（Node.js，Java，Python）构造交易提案（Proposal）。交易提案是一个调用智能合约功能函数的请求，用来确认哪些数据可以读取或写入账本。

客户端把交易提案发送给一个或多个背书节点，交易提案中包含本次交易要调用的合约标识、合约方法和参数信息以及客户端签名等。

SDK将交易提案打包为可识别的格式（如gRPC上的protobuf），并使用用户的加密凭证为该交易提案生成唯一的签名。

背书节点（endorser）收到交易提案后，验证签名并确定提交者是否有权执行操作。背书节点将交易提案的参数作为输入，在当前状态KV数据库上执行交易，生成包含执行返回值、读操作集和写操作集的交易结果（此时不会更新账本），交易结果集、背书节点的签名和背书结果（YES/NO）作为提案的结果返回给客户端SDK，SDK解析信息判断是否应用于后续的交易。

客户端应用程序（SDK）验证背书节点签名，并比较各节点返回的提案结果，判断提案结果是否一致以及是否参照指定的背书策略执行。

客户端收到各个背书节点的应答后，打包到一起组成一个交易并签名，发送给排序服务节点。

排序服务节点对接收到的交易进行共识排序，然后按照区块生成策略，将一批交易打包到一起，生成新的区块，调用deliver API投递消息，发送给确认节点。

Fabric联盟链的开发人员主要分为三类：底层开发者负责系统部署与维护；组织管理者负责证书、MSP权限管理、共识机制等；业务开发者负责编写链码、创建维护通道、执行交易等。

Fabric区块链开发流程主要包括智能合约编写，通过SDK调用智能合约，订阅各类事件。

开发者创建客户端应用和链码，链码被部署到区块链网络的背书节点上。通过链码来操作账本，当客户端调用一个交易时，实际上是在调用链码中的一个实现业务逻辑的函数方法，并对账本进行get, put, delete操作。客户端应用提供用户交互界面，并提交交易到区块链网络上。