Fabric数据访问层

当需要在Fabric中对系统进行管理操作或者调用Chaincode的时候通常可以使用两种方法:CLI命令行工具和Fabric SDK调用。CLI命令行工具需要获取Peer节点所在主机的操作系统的账号,然后登录操作系统之后使用,这种方式通常被系统管理员采用。如果需要在业务系统中通过代码的方式同Fabric进行交互,只能通过Fabric提供的相关语言的SDK编写相应的代码和Fabric进行交换。在设计这些访问代码的时候通常会采取两种方式:嵌入式和中间件式。这两种代码的设计方式如图9-4所示:

blob.png

在图9-4所示的两种方法中,我们建议采用方式b。在Fabric系统中设计一个独立的中间层封装对应Fabric常用操作,将这些操作采用通用接口的方式提供给业务系统调用。我们认为这种设计方式有以下好处:

1、解决Fabric记录状态返回不实时的问题

Fabric是基于区块链的分布式总账系统,所有的数据存放于区块链中。区块链的区块生成是需要时间的,目前Fabric的Orderer模块专门负责将交易打包成区块。区块的生成按照时间或者交易的数量进行打包,比如可以设置每一分钟打包一个区块或者每个1000条记录打包一个区块。无论采用哪种方式,区块链的生成都是需要一定时间的。因此Fabric系统中是无法立即响应数据操作状态,如果提交一笔交易之后则需要一段时间才能获取该交易的操作结果。如果采用将Fabric相关的操作集成在一个中间件中,遇到类似场景的时候可以数据处理完成之后,通过中间件将处理结果推送给业务系统进行后续处理。这样可以有效解决业务系统的等待问题,同时还可以降低业务系统的开发难度。

2、有利于系统进行负载均衡

Fabric并不是一个可以承载大并发读写的数据系统,当系统请求的并发比较多的时候Fabric会产生阻塞,遇到这种情况通常可以采用增加Peer节点的方式来减轻单个节点的负载。

举个例子,在Fabric系统中某个Channel1中存在一个数据访问节点Peer1,该节点专门负责接收外部系统的访问请求。随着系统运行外部系统的请求数量会逐步增加,这个时候Peer1节点可能无法满足需求因此需要增加一个新的节点分担Peer1节点的负载,我们将新增加的节点称为Peer2。增加的Peer2节点加入Channel1之后,系统会自动将Channel1中的数据部署到Peer2中。然后在Peer2中部署和Peer1中同样的Chaincode,这样Peer2就可以提供和Peer1一样的功能。通过这样的方式,Fabric系统能够简单的对系统进行横向扩展。但是这种特性对业务系统访问Fabric的方式提出了相关的要求。假设在业务系统中编写访问Fabric的代码,这时如果Fabric增加了一个新的访问节,业务系统可能需要进行重启、打包等维护工作。这样可能会降低业务系统的稳定性。如果将对Fabric的操作封装在一个独立的中间件中,可以在不影响业务系统的情况下直接更新中间件系统即可完成相关的升级工作。除此之外,通过独立的中间件系统访问Fabric还有一个好处,就是可以在中间件中集成相关的负载均衡算法,根据相关Peer节点的性能来决定接受的请求数量。

3、隔离客户端系统采用的开发语言

Fabric提供了基于Grpc的接口描述文件,理论上任何语言只要能够支持Grpc协议都能够很好地和Fabric进行通信。但是从头开始实现Fabric的Grpc协议的工作量非常大,而且要进行很多测试工作。目前Hyperledger项目已经实现了Nodejs、Go、Java、Python这个四个语言的SDK,应用这四种语言开发的系统可以非常容易的和Fabric进行通信。但是常用的编程语言远不止这些,开发业务系统的编程也不会局限于这四种语言。比如,业务系统采用的开发语言是PHP,这就需要从头开始用PHP根据Fabric提供的Grpc的描述文件生成相关的代码,这个过程比较繁琐而且容易出错。这时候如果采用Nodejs、Go、Java、Python这四种语言中的一种开发一个通用的中间件,然后通过一些常用的协议(比如JSON-RPC)暴露接口,这样能够屏蔽由于业务系统的编程语言多样性带来的问题。

868区块链学习网为您整理《Fabric数据访问层》仅供参考。