Fabric 架构和概念(fabric网络架构原理)

当前大家对于Fabric 架构和概念都是颇为感兴趣的，那么小编也是在网络上收集了一些相关信息以便大家阅读。

本文基于fabric 1.0.4版本，如果相关概念有所改动，请以官方文档为准。

基本架构fabric构建的区块链网络是一个分布式系统，包含了一些逻辑节点，这些逻辑节点各司其职，完整的执行着交易的发起，验证，账本状态更新，一致性等功能。

主要概念01chaincodechaincode是一个按照一定规范实现的应用程序，运行于容器中，chaincode可以被安装到peer上，应用程序（客户端）通过发起交易请求，endsorer peer执行chaincode并进行签名，经过orderer的验证后，下发到对应的channel中，对账本进行更新。

02交易fabric中的交易分为两种，一是发布chaincode到peer的deploy transaction，二是chaincode的执行，称为invoke transaction:其实还可能存在query transaction（v1版本加入）和cross-chaincode transaction（v1之后的版本会加入），不过不在本文讨论范围内。

03Membership Service Provider由于fabric提供了权限控制，因此，对于peer和client来说，对于交易的结果和交易本身，都需要进行授权，这个组件是一个抽象的接口，它定义了提供权限控制的一系列标准，对于不同的网络，可以通过注入不同的实现来实现自己的认证授权机制。

04Membermember是fabric中最粗的逻辑单位，一个member可以类比于一个参与该交易网络的组织，例如在电商网络中，京东，淘宝都是一个member，这个member包含自己的root CA ，自己的集群用于维护账本。

区块链的结构01状态整个区块链的状态可以看作是一个 versioned KVS（带有版本的 key-value store，类似于git仓库），这些kv通过chaincode（智能合约）进行更新，它只提供了put和get方法，所有的状态变更都有日志记录。

02账本如上所述，区块链的账本，其实就是其 KVS模型的当前状态。

并且账本会记录所有的成功或失败的交易请求。

账本的修改都来自于orderer下发的事件，其中包含了打包好的block，这些block中，既包含成功的交易，也包含失败的交易，经过排序后形成一个顺序存储的结构保存在block中，而账本（区块链）就是这样一个一个block首尾相连所形成的数据集合。

03分布式账本前文提到了，所有的node上，都会存在一个当前账本（或子集）的副本，是否是子集，取决于该节点所在的组织（organization）是否能看到所有的交易信息。

而最全的账本，是在orderer node上，称之为orderer ledger，而存在于peer node上的账本，则称之为peerledger，peer还在本地维护了一个bitmap，用于标记ledger中哪些交易是invalid的，而ordererledger则主要作为（peerledger的）容错和高可用而存在。

04nodefabric 1.0中，定义了三种node，分别是：clientpeerorderer05clientclient模拟的是交易网络中的普通用户，普通用户连接到某个peer上，调用注册在该peer上的某个chaincode，从而完成对账本的更新06peerpeer node通过channel和orderer node建立了一种 发布/订阅的关系，orderer service会把其关心的息发通过channel发送给peer node，peer接收到这些交易后，就会更新本地账本（peerledger）的状态，peer可以说是fabric网络中最基本的节点，所有的账本和智能合约都存储在其中，同时，anchor peer负责某个org在某个网络中的代表，而lead peer则是本org的所有peer的首脑，order通过peer将数据的更新扩散到org。

07orderer由于fabric是一个分布式系统，因此每个node上都存储着一个账本，而当各个节点要对账本状态的修改时，必须有一个机制保证所有的这些CUDR操作的一致性，这就是orderer service，orderer service由一些orderer node组成，将所有提交的交易进行排序，验证，然后分发给对这个交易感兴趣（订阅了某个channel）的member（organization），使副本和原始账本保持一致。

08orderer APIbroadcast(blob): 客户端使用这个API来发起一次提交请求，该消息blob会被endsor，然后将其结果发送给ordererdeliver(seqno, prevhash, blob)：当orderer service验证了某个交易是有效性的（valid）后，会使用该API分发消息到对应的channel，所有订阅了这个channel的peer都会收到这个deliver消息，消息包含一个正整数序列号（seqno），前一个blob的hash值和blob消息体的。

09orderer 特性一言以蔽之，orderer有如下几个特性：一致性：经过orderer deliver的交易，seqno一定时，blob和prevhash都一样:hash链的完整性：对于deliver(seqno, hash0, blob0)和deliver(seqno-1, hash1, blob1)，HASH(seqno-1, hash1, blob1) == hash0:不会凭空创造交易：每一次deliver，都是由于一次boardcast产生的:不会缺失交易：如果一个deliver(seqno, hash, blob)已经发生，那么一定有deliver(seqno-1, hash0, blob0) ... deliver(0, default-hash, blob):不会重复交易：如果产生了两次 boardcast(blob)，boardcast(blob1)，则deliver(seqno1, hash, blob1)和deliver(seqno, hash0, blob)中，seqno1==seqno，hash==hash0，blob==blob1。

10channelchannel可以理解为一个独立的交易网络，每一个channel都维护着自己的账本，也可以理解为，一个账本对应了一个channel，这个channel中的账本的状态由所有订阅了该channel的member（organization）维护。

。

。

。

。

。

。

。

。

。

。

。

。

。

。

。

。

。

。

。

。

。