在区块链的世界中，总括而言分别有公有链、联盟链、私有链三种类型，早前的文章亦介绍了很多关于公有链（比特币区块链、以太坊区块链）的资料，当中也经常提到联盟链和私有链，但联盟链和私有链对于大家来说，却是比较陌生，可能只知识有这种类型，而对当中的细节可能不太了解。

在公有链上，所有节点都透过共识机制共同维护着"同一个"账本，这个账本记录着所有Transaction（交易），为了在所有互不认识的节点之间达成维护账本的一致性及安全，舍弃了交易效率，导致效率低下（目前比特币区块链中，每秒只有7笔交易），这是优点也是缺点，同时亦存在匿名公开化的问题，并非完全具有私密性。

在商业世界上，每笔数据或交易的处理效率、私密性是相当重要，所以企业很难将与企业之间的业务放在公有链上，正因如此，也是为何会出现有公有链、联盟链、私有链三种类型的区块链。而联盟链则会较适用于企业间（联盟）内部进行商业往来的方式，就好比互联网的和公司局域网，各有其各自的用法和优缺点。

超级账本

过去由IBM 带头联同Intel及Cisco等巨头发起的一个联盟链项目－Hyperledger（超级账本），整个项目由2015年底转移给Linux 基金会托管，成为开源项目。Hyperledger 项目中有5 个子项目，其中，Fabric 是当中最有名的一个，一般而言，大家常说的Hyperledger（超级账本），实质上指的就是Fabric。

Hyperledger Fabric

Hyperledger Fabric 是一个企业区块链框架，主要为采用模块化架构的区块链应用及解决方案提供开发基础，追求模块化（Modular）、扩展化（Scalable）、安全化（Secure）。Hyperledger Fabric 可以令共识机制（Consensus）、会员服务（Membership Services）等"组件"可被即插即用（Plug-and-Play）。而在Hyperledger Fabric 中的智能合约则可以透过"Chaincode"实现。

接下来就深入看看 Hyperledger Fabric 的架构。

Hyperledger Fabric 架构

Fabric 1.0 ，将Peer 节点按功能进行分解为Endorser, Committer, Ledger, Events, Chaincode，同时把共识机制从节点中抽取出来，独立成为Orderer 节点提供即插即用的共识机制，而且加入了多通道（ Multi-Channel）功能，可实现了多业务隔离。

多通道（Multi-Channel）

Hyperledger Fabric 中的链（Chain）包含了链码（Chaincode）、账本（ledger）、通道（Channel）的逻辑结构，它将参与方（Organization）、交易（Transaction）进行隔离，满足了不同业务场景不同的人访问不同数据的基本要求。通常我们说的多链在运维层次上也就是多通道。一个Peer 节点可以接入多条通道，从而加入到多条链，参与到不同的业务中。

图中（P1、P2）、（P1、P2、PN）、（P2、P3）组成了三个相互独立的链，Peer 节点只需维护自己加入的链的账本信息，不会感知到其他链的存在。这种模式与现实业务场景有诸多相似之处，不同业务有不同的参与方，不参与该业务，也不应该看到业务相关的任何信息。

多通道特性是Fabric 在商用区块链领域推出的杀手锏，当然也不完美，虽然Peer 节点不能看到不相关通道的交易，但是对于orderer 节点来说，还是所有通道的交易都可以看到，虽然可以使用技术手段分区，但无疑增加了复杂度。

账本结构

账本是一系列有序的、不可篡改的状态转移记录日志。状态转移是链码（Chaincode）执行交易（Transaction）的结果，每个交易都是通过增删改操作提交一系列键值对到账本。一系列有序的交易被打包成块，这样就将账本串联成了区块链。同时，一个状态数据库维护账本当前的状态，因此也被叫做世界状态。在Fabric 1.0 中，每个通道都有其账本，每个Peer 节点都保存着其加入的通道的账本，包含着交易日志（账本数据库）、状态数据库以及历史数据库。

