Fabric项目开发实例详解

Fabric的编译、配置、账号管理、Chaincode等部分的内容在前面已经介绍过,本节实例是在前面这些内容的基础上进行的,希望读者在充分理解前面章节的基础上阅读本章。在本次示例开始前,我们会根据相关项目的流程给出一个流程图来说明Fabric项目的实施过程。在流程的每一个节点中,我们会列出本节点采用的工具、配置文件,输出文件,以及需要在后面引起注意的域名和文件目录。

一、系统初始化

Fabric在开始之前,我们建议首先根据项目的需求,把整个项目中可能会涉及的参与方(组织)和参与方大概的规模(节点和用户账号数)罗列出来。10.1节的内容就是一个简单的项目分析结果清单。我们建议读者在Fabric项目开始之前可以参考10.1节中的图例,将相关的组织和组织的规模画出来先分析一下,然后也列出类似的表格,最后根据这些表格的内容开始编写配置文件。在项目演示开始之前,我们首先创建一个文件夹,这个文件夹用来存放所有的配置文件以及后面的演示过程中生成的相关文件。本例中的文件夹如下所示:

blob.png

目录创建完成后,以10.1节表格为参考开始编写cryptogen模块需要使用的配置文件。配置文件内容如下所示:

blob.png

将上述内容保存到名为crypto-config.yaml的配置文件中,然后将该配置文件保存到文件夹/var/qklszzn中,最后调用cryptogen模块生成相关的配置文件,生成配置的命令如下:

blob.png

cryptogen模块执行成功之后,生成的配置文件会保存到当前目录下面的crypto-config文件夹中。crypto-config中的内容如下所示:

blob.png

blob.png

二、Orderer节点的初始化和启动

Orderer模块启动之前需要生成一个创始块文件和Orderer模块所需的配置文件。创始块是Fabric的第一个区块,主要存储相关的配置信息。

1、Fabric创始块的生成

创始块的创建需要通过configtxgen模块来生成,configtxgen模块需要一个配置文件来描述创始块的配置信息。本例中的配置文件的文件名为configtx.yaml,文件内容如下所示:

blob.png

blob.png

blob.png

blob.png

注意 上述配置文件中请注意Kafka服务器的部署地址。

configtx.yaml文件中的Profiles节点的子节点TestOrgsOrdererGenesis为系统创始块的相关配置信息。通过configtxgen模块可以生成创始块的初始化文件。生成的命令如下所示:

blob.png

-profile TestOrgsOrdererGenesis就是在configtx.yaml配置文件Profiles节点的子节点名称。

configtxgen命令执行完成之后会在根目录下面生成创始块文件orderer.genesis.block。

系统的创始块生成之后,可以创建Orderer模块的配置文件来启动Orderer模块,Orderer模块的配置文件名为orderer.yaml。由于配置文件的内容太多,这里以Fabric源代码中示例配置文件为基础进行修改。示例文件夹的路径为:

https://github.com/hyperledger/fabric/blob/release/sampleconfig/orderer.yaml

首先创建一个文件夹用来存放Orderer模块相关的配置文件和数据文件。创建文件夹的命令如下:

blob.png

需要修改的内容如下所示:

blob.png

blob.png

将修改好的Orderer配置文件orderer.yaml保存到文件夹/var/qklszzn/order中,现在可以启动Orderer模块了。Orderer模块的启动方式有两种,分别是直接启动和通过Docker容器的方式进行启动,本章所有内容一律采用直接启动的方式。在orderer.yaml文件所在的目录中执行以下命令启动Orderer模块。

注意 在启动之前有一点非常重要,在配置文件中我们用域名替代了IP地址,本例中的域名是测试域名,需要在服务器中进行域名的映射才能访问。在编写本书的时候,本例运行服务器的地址为192.168.23.212,操作系统为Ubuntu。采用的域名映射命令如下:

blob.png

在打开文件中输入以下内容:

blob.png

保存内容

Orderer模块的启动命令如下:

blob.png

如果想让Orderer模块常驻后台运行,采用以下命令:

blob.png

2、对后续操作产生影响的地址和配置文件

在configtxgen模块的配置文件configtx.yaml中有一些配置信息非常重要。现列举如下:

(1)Orderer相关的配置信息

Orderer相关的配置信息内容如下:

blob.png

需要注意的有这样节点:

