hyperledger

Hyperledger Cello是超级账本项目下面的一个子项目，提供按需部署的功能，可以将区块链部署在各种裸机、虚拟机、容器等环境中。该项目最初由IBM发起，目前得到了Soramitsu, 华为，和Intel的赞助。 该项目目前还在孵化中，未来可能还存在较大变化，本篇内容我们将对这个工具进行快速概览。 1 Cello的功能简介 Cello可以容易的帮助用户实现: 从头开始快速构建一个区块链即平台(BaaS)的服务 支持可定制的区块链,如 Hyperledger fabric network v1.0. 可以在裸机、虚拟云端(如虚拟机，vsphere Clouds等)，或容器集群(如Docker, Swarm, Kubernates等)中管理一个区块链网络资源 从dashboard中就可以完成检查系统状态，调整区块链数量，扩展资源等功能 典型的应用场景如下: 2 安装部署 整个Cello的架构图如下所示: Cello采取了一主多从的部署模式，Cello Service部署在Master节点上，提供宿主资源的裸机或虚拟环境称为Host，被Cello管理的区块链服务单元称为Worker。整套环境部署要求至少一个Master与一个Worker。 Master安装部署 Master节点提供Cello Service的宿主环境，通常提供web管理界面

Hyperledger Fabric日益增强的潜力使得许多企业正在尝试使用fabric。当使用涉及更多peers和orderers的大型网络时，维护超级账本数据的备份非常重要。如果网络出现故障，这将有所帮助。它还有助于开发阶段，因为可以使用备份数据来执行将来的测试。 在本文中，我将介绍如何进行备份以及如何在Hyperledger Fabric中使用备份。 超级账本分类帐数据在容器中的位置 通常，peer中的分类帐数据存储在 /var/hyperledger/production/location 中。在orderer中，它位于 /var/hyperledger/production/orderer 中。我们需要备份这些文件夹。 采取备份的步骤 第1步： 要进行备份，必须创建空间来存储数据。当网络在Docker容器内运行时，我们将使用卷来实现这一点。我将使用一个基本网络与一个peer，一个orderer，一个ca和一个CouchDB。由于我们有一个peer和一个orderer，我们需要创建两个卷，比如 backup_orderer 和 backup_peer 。我们需要在 docker-compose.yml 文件中将这些指定为卷，如下所示。 networks: basic: volumes: backup_peer: backup_orderer: 这将在启动网络时创建两个卷。

使用CouchDB作为状态数据库 状态数据库选项 状态数据库包括LevelDB和CouchDB。LevelDB是嵌入在peer进程中的默认键/值状态数据库， CouchDB是一个可选的外部状态数据库。 与LevelDB键/值存储一样，CouchDB可以存储任何以chaincode建模的二进制数据（CouchDB附件函数在内部用于非json二进制数据）。但是，当chaincode值（例如，资产）被建模为JSON数据时，作为JSON文档存储，CouchDB支持对chaincode数据进行丰富的查询。 LevelDB和CouchDB都支持核心chaincode操作，例如获取和设置一个键（资产），并根据键进行查询。 键可以通过范围查询，可以对组合键进行建模，以支持针对多个参数的等价查询。 例如，作为所有者的组合键，资产id可以用于查询某个实体拥有的所有资产。 这些基于key的查询可以用于针对账本的只读查询，以及更新总账的事务。 如果将资产建模为JSON并使用CouchDB，那么就可以使用chaincode中的CouchDB JSON查询语言对chaincode数据值执行复杂的富查询，这些类型的查询对于理解账本上的内容很有帮助。对于这些类型的查询，事务协议响应通常对客户端应用程序有用，但通常不会作为事务提交到排序服务。事实上

　　之前介绍了使用官方脚本自动化启动一个Fabric网络，并且所有的证书都是通过官方的命令行工具cryptogen直接生成网络中的所有节点的证书。在开发环境可以这么简单进行，但是生成环境下还是需要我们自定义对网络中的节点的证书进行配置。 　　 　　所以在本文中，将会详细介绍一个从手动生成证书一直到启动网络的整体步骤。本文只交代整体的搭建步骤。对于Fabric-Ca的讲解不在本文的范围内，将在另一篇文章中说明。 　　 　　正篇文章也是根据官方的文档进行的。但是由于官方的文档尚未完工，也是好多没有交代清楚的，并且有些地方是错误的，所以笔者也是一步一步摸索出来的，所以如果本文哪里没有交代清楚或者错误的地方，希望各位批评指正。 　　 　　在这里贴出官方文档地址. 　　 　　1.整体架构 　　 　　架构图直接贴过来好了： 　　 　　系统架构 　　 　　官方文档采用的是多机环境，这里简洁化一点，所有的操作都在一台机器上进行，至于多机环境，以后再补充好了。 　　 　　介绍一下本文所采用的整体架构： 　　 　　三个组织 　　 　　Org0 -> 组织0 　　 　　Org1 -> 组织1 　　 　　Org2 -> 组织2 　　 　　组织中的成员 　　 　　Org0 一个Orderer节点，一个Org0的Admin节点 　　 　　Org1 两个Peer节点，一个Org1的Admin节点