随着微服务架构技术的发展, 为了避免重复开发, 提升开发效率, 各大企业在开发功能模块时, 通过搭建微服务平台将企业的各功能模块微服务化, 每个服务都具有自己独立的生命周期和服务边界, 可以独立部署、独立维护、独立扩展, 服务与服务之间通过统一的API进行相互通信, 实现功能模块的快速部署和调用. 然而, 在微服务完成部署应用一段时间后, 随着对业务需求的不断变更, 该微服务对业务的支撑价值逐渐变小, 为了促使开发人员对低应用价值的微服务进行优化和升级, 定期对微服务进行公开、公正的评价. 当前, 针对这些微服务管理是根据微服务的调用频率及最后一次调用时间, 判断该微服务的应用价值, 缺乏一定的公正性, 且数据容易被篡改. 为了对每个微服务进行公开透明的评价, 本文基于区块链的技术定期对微服务发起评价, 并授权多个节点对微服务进行多维度打分评价, 保障微服务各维度的评分结果不可篡改、可追溯; 然后, 基于微服务各维度不可篡改的评价分数, 结合层次分析法和熵权法构建微服务的评价模型, 计算微服务的综合得分, 最终实现微服务的智能化管理.

区块链的去中心化、可追溯、防篡改等特性已受到了各行各业的关注, 其核心技术主要由加密算法、共识算法、智能合约、P2P网络等组成. 其中, 共识机制算法主要有以下几种: 工作量证明(Proof of work, PoW)^[1,2], 权益证明(Proof of Stake, PoS)^[3]和拜占庭容错(PBFT)^[4–6]等. 区块链是由整个网络节点进行记账, 而并非某一个中心机构, 确保了多个参与方之间在数据层面不可篡改, 且能够追溯历史数据^[7], 基于区块链技术可构建多方参与去信任化的交易系统^[8]. “中本聪”于2008年首次发表了关于比特币的文章^[9], 首个区块链货币加密系统——比特币(Bitcoin)也在次年发布, 实现了网络上互不信任的个体可以在无中介的情况下使用比特币进行货币交易. 2014年, 以太坊(Ethereum)^[10]在比特币的基础上首次将智能合约应用到区块链. 在对区块链技术的不断完善过程中, 其适用的范围也在扩大, 为了适用于商业应用场景, 出现了去中心化程度较低的联盟链和私有链. 2017年, Linux基金会发起了开源的区块链项目超级账本(Hyperledger)^[11], 其主要有5个子项目: Fabric、Sawtooth、Indy、Burrow和Iroha. 其中, 最受关注的是Fabric^[12]联盟链, 不同与比特币和以太坊, Hyperledger Fabric是专门针对于企业级的区块链应用而设计的联盟链平台, 成员节点必须经过授权才可以加入^[13]. 区块链作为数字货币的底层技术支持, 保障了数字货币的隐私和匿名性^[14]. 当今, 各企业对区块链研究现状呈现指数型的增长, 在共识机制、数据管理、信息安全等方面的应用都有较多的研究^[15-18], 但在评价系统中的应用研究较少.

本文利用Hyperledger Fabric区块链技术, 授权参与微服务评分用户节点对指定的微服务的维度进行打分, 系统利用Hyperledger Fabric的智能合约对用户节点的打分进行记账, 这样保障了微服务的评价数据不可篡改, 且后期可进行追溯, 在得到微服务各维度的评分后, 利用综合评价的方法计算微服务的综合得分. 综合评价常用的方法有层次分析法(AHP)、熵值法^[19]、和逼近理想解排序(TOPSIS)^[20]等. 然而, 层次分析法需要先对采用1–9标度法和判断矩阵中每一层次各个因素之间的相对重要性数值, 具有一定的主观性; 与层次分析法相比, 熵权法具有较高客观性, 其主要依据评价数据计算权重, 但其对每一次跟新的评价数据重新计算权值, 造成每次计算得到的权数会发生变化^[21]. 本文提出一种基于AHP与熵值法结合的评价方法构建微服务综合评价模型, 大大提高了评价结果的合理性, 最后, 通过微服务的评价数据, 验证了本文中评价方法的有效性. 为微服务的智能优化管理提供了有效的数据支撑.