·ID属性:ID属性的值表示该Orderer节点的名字,在后面的Orderer模块的配置文件orderer.yaml中,属性LocalMSPID的值必须同此处的值一致,否则系统会提示错误。

·MSPDir属性:MSPDir属性表示当前Orderer节点的账号文件的路径(关于Fabric的账号情况参考本书的第6章),必须指向由cryptogen工具生成的相关目录。注意:如果采用集群的方式在其他机器上布置Orderer节点,那么其他机器上的Orderer节点中配置文件的MSP文件夹的路径和MSPDir属性的的值必须和这里配置是一致的,否则Orderer无法启动。

(2)组织相关配置信息

本例中有三个组织bc_org1、bc_org2、bc_org3。他们的配置信息都是一样的。我们以组织bc_org1的配置为例来说明configtx.yaml配置文件中组织相关配置信息在后续操作中的重要作用。

blob.png

blob.png

上述配置信息有以下需要注意的地方:

·ID属性:ID属性的值是当前组织在整个系统中唯一的标识符,在后面的很多操作中都需要用到该值。注意:任何两个组织的ID属性都不能相同,否则系统无法运行。

·MSPDir属性:MSPDir属性的值存放的是当前组织的账号(关于Fabric的账号情况参考本书第6章的内容)。组织中的任何节点,不管运行在哪个服务器上,都必须保证把账号文件存储在和MSPDir属性的值设置的路径。在多机部署,特别是非Docker部署的时候,这一点尤其重要。在作者运营的区块链技术论坛中,很多问题都和这个路径有关系。读者在使用Fabric的过程中,如果遇到错误,首先请检查路径是否正确。

·AnchorPeers属性:AnchorPeers属性主要是配置了锚节点的信息。锚节点是一个Peer服务器节点,该节点专门负责组织和其他组织的信息交互。锚节点非常重要,如果锚节点配置错误,那么组织将无法被其他组织感知到。在加入一个组织的时候需要验证新组织的锚节点的服务器地址可以被访问到。同时新组织也需要验证已有组织的锚节点是否可以被正确访问。

三、启动第一个Peer

1、设置Peer模块的配置文件Peer模块的配置文件的内容比较多,我们选择在Fabric源码中提供的模板文件进行修改。模板文件的路径如下:

https://github.com/hyperledger/fabric/blob/release/sampleconfig/core.yaml

由于core.yaml中的配置信息太多,这里只列出需要修改的部分。在修改配置文件之前,首先创建一个文件夹用来存放Peer模块的配置文件和数据文件。创建文件夹的命令如下所示:

blob.png

Peer模块配置文件需要修改的部分如下:

blob.png

blob.png

将修改好的Peer模块配置文件core.yaml保存到文件夹/var/qklszzn/peer中。现在可以启动Peer模块了。Peer模块的启动方式有两种,分别是直接启动和通过Docker容器的方式进行启动,本章所有内容一律采用直接启动的方式。在core.yaml文件所在的目录中执行以下命令启动Orderer模块。

blob.png

如果想让Peer模块常驻后台运行,采用以下命令:

blob.png

2、对后续操作产生影响的地址和配置信息

Peer模块的配置文件core.yaml有一些属性比较重要,如果处理不当可能会引起错误。具体需要关注以下配置属性。

·bootstrap:bootstrap表示组织内部的一个Peer服务器节点的地址,当Peer模块启动之后首先需要向该节点服务器发送请求同步本组织的相关信息。如果是第一个Peer节点可以填写本机的地址,如果组织中已经存在Peer节点,那么可以添加任何一个已经存在的Peer节点的地址。

·listenAddress:本机监听的地址。

·fileSystemPath:Peer节点本地数据文件的存储路径。

·mspConfigPath:Peer节点账号文件的目录路径。这些文件是通过cryptogen模块生成的。

·localMspId:Peer节点所属组织的编号,该编号在cryptogen模块的配置文件中设定,设定后一般不需要修改。

四、Channel的创建和加入

Peer节点启动后还不能进行任何工作,首先需要创建Channel,创建成功之后需要将当前的Peer加入到新创建的Channel中。创建Channel需要使用configtxgen模块,并在其配置文件中配置Channel的信息。在10.2.2节中已经配置好了相关Channel的配置信息,我们截取其中的一段来说明配置信息中包含哪些要素,如果读者想了解详细的配置信息,可参考10.2.2节中的配置文件