账本状态数据库实际上存储的是所有曾经在交易中出现的键值对的最新值。调用链码执行交易可以改变状态数据，为了高效的执行链码调用，所有数据的最新值都被存放在状态数据库中。就逻辑上来说，状态数据库仅仅是有序交易日志的快照，因此在任何时候都可以根据交易日志重新生成。状态数据库会在Peer 节点启动的时候自动恢复或重构，未完备前，该节点不会接受新的交易。状态数据库可以使用LevelDB 或者CouchDB。LevelDB 是默认的内置的数据库，CouchDB 是额外的第三方数据库。跟LevelDB 一样，CouchDB 也能够存储任意的二进制数据，而且作为JSON 文件数据库，CouchDB 额外的支撑JSON 富文本查询，如果链码的键值对存储的是JSON，那么可以很好的利用CouchDB 的富文本查询功能。

Fabric 的账本结构中还有一个可选的历史状态数据库，用于查询某个key 的历史修改记录，需要注意的是，历史数据库并不存储key 具体的值，而只记录在某个区块的某个交易里，某key 变动了一次。后续需要查询的时候，根据变动历史去查询实际变动的值，这样的做法减少了数据的存储，当然也增加了查询逻辑的复杂度，各有利弊。

账本数据库是基于文件系统，将区块存储于文件块中，然后在LevelDB 中存储区块交易对应的文件块及其偏移，也就是将LevelDB 作为账本数据库的索引。文件形式的区块存储方式如果没有快速定位的索引，那么查询区块交易信息可能是噩梦。现阶段支持的索引有：

区块编号 区块哈希 交易ID 索引交易 区块交易编号 交易ID 索引区块 交易ID 索引交易验证码

链码Chaincode

Fabric 架构更多的是针对Fabric 平台运维工程师，而对更多的应用开发者来说，链码其实才是最重要的。链码（Chaincode）是Hyperledger Fabric 提供的智能合约，是上层应用与底层区块链平台交互的媒介。现阶段，Fabric 提供Go、Java 等语言编写的链码。所有的链码都继承两个接口，init 和invoke。init 接口用于初始化合约，在整个链码的生命周期里，该接口仅仅执行一次。剩下的invoke 接口是编写业务逻辑的唯一入口，虽然只有一个入口，但是可以根据参数传递的不同自由区分不同业务逻辑，灵活性很高。比如应用开发者规定Invoke 接口的第一个参数是合约方法名，剩余的Invoke 参数列表是传递给该方法的参数，那么就可以在Invoke 接口方法体中根据方法名的不同分流不同业务了。

那么在合约里能够获取哪些内容呢合约接口能获得数据分为三类：

输入参数获取 这点很好理解，我们只有知道此次调用的输入，才能处理逻辑，推导输出； 与状态数据库和历史数据库交互 在合约层，我们可以将区块链底层当做是一个键值对数据库，合约就是对数据库中键值的增删改查； 与其他合约的交互 在合约执行的过程中，可以与其他合约交换数据，做到类似跨链的效果。有了这种形式的数据获取方式，其实就可以将联系不紧密的业务逻辑拆分为多个合约，只在必要的时候跨合约调用，非常类似于现在提倡的微服务架构。

编写链码还有一个非常重要的原则：不要出现任何本地化和随机逻辑。此处的本地化，不是指语言本地化，而是执行环境本地化。区块链因为是去中心架构，业务逻辑不是只在某一个节点执行，而是在所有的共识节点都执行，如果链码输出与本地化数据相关，那么可能会导致结果差异，从而不能达成共识。比如，时间戳，随机函数等。这些方法是链码编程的禁地，除非你知道你的用意，否则慎用！

节点Peer、通道Channel 和链码Chaincode 之间的关系

节点Peer 是一个独立存在的计算机节点，不管是物理机还是虚拟机，总之是独立实体。在Peer 没有加入任何通道之前，是不能够做任何业务的，因为没有业务载体。

通道Channel 就是业务载体，是纯粹的逻辑概念。

链码Chaincode 就是业务，业务是跑在通道里的，不同的通道即便是运行相同的链码，因为载体不同，可认为是两个不同业务。

三者需要互相配合才能构成一个完整的Hyperledger Fabric 区块链。

简单例子：每个人的手机就是一个Peer，手机的APP应用就好比Chaincode，打开APP应用连接到APP 应用的伺服器就好比建立了一条通道。

代币Token

在公有链上，存在激励机制，通过奖励为交易打包（挖矿）的"矿工"达成共识机制，给予奖励代币，维持区块链网络的正常运作。

在 Hyperledger Fabric 这种联盟链上，由于都是信任的节点，并不一定要透过挖矿这种方式达成共识，因此也未必需要代币Token。如一定要使用代币，可以透过链码Chaincode 进行实现。