1 Hyperledger Fabric区块链

2015年12月, Linux基金会和30家初期公司成立了Hyperledger项目, 以推广跨行业区块链技术, 并为透明、开放的企业级分布式账本技术提供了开源代码实现. Hyperledger Fabric结构采用模块化的架构设计, 并引入了权限管理, 因而具有高度的可扩展性和灵活性. 从应用的角度看, Hyperledger Fabric结构可分为身份管理、账本管理、交易管理和智能合约4个部分; 从自下而上的角度看, Hyperledger Fabric结构分为成员管理、共识服务、链码服务3个部分. 安全性问题是企业级区块链关心的问题, 需要底层加密技术的支持, Fabric专门定义了一个BCCSP (BlockChain Crypto-graphic Service Provider), 使其实现密钥生成、哈希运算、加密解密等基础功能. Hyperledger Fabric的逻辑架构如图1所示.

Hyperledger Fabric作为一种联盟链，其主要由对等节点(Peer node)、链码(Chaincode, 即智能合约)、成员服务提供者(Membership Service Provider, MSP)、通道(Channel)、排序服务(Ordering Service)、客户端(Client)等组成.

Peer node主要分为两类: 背书节点(Endorser)和确认节点(Committer). 其中, Endorser主要对客户端发出的请求按照已制定的策略进行模拟交易和签名背书, 然后返回给客户端. Committer主要对交易的请求进行核查, 并向区块写入交易, 更新账本. 一般只有部分Peer node具有确认功能.

Chaincode: Hyperledger Fabric提供了用于系统维护的系统链码和通过执行可编程的代码逻辑与账本交互的用户链码两种.

MSP: 其作为Hyperledger Fabric网络的一个重要组件, 定义了相关的颁发和校验数字证书的标准化规范, 对区块链网络中各组织和成员的权限进行管控,负责成员的身份管理和认证. 在初始化MSP的一个实例, 需要在每一个peer node、Ordering Service指定其配置, 包含被授权组织的MSP相关信息, 并在Channel上启用Peer node、Ordering Service身份验证和数字签名验证.

Channel: 其主要功能是对区块链网络上的交易进行隔离, 即使对于同一个Peer node, 在提交到不同通道的交易中的访问策略、组织身份及排序服务也是相互独立的, 这样, 不同通道内的交易可并行进行, 提升了平台的性能和扩展性, 同时, 通道的外部成员是无法访问和篡改通道内部的数据, 保障了通道内数据的安全性.

Ordering Service: 它是由1个或多个排序节点组成, 主要负责在某段时间内, 收集到由不同客户端提交的多个合法交易请求, 按提交交易请求的时间顺序进行排序, 然后组成区块数据广播至通道内的区块链网络.

Client: 其主要对区块链网络底层接口进行封装, 一般通过 SDK进行调用, 保障应用层各功能模块和区块链网络中各个组件之间的交互. 客户端能够实现在网络中发起交易、监听消息、更新配置、启动和停止节点等功能.

Hyperledger Fabric是由多个不同组织的成员、Peer node、Channel、Ordering Service、Client组成. 每个成员都有一个由MSP提供的唯一标识, 同一通道内的成员可看到所以组织的身份, 并可以对其进行验证.

2 基于Fabric的微服务评价系统实现 2.1 系统架构设计

为了满足对微服务进行公正、透明及可验证的评价需求, 本文利用区块链技术的去中心化、数据不可篡改、公开透明等特性, 将用户地址、微服务评价选项的地址、用户评价分数等信息写入区块链里, 基础数据(如用户基础信息、微服务基础信息等)存入本地数据库Oracle中. 同时, 本文基于用户对微服务各维度的评分和微服务维度间的重要程度, 将层次分析法(AHP)和熵值法相结合计算维度的权值构建微服务综合评价模型, 计算得到微服务的综合得分, 将其作为微服务下线的重要参考依据, 为微服务的智能化管理提供数据支撑. 微服务评价系统主要由应用层和数据层组成, 用户可通过编写SQL语句查询基础数据, 也可通过调用接口查询区块链数据. 本文基于区块链的微服务评价系统架构设计如图2.