下面是一个名为TestOrgsChannel的Channel的配置信息。

blob.png

blob.png

该Channel中包含三个组织,bc_org1、bc_org2、bc_org3。通道生成之后只有这三个组织的内Peer节点才能够加入到Channel中或者访问Channel中的交易信息。通过下面的步骤可以生成Channel的创始块文件,并将已经启动的Peer加入到新创建的Channel中。

第一步:创建Channel提案文件

创建Channel提案文件的命令如下所示:

blob.png

上述命令执行完成后,在当前目录中会生成名为fabricchannel.tx的文件。在生成Channel的命令中有一些参数是需要注意的,譬如:

·-profile。-profile参数设置的值必须和10.2.2节中定义的配置文件configtx.yaml中的Profiles节点中定义的子节点完全一致,否则命令会出错。

第二步:创建锚节点通知提案

锚节点通知提案负责将Channel创建的消息通知告诉锚节点,锚节点负责通知其他组织Channel创建的消息。创建锚节点通知提案的命令如下所示:

blob.png

上述命令执行完成之后在当前目录生成名为Org1MSPanchors.tx的文件。

第三步:创建Channel创始块

创建Channel创始块命令如下所示:

blob.png

·CORE_PEER_LOCALMSPID。环境变量CORE_PEER_LOCALMSPID表示创建Channel的组织的编号。

·CORE_PEER_MSPCONFIGPATH。环境变量CORE_PEER_MSPCONFIGPATH表示执行创建Channle的用户账号。上述命令执行成功之后会在当前文件夹中生成名为fabricchannel.block的文件。

第四步:加入Channel

现在可以将前面启动的Peer节点加入到Channel中。加入Channel的命令如下所示:

blob.png

第五步:通知锚节点

通知锚节点的命令如下所示:

blob.png

通过上面5个步骤,可以把10.2.3节中启动的Peer节点加入到名为fabricchannel的Channel中

对后续操作产生影响的配置信息如下:

在创建并加入Channel的过程中会产生三个文件:fabricchannel.tx、fabricchannel.block、Org1MSPanchors.tx。三个文件中fabricchannel.block是通道的创始块文件,其余的Peer节点如果想要加入名为fabricchannel的Channel,必须首先获取fabricchannel的block文件。在第一步(创建Channel创始块)中,创建Channel创始块的命令中有个选项-channelID,该选项后面的值为Channel的名字,一旦创建无法更改。本章后续内容中所有需要使用Channel名称的地方,一律使用fabricchannel。

五、启动当前组织的Fabric-ca

在项目初始化的过程中,采用了cryptogen模块生成了相关的账号,这种方式无法满足动态添加用户账号信息的场景,因此需要将Fabric-ca-server绑定到当前组织中。Fabric-ca-server的安装请参考6.3.1节的相关内容。在Fabric-ca-server的配置文件fabric-ca-server-config.yaml中设置以下信息完成绑定过程。

blob.png

六、测试Chaincode的部署和开发

我们以Fabric源代码中的示例Chaincode为例,部署测试Chaincode。首先需要设置相关环境变量,设置相关环境变量的命令如下所示:

blob.png

(1)安装Chaincode

blob.png

(2)实例化Chaincode

blob.png

(3)调用Chaincode的invoke方法

blob.png

(4)调用Chaincode的query方法

blob.png

上述命令都能正确执行的话说明前面的设置都是正确的。本例中Chaincode采用的Fabric是源码自带的示例Chaincode,如果想要自己编写示例Chaincode,请参考第7章

七、客户端的开发

Chaincode编写完成之后可以在客户端通过命令调用,在实际项目中这显然是不够的,需要通过Fabric提供的Grpc接口在客户端程序中调用Fabric。第8章中详细介绍了如何通过Fabric的SDK调用Fabric,这里不再复述。这里我们给出用Nodejs调用本例中Chaincode的示例。本书在编写测试用例的时候将Fabric和Fabric-ca-server部署的服务器为192.168.23.212,下面的示例代码中将会采用该服务器的地址。读者如果想自己测试,请将相关的IP地址修改成自己测试服务器的地址或者域名。Node.js调用本例中Chaincode的示例代码如下所示:

blob.png

blob.png

blob.png

blob.png

八、启动本组织的其他Peer

