HyperLeger Fabric开发（三）——HyperLeger Fabric架构
一、HyperLeger Fabric逻辑架构
1、HyperLeger Fabric逻辑架构简介
Fabric逻辑架构根据不同角度进行划分，上层基于应用程序角度进行设计，包括SDK、API、事件，通过SDK、API、事件来对底层区块链进行操作：包括身份管理、账本管理、交易管理、智能合约的部署和调用；下层基于底层区块链进行设计，对外提供成员管理服务、共识服务、链码服务、安全和密码服务。
Fabric为应用开发提供了标准的gRPC接口，在API的基础上封装了不同语言的SDK，包括Go、NODE.JS、Java、Python等，开发人员可以利用SDK开发基于区块链的应用；同时，区块链的强一致性要求各个节点之间达成共识需要较长的执行时间，应用程序也是采用异步通信的模式进行开发的，事件模块可以在触发区块事件或者链码事件的时候执行预先定义的回调函数。
Fabric通过将各个部分分离成不同的模块，做到可插拔性、灵活扩展性。
2、应用层逻辑架构
（1）身份管理
联盟链考虑到商业应用对安全、隐私、监管、审计、性能的需求，提高准入门槛，成员必须被许可才能加入网络。Fabric是目前为止在设计上最贴近联盟链思想的区块链。联盟链考虑到商业应用对安全、隐私、监管、审计、性能的需求，提高准入门槛，成员必须被许可才能加入网络。Fabric成员管理服务为整个区块链网络提供身份管理、隐私、保密和可审计的服务。成员管理服务通过公钥基础设施PKI和去中心化共识机制使得非许可的区块链变成许可制的区块链。
Fabric区块链中，采用数字证书机制负责对网络中的成员身份进行管理，CA节点实现了PKI服务。
PKI（Public Key Infrastructure）是综合多种密码学手段来实现安全可靠传递消息和身份确认的一个框架和规范。通常，PKI包括三部分：CA（Certification Authority）负责证书的颁发和作废，接收来自RA的请求； RA（Registration Authority）负责对用户身份进行验证，校验数据合法性，负责登记，审核通过则发给CA；证书数据库用于存放证书，一般采用LDAP目录服务，标准格式采用X.500系列。
CA是PKI体系最核心的组件，主要完成对公钥的管理。密钥有两种类型：用于签名和用于加解密，对应称为签名密钥对和加密密钥对。 用户基于PKI体系要申请一个证书，一般可以由CA来生成证书和私钥，也可以自己生成公钥和私钥，然后由CA来对公钥进行签发。
（2）账本管理
授权的用户是可以查询账本数据的，可以通过多种方式查询，包括：
A、根据区块号查询区块
B、根据区块哈希查询区块
C、根据交易号查询区块
D、根据交易号查询交易
E、根据通道名称查询区块链信息
（3）交易管理
账本数据只能通过交易执行才能更新，应用程序通过交易管理提交提案(Proposal)，在获取到足够数量交易背书(Endorsement)后，再给排序服务节点提交交易，排序服务将批量交易打包生成区块。SDK提供接口，利用用户证书本地生成交易号，背书节点和记账节点都会校验是否存在重复交易。
（4）智能合约
Fabric的智能合约（Smart Contract）称为链码（ChainCode），是一段代码，用于处理网络成员所同意的业务逻辑。Fabric的链码和底层账本是分开的，升级链码时并不需要迁移账本数据到新链码当中，真正实现了逻辑与数据的分离。
Fabric通过智能合约实现了可编程的账本，通过链码执行提交的交易，实现基于区块链的智能合约业务逻辑。只有智能合约才能更新账本数据，其它模块不能直接修改状态数据。
链码可采用Go、Java、Node.js语言编写。链码被编译成一个独立的应用程序，Fabric用Docker容器来运行链码，容器里的base镜像都是经过签名验证的安全镜像，包括OS层和开发链码的语言、runtime和SDK层。一旦链码容器被启动，就会通过gRPC与启动链码的Peer节点连接。
3、底层逻辑架构
（1）成员服务管理
MSP（Member Service Provider）成员服务模块对成员管理进行了抽象，提供包括会员注册，身份保护、内容保密、交易审计等功能，可以使用可插拔的Fabric-CA模块或第三方的CA来代替。
（2）共识服务
共识服务负责节点间共识管理、账本的分布式计算、账本的存储及节点间的P2P协议功能的实现，是区块链的核心组成部分，为区块链的主体功能提供了底层技术支撑
（3）链码服务
链码服务为智能合约实现提供了一系列接口，并为链码的安装、运行、部署提供了环境。智能合约的实现依赖于安全的执行环境，确保安全的执行过程和用户数据的隔离。Fabric采用Docker管理普通的链码，提供安全的沙箱环境和镜像文件仓库，可支持多种语言的链码。
（4）安全和密码服务
安全问题是企业级区块链关心的问题，Hyperledger Fabric专门定义了一个BCCSP（BlockChain Cryptographic Service Provider）模块，实现密钥生成、哈希运算、签名验签、加密解密等基础功能。
4、HyperLeger Fabric逻辑架构的特点
Hyperledger Fabric采用模块化架构设计，利用通用的功能模块和接口。模块化的方法带来了可扩展性、灵活性等优势，会减少模块修改、升级带来的影响，能很好的利用微服务实现区块链应用系统的开发和部署。
（1）模块插件化
Fabric很多功能模块（如CA模块、共识算法、状态数据库存储、ESCC、VSCC、BCCSP等）都是可插拔的。Fabric提供的通用接口和默认实现可以满足大多数的业务需求，同时功能模块也可以根据需求进行扩展，集成到Fabric区块链网络系统中。
（2）充分利用容器技术
Fabric中不仅节点使用容器作为运行环境，链码也默认运行在安全的容器中。应用程序或者外部系统不能直接操作链码，必须通过背书节点提供的接口转发给链码来执行。容器给链码运行提供安全沙箱环境，把链码的环境和背书节点的环境隔离开，链码存在安全问题也不会影响到背书节点。
（3）可扩展性
Hyperledger Fabric1.x版本对节点的角色进行了不同的拆分，有主节点(Leader)、背书节点(Endorser)、记账节点(Committer)、排序服务节点(Orderer)等，不同角色的节点有不同的功能。节点可以加入不同的通道中，链码可以运行在不同的背书节点上，可以更好的提升并行执行的效率和吞吐量。
（4）安全性
Hyperledger Fabric提供授权访问的区块链网络，节点共同维护成员信息，只有MSP(Member Service Provide)模块验证、授权的终端用户才能使用区块链网络的功能。多链和多通道的设计容易实现数据隔离，也提供了应用程序和链码之间的安全通道，实现了隐私保护。
二、HyperLeger Fabric网络架构
1、HyperLeger Fabric网络架构简介
Fabric网络是通过组织来划分的，每个组织内都包含承担不同功能的Peer 节点，每个Peer节点又可以担任多种角色。所有的组织共用一个统一的Orderer排序服务集群。基于Hyperledger Fabric区块链网络的设计时需要考虑组织之间的业务关系以及内部每个模块之间的联系，统一进行规划。
Fabric网络包含客户端节点、CA节点、Peer节点、Orderer节点。
每个组织通常拥有自己的客户端、Peer节点和CA节点，并且可以根据需要创建一个或多个不同的类型节点。Orderer节点不属于某个组织的实体，属于组织共同维护的节点。
2、客户端节点
客户端或应用程序代表由终端用户操作的实体，必须连接到某一个Peer节点或者排序服务节点上与区块链网络进行通信。客户端向背书节点（Endorser Peer）提交交易提案(Proposal)，当收集到足够背书后，向排序服务节点广播交易，进行排序，生成区块。
客户端的主要作用是与Fabric区块链交互，实现对区块链的操作。区块链操作分为管理类和链码类的两种，管理类操作包括启停节点和配置网络等；链码类操作主要是链码的生命周期管理，如安装、实例化以及调用链码。最常用的客户端是命令行客户端（CLI），此外是使用Fabric SDK开发的应用客户端。
3、CA节点
CA节点主要给Fabric网络中的成员提供基于数字证书的身份信息，可以生成或取消成员的×××书（certificate）。CA节点是Fabric网络的证书颁发节点(Certificate Authority)，由服务器(fabric-ca-server)和客户端(fabric-ca-client)组成。
CA节点接收客户端的注册申请，返回注册密码用于登录，以便获取×××书。在区块链网络上所有的操作都会验证用户的身份。
CA节点是可选的，也可以用其它成熟的第三方CA颁发证书。
4、Peer节点
Fabric区块链网络中的每个组织可以拥有一到多个Peer节点。每个Peer节点可以担任多种角色：Endorser Peer（背书节点）、Leader Peer（主节点）、Committer Peer（记账节点）、Anchor Peer（锚节点）。
每个Peer节点必定是一个记账节点，除记账节点外，也可以担任其它一到多种角色，即某个Peer节点可以同时是记账节点和背书节点，也可以同时是记账节点、背书节点、主节点，锚节点。
（1）Endorser Peer（背书节点）
部分Peer节点会执行交易并对结果进行签名背书，充当背书节点的角色 。
背书(Endorsement)是指特定Peer节点执行交易并向生成交易提案( proposal )的客户端应用程序返回YES/NO响应的过程。
背书节点是动态的角色，是与具体链码绑定的。每个链码在实例化的时候都会设置背书策略(Endorsement policy)，指定哪些节点对交易背书才有效。
也只有在应用程序向节点发起交易背书请求时才成为背书节点，其它时候是普通的记账节点，只负责验证交易并记账。
（2）Leader Peer（主节点）
主节点负责和Orderer排序服务节点通信，从排序服务节点处获取最新的区块并在组织内部同步。可以强制设置，也可以选举产生。
（3）Committer Peer（记账节点）
负责验证从排序服务节点接收的区块里的交易，然后将区块提交（写入/追加）到其通道账本的副本。记账节点还将每个块中的每个交易标记为有效或无效。
（4）Anchor Peer（锚节点）
在一个通道上可以被所有其它Peer节点发现的Peer节点，通道上的每个成员都有一个Anchor Peer(或多个Anchor Peer来防止单点故障)，允许属于不同成员的Peer节点发现通道上的所有现有Peer节点。
5、Orderer（排序服务节点）
排序服务节点接收包含背书签名的交易，对未打包的交易进行排序生成区块，广播给Peer节点。
排序服务提供的是原子广播，保证同一个链上的节点为接收到相同的消息，并且有相同的逻辑顺序。
排序服务独立于Peer进程存在并且以先来先服务的方式对Fabric网络上的所有通道进行排序交易。排序服务旨在支持超出现有的SOLO和Kafka的可插拔实现。排序服务是整个网络的公共绑定，包含绑定到每个成员的加密身份材料。
排序服务节点按照一定规则确定交易顺序后，发给各个记账节点，把交易持久化到区块链的账本中。排序服务节点支持互相隔离的多个通道，使得交易只发送给相关的记账节点（Peer节点）。
三、Fabric多链多通道设计
1、通道简介
商业应用的一个重要的需求是私密×××易，为此Fabric设计了通道（Channel）来提供成员之间的隐私保护。通道是部分网络成员之间拥有独立的通信渠道，在通道中发送的交易只有属于通道的成员才可见，因此通道可以看作是Fabric的网络中部分成员的私有通信子网。
通道由排序服务管理。在创建通道的时候，需要定义通道的成员和组织、锚节点（anchor peer）和排序服务节点，一条与通道对应的区块链会同时生成，用于记录账本的交易，通道的初始配置信息记录在区块链的创世区块中，可以通过增加一个新的配置区块来更改通道的配置信息。
每个组织可以有多个节点加入同一个通道，组织内的节点中可以指定一个锚节点或多个锚节点（增强系统可靠性，避免单点故障）。组织的锚节点代表本组织与其它组织的节点交互，从而发现通道中的所有节点。另外，同一组织的节点会选举或指定主导节点（leading peer），主导节点负责接收从排序服务发来的区块，然后转发给本组织的其它节点。主导节点可以通过特定的算法选出，可以保证在节点数量不断变动的情况下仍能维持整个网络的稳定性。
在Fabric网络中，可能同时存在多条彼此隔离的通道，每条通道包含一条私有的区块链和一个私有账本，通道中可以实例化一个或多个链码，以操作区块链上的数据。
2、Fabric多链多通道设计
Fabric 1.x版本支持多链和多通道。Fabric的一条区块链是包含Peer节点、账本、排序服务的逻辑结构，将参与者与数据（包含链码）进行隔离，满足不同业务场景下的不同的人访问不同数据的基本要求。
通道是共识服务提供的一种通讯机制，基于发布-订阅关系，将Peer节点和排序节点根据某个Topic连接在一起，形成一个具有保密性的通讯链路（虚拟），实现业务隔离的要求。
排序服务提供了供Peer节点订阅的主题（如发布-订阅消息队列），每个主题是一个通道。Peer节点可以订阅多个通道，并且只能访问自己所订阅通道上的交易，因此一个Peer节点可以通过接入多个通道参与到多条链中。
目前通道分为系统通道（System Channel）和应用通道（Application Channel）。排序服务通过系统通道来管理应用通道，用户的交易信息通过应用通道传递。
通道由排序服务节点负责管理，同时排序服务节点还负责对通道中的交易进行排序。在通道中一般包含有若干成员（组织），若两个网络实体的×××书能够追溯到同一个根CA，则认为这两个实体属于同一组织。此外，通道中的每个组织都会有一个或以上的锚节点，锚节点负责与其它组织交换共享账本的数据。
创建通道的时候定义了成员，只有通过成员MSP验证的实体，才能够加入到通道并访问通道的数据。
排序服务支持多通道，提供了通向客户端和Peer节点的共享通信通道，提供了包含交易的消息广播服务（broadcast和deliver）。客户端可以通过通道向连接到通道的所有节点广播（broadcast）消息，向连接到通道的所有节点投递(deliver)消息。多通道使得Peer节点可以基于应用访问控制策略来订阅任意数量的通道，应用程序根据业务逻辑决定将交易发送到1个或多个通道。
共识服务与（P1、PN）、（P1、P2、PN）、（P2、PN）组成三个相互独立的通道，加入到不同通道的Peer节点能够维护各个通道对应的账本和状态。不同通道对应现实世界中不同业务场景下的参与方，如银行、保险公司、物流企业、生产企业等实体结构。
3、通道的配置
通道的配置信息都被打包到一个区块中，并存放在通道的共享账本中，成为通道的配置区块，配置区块除了配置信息外不包含其它交易信息。通道可以使用配置区块来更新配置，因此在账本中每新添加一个配置区块，通道就按照最新配置区块的定义来修改配置。通道账本的首个区块一定是配置区块，也称为创世区块（Genesis Block）。
4、通道管理命令
通道的CLI客户端可以使用命令对通道进行管理。
peer channel create: 用于创建通道，主要参数有-c, -f, -o分别用于指定通道ID, configtx的路径和orderer的地址。
peer channel fetch：抓取通道中的特定区块，通过-c和-f参数来指定通道ID和orderer地址。
peer channel join：加入通道，通过-b参数指定初始区块。
peer channel list：列出peer加入的通道。
peer channel update ：签名并且发送configtx以升级通道配置，需要通过-c, -f, -o参数分别指定通道ID, configtx的路径以及排序节点的地址。
5、动态修改通道配置
在通道创建后，通道相关的配置以区块的形式存在于通道的账本中。如果需要修改通道的配置，可通过生成新的配置区块去更新。修改通道配置的步骤如下：
A、通过SDK或CLI获得最新的配置区块。
B、编辑配置区块。
C、计算配置更新量。
D、为配置区块添加配置更新量。
E、SDK或CLI签名并发送配置区块。
若新的配置区块通过验证，则通道配置以最新配置区块为准。
四、交易流程简介
1、交易简介
Fabric区块链的交易分两种，部署交易和调用交易。
部署交易把链码部署到Peer节点上并准备好被调用，当一个部署交易成功执行时，链码就被部署到各个背书节点上。
调用交易是客户端应用程序通过Fabric提供的API调用先前已部署好的某个链码的某个函数执行交易，并相应地读取和写入KV数据库，返回是否成功或者失败。
2、Fabric交易流程简介
Fabric v1.0的交易流程如下：
区块链的账本由Peer节点维护，并不是由排序服务集群维护，所以，只有Peer节点（背书节点和确认节点）包含完整的区块链信息，而排序服务集群只负责对交易进行排序，只保留处理过程中的一部分区块链信息。Hyperledger Fabric网络中的节点是一个逻辑的概念，并不一定是一个台物理设备，但对于生产环境，为了系统架构的解耦，提高扩展性以及通过主机隔离提高安全性，Peer节点不能和排序服务节点部署在一台机器上，而背书节点和确认节点可以部署在同一台机器上。背书节点校验客户端的签名，然后执行智能合约代码模拟交易。交易处理完成后，对交易信息签名，返回给客户端。客户端收到签名后的交易信息后，发给排序服务节点排序。排序服务节点将交易信息排序打包成区块后，广播发给确认节点，写入区块链中。
3、客户端构造交易提案
客户端应用程序利用SDK（Node.js，Java，Python）构造交易提案（Proposal）。交易提案是一个调用智能合约功能函数的请求，用来确认哪些数据可以读取或写入账本。
客户端把交易提案发送给一个或多个背书节点，交易提案中包含本次交易要调用的合约标识、合约方法和参数信息以及客户端签名等。
SDK将交易提案打包为可识别的格式（如gRPC上的protobuf），并使用用户的加密凭证为该交易提案生成唯一的签名。
4、背书节点模拟执行交易
背书节点（endorser）收到交易提案后，验证签名并确定提交者是否有权执行操作。背书节点将交易提案的参数作为输入，在当前状态KV数据库上执行交易，生成包含执行返回值、读操作集和写操作集的交易结果（此时不会更新账本），交易结果集、背书节点的签名和背书结果（YES/NO）作为提案的结果返回给客户端SDK，SDK解析信息判断是否应用于后续的交易。
5、客户端把交易发送到排序服务节点
客户端应用程序（SDK）验证背书节点签名，并比较各节点返回的提案结果，判断提案结果是否一致以及是否参照指定的背书策略执行。
客户端收到各个背书节点的应答后，打包到一起组成一个交易并签名，发送给排序服务节点。
6、共识排序，生成新区块
排序服务节点对接收到的交易进行共识排序，然后按照区块生成策略，将一批交易打包到一起，生成新的区块，调用deliver API投递消息，发送给确认节点。
7、交易校验
确认节点收到区块后，会对区块中的每笔交易进行校验，检查交易依赖的输入输出是否符合当前区块链的状态，完成后将区块追加到本地的区块链，并修改K-V状态数据库。
五、账本简介
Fabric使用建立在HTTP/2上的P2P协议来管理分布式账本，采取可插拔的方式来根据具体需求来设置共识协议，比如PBFT，Raft，PoW和PoS等。
Fabric网络的数据以分布式账本的形式存储。账本由一系列有顺序和防篡改的记录组成，记录包含着数据的全部状态改变。账本中的数据项以键值对的形式存放，账本中所有的键值对构成了账本的状态，称为世界状态（World State）。
每个通道中有唯一的账本，通道的账本由通道中所有成员共同维护，每个记账节点上都保存所属通道的账本的一个副本，因而是分布式账本。对账本的访问需要通过链码实现对账本键值对的增加、删除、更新和查询等操作。
账本由区块链和状态数据库两部分组成。
区块链是一组不可更改的有序的区块（数据块），记录着全部交易的日志。每个区块中包含若干个交易的数据，不同区块所包含的交易数量可以不同。区块之间用哈希链（Hashed-link）关联：每个区块头包含本区块所有交易的哈希值，以及上一个区块头的哈希值。链式结构可以确保每个区块的数据不可更改，以及每个区块之间的顺序关系不可更改。因此，区块链的区块只可以添加在链的尾部。
状态数据库记录了账本中所有键值对的当前值，相当于对当前账本的交易日志做了索引。链码执行交易的时候需要读取账本的当前状态，从状态数据库可以迅速获取键值的最新状态。
如果没有状态数据库，要获得某个键值时，需要遍历整个区块链中和该键值相关的交易，效率非常低，因此，读取状态数据库可以认为是快速定位和访问某个键值的方法。另外，当状态数据库出现故障的时候，可以通过遍历账本重新生成。
当一个区块附加到区块链尾部的时候，如果区块中的有效交易修改了键值对，则会在状态数据库中作相应的更新，确保区块链和状态数据库始终保持一致。
区块链的数据块以文件形式保存在各个节点中。状态数据库可以是各种键值数据库，Fabric缺省使用LevelDB ，同时支持CouchDB选项。CouchDB除了支持键值数据外，也支持JSON格式的文档模型，能够做复杂的查询。
六、Fabric开发流程
1、Fabric开发简介
Fabric联盟链的开发人员主要分为三类：底层开发者负责系统部署与维护；组织管理者负责证书、MSP权限管理、共识机制等；业务开发者负责编写链码、创建维护通道、执行交易等。
2、Fabric区块链开发流程
Fabric区块链开发流程主要包括智能合约编写，通过SDK调用智能合约，订阅各类事件。
开发者创建客户端应用和链码，链码被部署到区块链网络的背书节点上。通过链码来操作账本，当客户端调用一个交易时，实际上是在调用链码中的一个实现业务逻辑的函数方法，并对账本进行get, put, delete操作。客户端应用提供用户交互界面，并提交交易到区块链网络上。