本文基于区块链的微服务评价系统中的应用层采用的是B/S架构, 其中, Web应用主要呈现微服务评价系统的功能, 该系统分为普通用户和系统用户两个模块, 系统用户有用户评价授权管理、评价管理、新建微服务评价等模块; 其主要负责微服务的评价事务, 创建新的微服务投票项并进行维护, 同时对普通用户进行授权管理. 普通用户有参与评价、查看评价结果、验证评价结果等模块功能. 客户端负责了与Web服务器的交互, 通过调用接口实现Web服务器与区块链之间的数据流转, 将用户评价数据打包写入区块链上, 同时响应对评价结果数据的查询请求. 基于区块链的微服务评价的主要过程如下:

(1)系统用户发起某个微服务的评价, 系统生成该微服务评价的区块, 在发起评价后, 系统用户授权普通用户对该微服务进行评价.

(2)普通用户在通过系统授权后, 可对该微服务的各个维度进行打分, 评价完成后, 系统利用加密算法对用户的评价结果数据进行加密并生成密钥, 用户可根据密钥查看并验证评价结果, 验证完成后, 系统将验证记录等执行结果进行打包写入区块链中.

(3)综合评价模型通过调用区块链数据查询接口, 查询用户对微服务各维度的评价分数, 并计算微服务综合得分. 用户可在客户端进行信息查询和验证.

为了快速查询基础信息, 本文的数据层将区块链数据和基础数据分开存储. 其中, 本地Oracle数据库主要存储用户和微服务的基础信息; 区块链层则由网络层和存储层构成, 主要通过搭建P2P网络层构建分布式数据库, 在微服务评价数据打包发送至区块链网络中时, 实现数据在区块链中分布式存储, 保障数据去中心化存储, 同时, 该区块层利用数字签名等加密算法以实现数据的不可篡改, 通过共识算法保证区块链中数据的一致性, 同时, 根据时间戳将区块以首尾相连的链式结构进行保存.

2.2 基于Fabric的微服务评价流程

与其他采用订单执行交易模型的区块链网络不同, Fabric将交易处理流程解耦至不同类型的节点进行, 这在一定程度上降低了单个节点的负载, 提升了交易的效率. 图3描述了基于Fabric区块链技术, 某评价用户对单个微服务进行评价的具体流程, 其主要包括3个阶段: (1)背书阶段: 在选择的对等节点上模拟微服务各维度的评价结果并采集修改的状态; (2)排序阶段: 通过协商一致协议执行微服务各维度的评价; (3)验证阶段: 验证后提交到分类账本. 具体的微服务评价流程如下:

(1)评价用户注册/登录: 评价用户通过客户端利用SDK调用证书服务(CA)进行注册, 获取身份证书, 在注册成功之后就拥有了合法身份, 并凭借该身份加入联盟通道.

(2)发送微服务评价提案: 客户端在MSP获取身份证书加入通道后, 对微服务各维度进行打分, 在完成打分后提交评价结果, 系统将发送本次评价提案(Proposal), 把带有本次评价要调用的合约标识、合约方法、参数信息、客户端签名等信息发送给背书(Endorser)节点.

(3)背书和模拟用户评价: 背书节点收到用户评价提案后, 验证签名并确定提交者是否具有执行操作的权限, 同时根据背书策略模拟执行智能合约, 并将结果及其CA证书签名返回给客户端.

(4)发送微服务评价结果: 客户端收到背书节点返回的信息后, 判断提案结果是否一致, 并核查背书的合法性, 核查一致后, 把数据进行打包到组成一个交易并签名, 发送给排序服务(Orderers), 否则中止处理.

(5)微服务评价排序: 排序节点根据共识算法对接收到的微服务评价结果进行排序, 并按照接受到的评价结果时间将一批微服务的评价数据打包进对应通道的区块, 然后广播至通道内的确认节点;