在前面的操作中我们已经启动了Orderer节点,然后启动了组织BcOrg1MSP的一个节点。现在需要启动组织BcOrg1MSP的第二个节点,并且将这个节点加入到之前创建的名为fabricchannel的Channel中。为了达到更好的演示效果,我们建议在另外独立的服务器上面启动组织BcOrg1MSP的第二个Peer节点。

1、启动Peer节点

在第二台服务器上我们需要创建和一个第一台服务器同样的路径,并且将相关的配置文件复制到同等目录中。创建目录的命令如下所示:

blob.png

将10.2.1节中创建的证书文件部分复制到目录/var/qklszzn/crypto-config中,成功复制后可以通过以下命令的结果核对复制是否正确:

blob.png

上诉命令成执行后,我们可以发现相关证书文件的数量和第一个Peer节点的服务器不一样。因为在运行组织BcOrg1MSP的第二个Peer节点的服务器上,我们需要运行一个Peer节点,而不需要运行Orderer,所以我们只将需要的证书复制过来。这里我们使用了peer1.org1.qklszzn.com的账号来生成组织BcOrg1MSP的第二个Peer节点。第二个Peer节点的配置文件还是以Fabric源码中提供的Peer模块的配置文件模板为基础进行修改。由于本书篇幅的限制,这里我们仅列出修改过的内容,具体内容如下所示:

blob.png

blob.png

配置文件修改完成后便可以启动组织BcOrg1MSP的第二个Peer节点。启动命令如下所示:

blob.png

如果想让Peer模块常驻后台运行,采用以下命令:

blob.png

2.将Peer节点加入到Channel中

组织BcOrg1MSP的第二个Peer节点成功启动后,需要加入到名为fabricchannel的Channel中以便获取账本信息。在加入之前首先需要获取通道的创始块文件,获取创始块的方式有两种:

(1)直接使用现存通道的创始块文件在10.2.4节的第三步正确执行完成后会生成一个名为fabricchannel.block,将该文件直接复制过来即可。

(2)通过命令行工具导出

如果之前生成的创始块丢失了,可以通过命令工具从现有通道中导出创始块文件,导出Channel创始块的命令如下所示:

blob.png

上述命令中需要在已经加入Channel的Peer节点的环境中运行。Channel的创始块创建完成之后执下面的命令:

blob.png

上述命令成功执行后,组织BcOrg1MSP的第二个Peer节点已经成功加入了名为fabric-channel的Channel中。

九、其他组织Peer节点的加入

在前面的操作中,我们已经成功启动了组织BcOrg1MSP的两个Peer节点,现在我们要启动组织BcOrg2MSP的Peer节点了。启动顺序和10.2.8节是一样的,需要注意的是组织BcOrg2MSP的Peer节点所使用的证书的路径。具体的步骤如下:

1、启动组织BcOrg2MSP的peer节点组织BcOrg1MSP的第二个Peer节点的配置文件:

blob.png

将10.2.1节中创建的证书文件部分复制到目录/var/qklszzn/crypto-config中,具体复制的文件可以参考以下命令的执行结果:

blob.png

注意 上述命令使用了目录org2.qklszzn.com下面的证书文件。

账号证书文件准备好之后,开始复制设置Peer节点的配置文件core.yaml。我们还是和10.2.3节介绍的一样,在Fabric源码中提供的样例配置文件的基础上进行修改,需要修改的内容如下:

blob.png

blob.png

执行以下命令启动Peer节点:

blob.png

如果想让Peer模块常驻后台运行,采用以下命令:

blob.png

本例中peer0.org2.qklszzn.com节点的部署地址的IP为192.168.23.213,在后面SDK部分需要用到这个IP地址,读者如果需要演示本示例请根据自己的实际环境予以调整。

2.将组织BcOrg2MSP的Peer节点加入到Channel中

直接使用现存通道的创始块文件

复制10.2.4节的第三步正确执行完成之后生成的创始块文件fabricchannel.block,将该文件复制到当前服务器中。Channel的创始块创建完成后执行下面的命令:

blob.png

blob.png

上述命令成功执行后,组织BcOrg1MSP的第二个Peer节点已经成功加入了名为fabric-channel的Channel中。在上述代码的执行中如果出现错误,请做以下检查:

·本地域名映射检查:由于还要和组织BcOrg1MSP的锚节点通信,请检查是否已经在本机和组织BcOrg1MSP的锚节点做了映射。具体可以检查本机的/etc/hosts文件。以下是本例的参考:

blob.png

·检查组织的配置文件:检查本地组织BcOrg2MSP组织的配置文件是否和11.2.1节中cryptogen模块的配置文件的配置路径完全一致。

十、背书交易的测试

到目前为止系统中已经有两个组织了,这时需要测试如何通过客户端发起一笔需要两个组织共同完成背书的交易了。首先需用重新部署一个Chaincode,这个Chaincode的交易验证规则和以前的不一样,需要经过组织BcOrg1MSP和组织BcOrg2MSP同时验证后才能生效。部署过程如下:

在组织BcOrg1MSP的peer0.org1.qklszzn.com上面部署Chaincode:

blob.png

blob.png

在组织BcOrg2MSP的peer0.org2.qklszzn.com上面部署Chaincode:

blob.png

blob.png

客户端代码示例如下:

blob.png

blob.png

blob.png

blob.png

十一、非初始化组织的加入

在Fabric项目运行的过程中,有时候需要加入新的组织,这时候需要对相关通道的创始块文件进行修改。本例中我们将演示如何在通道中加入非初始化组织。

第一步:生成新增加组织的配置文件

将以下内容保存到名为crypto-org4.yaml的配置文件中。

blob.png

执行以下命令生成新增组织的配置文件:

blob.png

第二步:启动configtxlator

blob.png

第三步:根据已经导出的创始块文件,构造新的结构文件

导出需要修改的通道的新文件:

blob.png

将导出的创始块文件转化成易于读写的JSON格式

blob.png

第四步:提取需要比较的地方

blob.png

第五步:构造增加组织的数据结构

blob.png

blob.png

blob.png

blob.png

blob.png

上述模板文件还有3个属性需要绑定响应的证书文件,分别是:

(1)admins

admins属性中的内容对应的是组织BcOrg4MSP的msp文件中admincerts的文件内容,将文件夹中的内容改为Base64格式的编码后,复制到文件中。本例中对应文件的路径为/var/qklszzn/crypto-config/peerOrganizations/org4.qklszzn.com/msp/admincerts。

(2)root_certs

admins属性中的内容对应的是组织BcOrg4MSP的msp文件中cacerts的文件内容,将文件夹中的内容改为Base64格式的编码后,复制到文件中。本例中对应文件的路径为/var/qklszzn/crypto-config/peerOrganizations/org4.qklszzn.com/msp/cacerts。

(3)tls_root_certs

admins属性中的内容对应的是组织BcOrg4MSP的msp文件中tlscacerts的文件内容,将文件夹中的内容改为Base64格式的编码后,复制到文件中。本例中对应文件的路径为/var/qklszzn/crypto-config/peerOrganizations/org4.qklszzn.com/msp/tlscacerts。

注意 上面3个属性的值必须将对应文件采用base64格式编码之后才能保存到文件中。

第六步:构建原来包含3个org的数据结构

blob.png

第七步:构建新组织BcBcOrg4MSP的数据结构

blob.png

第八步:计算两个数据结构的差异

blob.png

blob.png

第九步:解析差异化数据结构为Json格式

blob.png

第十步:构造更新消息的数据结构

blob.png

第十一步:构造更新数据结构

blob.png

第十二步:当前通道的所有组织对交易数据结构进行签名

新组织的加入必须征得其他组织的同意,因此需要更新数据进行签名,才能提交更新请求。本例中需要修改的Channel中已经有了BcOrg1MSP、BcOrg2MSP、BcOrg3MSP三个组织,由于我们将采用BcOrg1MSP的账号提交证书,因此本例只需要BcOrg2MSP、BcOrg3-MSP这两个组织的签名。

组织BcOrg2MSP的签名命令:

blob.png

组织BcOrg3MSP的签名命令:

blob.png

第十三步:执行更新交易

利用组织BcOrg1MSP的账号发起更新Channel的请求:

blob.png

第十四步:检查修改是否成功

导出名为fabricchannel的Channel配置块:

blob.png

将创始块的内容转换成JSON的格式:

blob.png

打开文件fabricchanneladdorg4.json,检查里面的内容是否包含新添加的组织。如果发现组织BcOrg4MSP相关的信息,则证明组织添加已经成功了。添加成功后的组织BcOrg4MSP便可以加入已经存在的系统中。

868区块链学习网为您整理《Fabric项目开发实例详解》仅供参考。