(6)微服务评价结果验证和写入: 确认节点收到广播后, 会对区块中的每次评价结果进行校验, 检查微服务评价依赖的输入输出是否符合当前区块链的状态, 核查完成后将区块追加到本地的区块链, 并修改世界状态.

(7)微服务评价账本更新公告: 告知客户端该微服务评价结果是否成功更新.

2.3 结合AHP和熵值法的微服务综合评价方法

层次分析法 (Analytic Hierarchy Process, AHP) 是一种将定性和定量相结合的主观赋权方法, 其主要根据主观对各评价维度之间的重要度进行量化, 构造一个判断矩阵, 然后利用数学相关计算方法解决了求解多目标和多准则特性的决策问题. AHP主要适用于对结果无法通过主观判断直接计算的场景, 因此, 在主观综合评价的场景一般选择AHP评价方法. 然而, 基于AHP计算的评价结果, 其主观性较强, 有较为明显的缺陷, 在使用AHP构建综合评价单模型时, 评价者根据个人主观对各维度重要度的判断给出标度值, 这样构造的判断矩阵受个人影响较大, 并且最后计算各维度的权值也是固定不变. 在所有的评价者对利用AHP方法计算的一个评价维度进行评价的分值都很接近时, 会造成该维度的权值较高, 但区分度较低的情况, 这样最终的评价结果可信度不高. 熵值法作为一种与AHP不同的客观赋权法, 首先计算评价维度的信息熵, 评价维度计算得到的熵值就越小, 显示该评价维度的离散程度越大, 反应的信息量也就越多, 最终计算的权值就会越大, 反之则评价维度最终计算的就越小. 本文结合熵值法和AHP计算各评价维度的权值, 可将评价维度评价分值区别度不高的重要维度权值适当降低, 将评价值相差较大的维度的权重适当提高, 实现固定的主观赋权与动态的客观赋权相结合, 提升各评价维度权值的可信度.

为了对微服务进行合理的价值评估, 本文结合AHP和熵值法根据微服务的评价结果构建综合评价模型, 计算微服务评价的综合得分, 首先通过专家评判构建微服务6个评价维度的判断矩阵. 微服务评价维度主要包括: 功能可用性(A1)、服务稳定性(A2)、服务易用性(A3)、服务扩展性(A4)、执行效率(A5)、文档完整度(A6). 经专家全面分析每个微服务的地位和作用, 再填写咨询表并进行统计, 通过1~9 标度法构造判断矩阵, 如表1所示.

根据上表微服务各维度的判断矩阵, 利用AHP计算各维度的权值, 结果如下:

${W_{\rm AHP}} = (0.3804,0.2229,0.1289,0.1289,0.0695,0.0695)$

然后, 根据微服务各维度的评价结果, 利用熵值法的计算各维度的信息效用值, 具体计算过程如下:

(1)对微服务的评价结果数据进行标准化处理:

数据标准化公式为: ${x'_{ij}} = \dfrac{{{x_{ij}} - {x_{j\min }}}}{{{x_{j\max }} - {x_{j\min }}}}$ ; 其中, ${x_{ij}}$ 为第i个评价用户对微服务的第j个维度的评价值, ${x_{j\max }}$ 为第j个评价维度的最大值, ${x_{j\min }}$ 为第j个评价维度的最小值, ${x'_{ij}}$ 为标准化后的数据值.

(2) 计算第j个评价维度下第i个评价用户的评价维度值的比重 ${p_{ij}} = \dfrac{{{x_{ij}}}}{{\displaystyle\sum\limits_{i = 1}^n {{x_{ij}}} }}$ ;

(3) 计算第j个评价维度的熵值 ${e_j} = - k \displaystyle\sum\limits_{i = 1}^n {{p_{ij}}} \ln {p_{ij}}$ , 其中 $k = \dfrac{1}{{\ln n}}$ .

(4) 计算第j个评价维度的信息效用值 ${d_j} = 1 - {e_j}$ ;

最后, 结合AHP和熵值法分别计算的第j个评价维度的权重值 $w_j^A$ 和信息效用值 $d_j^E$ , 计算得到一个新的权重, 公式为: ${w'_j} = w_j^A*d_j^E$ . 再将 ${w'_j}$ 进行归一化处理, 得到最终的第j个评价维度组合赋权为:

${w'_j} = \dfrac{{{{w'}\!_j}}}{{\displaystyle\sum\limits_{j = 1}^m {{{w'}\!_j}} }}$

(1)

3 实验分析 3.1 系统环境配置

本文基于Fabric区块链的微服务评价系统, 利用5台服务器共搭建了20台虚拟主机, 每台的配置为CPU 2核4 GHz, 主频2.0 GHz, 硬盘250 GB. 其中2台用于搭建Oracle数据库存储基础信息, 2台用于构建数据中心网络共享系统, 1台用于搭建综合评价模型, 15台用于构造P2P网络, 虚拟15个组织, 利用Docker分别构建2个认可的对等点, 则总共30个对等节点, 有一个Orderer节点和一个Kafka Zookeeper集群支持它, 所有节点和Kafka Zookeeper都运行在数据中心网络虚拟机上.

3.2 效率测试

为了测试基于Fabric区块链的微服务评价系统在多用户操作时的运行效率, 本文分别以5个、10个、20个并发请求对系统进行测试, 统计从发起请求到区块写入的时长, 以验证系统的响应速度, 结果如表2所示.

由表2可知, 基于Hyperledger Fabric的微服务评价系统可支持多用户在同一时间进行操作发送请求, 其随着并发数的增加, 相应时长也在增加, 但依然在用户的可接受范围. Hyperledger Fabric区块链与以太坊等公有链不同, 其挖矿的过程排序节点完成的, 因此交易效率较高, 能够满足较多用户同时对微服务各维度进行打分评价的需求.

3.3 基于AHP和熵值法微服务综合评价

本文收集10个区块链评价用户对某个微服务各维度进行打分, 由于当指标评分标准超过5级以后, 所增加的标度带来的效用很小^[22], 因此本文采用5分制, 每个维度的评价等级 $\alpha = \left( {5,4,3,2,1} \right) $ . 该微服务6个维度的评价结果如表3.

利用10个用户对微服务的6个维度的打分表, 计算6个维度指标值的信息效用值, 计算结果如下:

${W_E} = (0.32,0.24,0.13,0.22,0.14,0.16)$

根据公式 ${w'_j} = w_j^A*d_j^E$ 和式(1),得到结合层次分析法和熵值法得到各维度最终权重为:

${W_E} = (0.2767,0.2599,0.1476,0.1844,0.0773,0.0541)$

分别利用AHP、熵值法及其相结合的方法计算的微服务各维度权值结果如表4.

上述结果显示, 对于维度A1(功能可用性), 在仅使用AHP确定的权重较大, 经由熵值法结合调整后, 权重值被调小. 这样既可以保证重要指标不被剔除, 又可以避免因指标值过于相近导致该指标失去应有的价值. 对于维度A4(服务扩展性), 是一个重要的指标, 但这一指标被评价专家所忽视, 不同评价用户在这一指标上的表现差别很大, 该指标初始AHP权重较小,但由于其成为将微服务区分出优劣的高效度指标而被赋以更大的权重. 这些说明在微服务保障功能可用后, 其扩展性是评价用户关注的重点,在开发微服务功能时需要考虑其通用性, 提升微服务的应用价值.

4 结论与展望

本文将Hyperledger Fabric区块链的技术与评价系统相结合, 将用户对微服务各维度打分数据进行记账, 保障了微服务评价数据的透明、不可篡改、可追溯, 评价数据安全可信. Hyperledger Fabric的区块链类型为联盟链, 其吞吐量相比比特币和以太坊要高, 本系统可同时支持较多评价用户的并发量. 同时, 利用AHP和熵值法相结合的微服务维度权值计算方法, 构建微服务综合评价模型, 保证重要指标的权值过大, 又避免了因维度的评价值过于相近导致该指标失去应有的价值. 更加合理的反应了微服务的真实价值, 为微服务的智能化管理提供有效的数据支撑. 下一步将对系统的共识算法进行优化, 提升达成共识的速度和吞吐量, 并将改评价系统应用到其他需要评价的业务中.