趙曉峰 張紹華 盧 暾 戴炳榮 李 超

1(復(fù)旦大學(xué)協(xié)同信息與系統(tǒng)實驗室 上海201210) 2(上海計算機(jī)軟件技術(shù)開發(fā)中心 上海 201112)

0 引 言

區(qū)塊鏈技術(shù)是一種近年來迅速發(fā)展起來的分布式數(shù)據(jù)庫技術(shù)，其起源于數(shù)字加密貨幣領(lǐng)域。區(qū)塊鏈技術(shù)的去中心化、數(shù)據(jù)加密和智能合約等核心技術(shù)使得其在積分交易、數(shù)字版權(quán)保護(hù)等領(lǐng)域有著廣泛的應(yīng)用[1]。區(qū)塊鏈系統(tǒng)中沒有中心化的控制機(jī)構(gòu)，參與區(qū)塊鏈網(wǎng)絡(luò)中的節(jié)點(diǎn)的地位功能均相同。區(qū)塊鏈應(yīng)用通過客戶端接入應(yīng)用層，參與區(qū)塊鏈網(wǎng)絡(luò)中的活動，如挖礦、投票和發(fā)送交易等。當(dāng)前，區(qū)塊鏈應(yīng)用往往通過單客戶端參與區(qū)塊鏈網(wǎng)絡(luò)中的活動，因此導(dǎo)致區(qū)塊鏈系統(tǒng)無法承受較大的并發(fā)且沒有足夠的冗余機(jī)制以保證安全性和穩(wěn)定性。

現(xiàn)如今區(qū)塊鏈技術(shù)在虛擬貨幣、版權(quán)交易等諸多領(lǐng)域有著充分的應(yīng)用[2]。區(qū)塊鏈技術(shù)在虛擬貨幣領(lǐng)域的影響非常大，如比特幣、以太幣等，是近年來增長最快的金融投資產(chǎn)品。區(qū)塊鏈技術(shù)的去中心化特征使得在區(qū)塊鏈網(wǎng)絡(luò)中沒有中心化的管理機(jī)構(gòu)，這改變了傳統(tǒng)的第三方信任的架構(gòu)，將信任轉(zhuǎn)移到網(wǎng)絡(luò)中所有的節(jié)點(diǎn)共同承擔(dān)[3]。區(qū)塊鏈在版權(quán)保護(hù)等相關(guān)領(lǐng)域的落地，利用了其存證不可更改的特點(diǎn)。其數(shù)據(jù)分布式存儲，沒有中心化的架構(gòu)對數(shù)據(jù)擁有唯一的所有權(quán)。同時利用區(qū)塊鏈技術(shù)中核心的智能合約技術(shù)實現(xiàn)業(yè)務(wù)自動化結(jié)算的功能，智能合約是將業(yè)務(wù)場景中核心的業(yè)務(wù)邏輯封裝成代碼的形式運(yùn)行在區(qū)塊鏈網(wǎng)絡(luò)中。區(qū)塊鏈技術(shù)的蓬勃發(fā)展體現(xiàn)在區(qū)塊鏈應(yīng)用如雨后春筍般涌現(xiàn)出來。但是目前區(qū)塊鏈技術(shù)本身還存在一些問題，導(dǎo)致沒有一個殺手級的應(yīng)用出現(xiàn)在市場。廣大的高?？蒲腥藛T和業(yè)內(nèi)開發(fā)人員均在積極探索和改進(jìn)區(qū)塊鏈技術(shù)在應(yīng)用中的不足。本文在實踐中發(fā)現(xiàn)區(qū)塊鏈技術(shù)通過客戶端接入應(yīng)用層的架構(gòu)導(dǎo)致其無法面對高并發(fā)高可用的業(yè)務(wù)場景，因此在現(xiàn)在市場流量較大的情況下，區(qū)塊鏈技術(shù)無法支持。

微服務(wù)(Micro-Service，MS)是近年來工業(yè)界提出的概念，其意義是參考服務(wù)化的理念，將后臺系統(tǒng)按照功能拆分成多個子功能模塊，并將單個服務(wù)使用容器封裝操作管理的一棧式解決方案[4]。隨著區(qū)塊鏈面向的應(yīng)用場景實用性增強(qiáng)，用戶量也隨之增大，單體應(yīng)用架構(gòu)在提供足夠的并發(fā)處理方面能力不足。針對區(qū)塊鏈應(yīng)用場景，性能瓶頸僅是區(qū)塊鏈應(yīng)用模塊及區(qū)塊鏈客戶端的服務(wù)能力，因此擴(kuò)展整個單體應(yīng)用會導(dǎo)致成本(CPU、內(nèi)存等)的不必要增加。本文結(jié)合微服務(wù)思想，提出了一種單節(jié)點(diǎn)多客戶端的應(yīng)用架構(gòu)。在系統(tǒng)的區(qū)塊鏈交互模塊和區(qū)塊鏈客戶端服務(wù)能力不足的情況下，可以針對能力不足的模塊在最小資源消耗的情況下進(jìn)行擴(kuò)展，達(dá)到高并發(fā)的效果。對于模塊有可能出現(xiàn)的故障，也有足夠的備用節(jié)點(diǎn)保證任務(wù)正常執(zhí)行。在擴(kuò)展服務(wù)節(jié)點(diǎn)的同時，本文針對區(qū)塊鏈應(yīng)用業(yè)務(wù)場景設(shè)計了負(fù)載均衡模型以提高并發(fā)量和任務(wù)執(zhí)行效率。

1 相關(guān)工作

1.1 私募股權(quán)平臺

私募股權(quán)項目平臺通過募集私募股權(quán)項目信息，提供私募股權(quán)相信信息的隱私保護(hù)及信息自動化交易等功能[5]?？蛻粼谄脚_發(fā)布項目信息招募合伙人，合伙人通過平臺提供的信息篩選尋找合適的投資項目?；趨^(qū)塊鏈技術(shù)的私募股權(quán)平臺構(gòu)建在近年來受到了互聯(lián)網(wǎng)金融領(lǐng)域的廣泛關(guān)注，構(gòu)建高性能高并發(fā)高可用的區(qū)塊鏈服務(wù)平臺是研究的重點(diǎn)[6]。區(qū)塊鏈技術(shù)的去中心化、隱私保護(hù)、自動化結(jié)算[7]等特點(diǎn)剛好可以滿足私募股權(quán)業(yè)務(wù)場景下的需求。

1.2 高并發(fā)架構(gòu)

近年來行業(yè)內(nèi)對高可用高并發(fā)架構(gòu)的研究也如火如荼地進(jìn)行，目前業(yè)內(nèi)非常流行的高并發(fā)應(yīng)用架構(gòu)有微服務(wù)、SOA等[8]。微服務(wù)是將應(yīng)用系統(tǒng)根據(jù)業(yè)務(wù)的分類拆分成獨(dú)立的集成度夠高的小系統(tǒng)，在生產(chǎn)環(huán)境下，根據(jù)業(yè)務(wù)的實際情況對微服務(wù)系統(tǒng)的小系統(tǒng)進(jìn)行擴(kuò)展迭代等操作[9]。微服務(wù)技術(shù)近年來在行業(yè)內(nèi)取得了非常大的進(jìn)展，在高并發(fā)場景中有非常重要的應(yīng)用，阿里巴巴、京東等大型企業(yè)化應(yīng)用均采用此架構(gòu)。

1.3 負(fù)載均衡

僅使用微服務(wù)技術(shù)是遠(yuǎn)遠(yuǎn)不夠的，因為現(xiàn)成的微服務(wù)解決方案并未考慮區(qū)塊鏈相關(guān)業(yè)務(wù)的特殊性。微服務(wù)技術(shù)往往結(jié)合容器化技術(shù)進(jìn)行相應(yīng)的部署和構(gòu)建?；谌萜鳂?gòu)建的區(qū)塊鏈服務(wù)平臺在HyperLedger的應(yīng)用中非常廣泛。Ethereum在市場上的占有的分額比較高，但是缺少高效的BaaS平臺方案。實踐中發(fā)現(xiàn)，Ethereum客戶端在容器中運(yùn)行會導(dǎo)致容器狀態(tài)受到影響，而容器的狀態(tài)又會影響到其提供服務(wù)的能力，因此需要一定的負(fù)載均衡與回收策略。

云計算領(lǐng)域有多種負(fù)載均衡策略如輪詢、加權(quán)、最少連接等[10]。但此類方法并未考慮服務(wù)節(jié)點(diǎn)的狀態(tài)。文獻(xiàn)[11]將任務(wù)分組，且使用組內(nèi)任務(wù)優(yōu)先級相等，組內(nèi)截至?xí)r間短的任務(wù)優(yōu)先得到調(diào)度，實現(xiàn)了較高的任務(wù)調(diào)度效率。優(yōu)秀的負(fù)載均衡策略應(yīng)該有效地減少總?cè)蝿?wù)完成的時間，同時保證較好的系統(tǒng)的負(fù)載均衡，提高服務(wù)資源的利用率[12]。文獻(xiàn)[13]提出了相空分析方法，將集群中每個服務(wù)器的資源占用參數(shù)投影到以這些參數(shù)為坐標(biāo)軸的相空間中，將服務(wù)器參數(shù)變化看作相空間中點(diǎn)的運(yùn)動。文獻(xiàn)[14]在計算空間分析方法的基礎(chǔ)上，提出了負(fù)載均衡度概念，設(shè)計了最小負(fù)載均衡優(yōu)先算法并對該算法的基本理論進(jìn)行了研究和分析。

本文在文獻(xiàn)[13]、文獻(xiàn)[14]所提出的云計算空間分析方法基礎(chǔ)上，經(jīng)過分析論證，充分考慮區(qū)塊鏈相關(guān)業(yè)務(wù)的特殊性和Ethereum客戶端在容器中的運(yùn)行情況，建立面向區(qū)塊鏈應(yīng)用場景下的負(fù)載均衡模型，提升區(qū)塊鏈服務(wù)模塊的并發(fā)能力。

2 架構(gòu)設(shè)計

2.1 應(yīng)用架構(gòu)

區(qū)塊鏈技術(shù)的應(yīng)用架構(gòu)種類龐多，大多數(shù)中小型企業(yè)往往采用單體應(yīng)用的架構(gòu)模式。單體應(yīng)用架構(gòu)有不便擴(kuò)展、安全性低、并發(fā)低等特性。本文結(jié)合微服務(wù)思想設(shè)計了區(qū)塊鏈的微服務(wù)應(yīng)用框架，在單體應(yīng)用的基礎(chǔ)上首先對業(yè)務(wù)進(jìn)行了橫向的讀寫拆分，從安全限流的角度對業(yè)務(wù)進(jìn)行了縱向拆分并加入了熔斷和消息緩存等中間件機(jī)制。

從業(yè)務(wù)層面看，區(qū)塊鏈應(yīng)用的相關(guān)業(yè)務(wù)可大致分為讀業(yè)務(wù)與寫業(yè)務(wù)。讀業(yè)務(wù)如獲取賬戶信息、獲取區(qū)塊信息等操作耗費(fèi)資源小、速度快，不存在并發(fā)瓶頸的問題；寫業(yè)務(wù)如發(fā)布合約、調(diào)用合約交易等業(yè)務(wù)需要消耗占用客戶端資源，存在性能瓶頸。同時，區(qū)塊鏈寫業(yè)務(wù)涉及的數(shù)據(jù)安全性要求較高，因此對寫業(yè)務(wù)需要足夠的安全保障。

從安全和系統(tǒng)響應(yīng)速度角度出發(fā)，本文需要使用消息中間件對消息進(jìn)行緩存并且需要一定的熔斷機(jī)制保證分布式系統(tǒng)的容錯機(jī)制。因此，本文在業(yè)務(wù)層面將系統(tǒng)縱向拆分成服務(wù)提供者和服務(wù)消費(fèi)者，并且在消費(fèi)者和服務(wù)者之間使用消息中間件和熔斷機(jī)制保證響應(yīng)速度和可靠性。

本文基于區(qū)塊鏈的私募股權(quán)平臺總架構(gòu)如圖1所示。

在本文架構(gòu)中，由于網(wǎng)絡(luò)故障等原因，服務(wù)可能出現(xiàn)故障，而調(diào)用出現(xiàn)故障的服務(wù)會導(dǎo)致線程阻塞和服務(wù)癱瘓。服務(wù)之間的依賴性會導(dǎo)致故障在整個系統(tǒng)中傳播，使得整個微服務(wù)系統(tǒng)雪崩式崩潰。為防止上述服務(wù)雪崩，本文基于熔斷器設(shè)計模式，當(dāng)對特定服務(wù)的調(diào)用不可用達(dá)到一個閾值，熔斷器將會被打開，故障服務(wù)斷開，其注冊在服務(wù)注冊中心的API狀態(tài)變?yōu)椴豢捎谩^(qū)塊鏈后臺服務(wù)模塊架構(gòu)如圖2所示。

本文采用以太坊作為區(qū)塊鏈底層服務(wù)平臺，結(jié)合微服務(wù)思想，使用容器化技術(shù)部署以太坊客戶端，并通過調(diào)用接口實時檢測底層區(qū)塊鏈環(huán)境，搭建了一個簡化的BaaS(BlockChain As A Service)實驗平臺。本實驗平臺中，多個客戶端共用一份數(shù)據(jù)，因此在參與區(qū)塊鏈網(wǎng)路中時，即使擁有多個節(jié)點(diǎn)，但依然只有一個節(jié)點(diǎn)提供服務(wù)。區(qū)塊鏈底層服務(wù)系統(tǒng)架構(gòu)如圖3所示，其中：Geth Client是以太坊提供的官方客戶端，Status Monitor是區(qū)塊鏈系統(tǒng)狀態(tài)監(jiān)控中心，它們均運(yùn)行在容器內(nèi)部。整個系統(tǒng)共享同一份數(shù)據(jù)，因此在區(qū)塊鏈網(wǎng)絡(luò)中僅看作一個節(jié)點(diǎn)。

2.2 問題分析

在2.1節(jié)所描述的架構(gòu)中，底層的多個客戶端向應(yīng)用層提供區(qū)塊鏈服務(wù)，客戶端運(yùn)行在容器中。通過實驗監(jiān)控發(fā)現(xiàn)，容器的狀態(tài)受到執(zhí)行業(yè)務(wù)影響較大，且容器的狀態(tài)對容器的執(zhí)行業(yè)務(wù)能力影響較大。因此，設(shè)計合理的調(diào)度機(jī)制，將應(yīng)用層的任務(wù)分配給合適的區(qū)塊鏈客戶端進(jìn)行處理。

在區(qū)塊鏈服務(wù)節(jié)點(diǎn)提供服務(wù)的過程中，服務(wù)容器的狀態(tài)變化較大的有內(nèi)存和磁盤讀取量兩個參數(shù)，監(jiān)控參數(shù)如圖4所示。隨著任務(wù)的執(zhí)行，CPU使用率沒有明顯變化，內(nèi)存變化率變化較大。對于磁盤讀取量，分別求取最大值磁盤讀取量的百分比的平均值，這個值并不能精確衡量容器磁盤讀取量的大小，但能從一定程度上反映在執(zhí)行過程中磁盤讀取量的變化。根據(jù)節(jié)點(diǎn)提供的服務(wù)類型上的分析，節(jié)點(diǎn)進(jìn)行挖礦等操作導(dǎo)致內(nèi)存占用升高，節(jié)點(diǎn)進(jìn)行HTTP通信以及區(qū)塊數(shù)據(jù)打包導(dǎo)致磁盤IO數(shù)據(jù)量增大，因此本文考慮設(shè)計合理的調(diào)度模型來解決該問題，對服務(wù)能力較差、即將發(fā)生阻塞的節(jié)點(diǎn)進(jìn)行資源回收和重新分配，使之恢復(fù)處理能力。

3 調(diào)度模型設(shè)計

3.1 負(fù)載均衡依據(jù)

對于區(qū)塊鏈運(yùn)行在容器中產(chǎn)生的資源消耗使得客戶端無法正常運(yùn)行的問題，本文將采用負(fù)載均衡調(diào)度算法來解決，將運(yùn)行中的容器的工作狀態(tài)表示為一個參數(shù)向量。通過實驗發(fā)現(xiàn)，節(jié)點(diǎn)在處理寫任務(wù)后，內(nèi)存和磁盤讀取的占用會急劇增加。因此選取容器的這兩個參數(shù)建立容器狀態(tài)空間，將節(jié)點(diǎn)容器的狀態(tài)向量投影到該二維平面。對于本調(diào)度系統(tǒng)而言，在運(yùn)行狀態(tài)下，計算節(jié)點(diǎn)將大致分為兩類，一類資源消耗度較小，其投影點(diǎn)聚集在原點(diǎn)附近，另一類處于資源占用狀態(tài)，其投影點(diǎn)遠(yuǎn)離原點(diǎn)。

假設(shè)容器的個數(shù)為m，任務(wù)調(diào)度時根據(jù)容器狀態(tài)將任務(wù)在m個容器上合理分配。將m個容器在空間的投影做兩種極端化處理，假設(shè)其在空間投影的點(diǎn)集為U={(x1,x2)|0≤x1≤1,0≤x2≤1}，其中x1是容器內(nèi)存占用率，x2是磁盤IO量與容器在阻塞時IO量的比值。

讀取m個容器在不處理寫任務(wù)時刻和均處理完寫任務(wù)后的狀態(tài)信息并求取到原點(diǎn)的距離：

U1={(x1,x2)|0≤x1≤1,0≤x2≤1}

(1)

U2={(x1,x2)|0≤x1≤1,0≤x2≤1}

(2)

在狀態(tài)空間中的投影點(diǎn)分布如圖5所示。

計算平均值并以之做狀態(tài)分界圓：

(3)

為了評估本系統(tǒng)的健康狀況，可以用一個健康參數(shù)進(jìn)行衡量，定義其為負(fù)載均衡健康度。假設(shè)負(fù)載均衡系統(tǒng)中有m1個容器處于分界圓以內(nèi)，m2個容器處于分界圓以外(m=m1+m2)。則定義健康參數(shù)：

(4)

由于m1+m2=m，式(4)可化簡為：

(5)

由健康參數(shù)的定義可知，當(dāng)LBH≥0時，此時系統(tǒng)有大多數(shù)的容器處于閑置狀態(tài)，此時健康狀態(tài)良好，且LBH越大健康狀態(tài)越好；當(dāng)LBH<0時，健康狀態(tài)情況較差。

3.2 任務(wù)調(diào)度模型

本文將n個獨(dú)立的任務(wù)分配到m臺容器節(jié)點(diǎn)上，m

ti=tmemory+tio_memory

(6)

式中：tmemory是任務(wù)所需的內(nèi)存大??；tio_memory是任務(wù)處理時需要的IO內(nèi)存大小。

m個容器資源可以表示成CON(i)=(con1,con2,…,conm)，coni表示第i個容器，其屬性為：

coni=(conmemory,conio_memory)

(7)

式中：conmemory是容器剩余可用內(nèi)存；conio_memory是容器現(xiàn)有可用IO內(nèi)存。

本調(diào)度模型的目標(biāo)是讓系統(tǒng)承受盡量大的并發(fā)，其目標(biāo)函數(shù)與約束條件如下：

max n

s.t.ti_memory≤conj_memoryi=1,2,…,n

ti_iomemory≤conj_iomemoryj=1,2,…,m

(8)

即僅在約束條件滿足的時候才能將任務(wù)分配給相應(yīng)的節(jié)點(diǎn)。

3.3 構(gòu)建優(yōu)先級模型

在區(qū)塊鏈環(huán)境下，任務(wù)可以分為讀任務(wù)和寫任務(wù)，讀任務(wù)不消耗容器資源因此優(yōu)先使用第二區(qū)域的容器，在第二區(qū)域容器均無空閑時選擇第三區(qū)域的容器。對于寫任務(wù)，可以分為發(fā)布合約任務(wù)、操作賬戶任務(wù)、調(diào)用合約任務(wù)，發(fā)布合約任務(wù)較少，操作賬戶任務(wù)次之，調(diào)用合約任務(wù)較多。本文根據(jù)任務(wù)出現(xiàn)的頻率對其先后執(zhí)行順序，優(yōu)先執(zhí)行處理出現(xiàn)次數(shù)較少的任務(wù)。

任務(wù)優(yōu)先級模型具體描述如下：讀任務(wù)與寫任務(wù)分開執(zhí)行；讀寫任務(wù)可能在第二區(qū)域沖突，此時因為讀任務(wù)耗時短且不消耗系統(tǒng)資源，優(yōu)先執(zhí)行；讀任務(wù)按時間先后順序執(zhí)行；寫任務(wù)分為發(fā)布合約任務(wù)、操作賬戶任務(wù)和調(diào)用合約任務(wù)，其在實際業(yè)務(wù)場景中出現(xiàn)頻次依次增加，同時重要性會減小，因此優(yōu)先級為降序排列。

具體任務(wù)優(yōu)先級如圖6所示。

圖6 任務(wù)流優(yōu)先級

3.4 任務(wù)分配模型

任務(wù)的優(yōu)先級決定了任務(wù)的調(diào)度順序，本文根據(jù)容器的健康參數(shù)將容器分為三個區(qū)域。將讀任務(wù)交給第二區(qū)域的容器處理，寫任務(wù)交給第一區(qū)域的容器處理。第三區(qū)域的容器進(jìn)行定時回收重啟處理。在各個區(qū)域內(nèi)部，本文結(jié)合區(qū)塊鏈場景下的任務(wù)的性質(zhì)及資源的使用和分配情況，構(gòu)建動態(tài)優(yōu)先級。

因為容器的狀態(tài)影響其執(zhí)行寫操作，因此本文將容器按狀態(tài)分為兩類，具體映射到狀態(tài)平面空間為Ⅰ區(qū)、Ⅱ區(qū)，Ⅰ區(qū)代表安全區(qū)，Ⅱ區(qū)代表非安全讀區(qū)。以式(3)得到的數(shù)值Disave為分界線。圖7為容器狀態(tài)平面分區(qū)示意圖。

任務(wù)分配模型描述如下：對于寫任務(wù)，優(yōu)先分配到Ⅰ區(qū)，當(dāng)Ⅰ區(qū)沒有節(jié)點(diǎn)時分配到Ⅱ區(qū)；對于讀任務(wù)，優(yōu)先分配到Ⅱ區(qū)，當(dāng)Ⅱ區(qū)沒有節(jié)點(diǎn)時分配到Ⅰ區(qū)。

3.5 算法描述

本文設(shè)計的面向區(qū)塊鏈微服務(wù)化場景下的任務(wù)調(diào)度算法描述如下：將任務(wù)根據(jù)其讀寫性質(zhì)進(jìn)行分類并按時間排序；將任務(wù)依次動態(tài)地分配到適合的區(qū)域中的容器；更新容器的狀態(tài)信息，動態(tài)將任務(wù)分配到其中；將第三分區(qū)中的容器依次進(jìn)行重啟操作，回收資源；檢查健康狀態(tài)參數(shù)，若健康狀態(tài)參數(shù)為負(fù)數(shù)，則暫停如任務(wù)分配，等待知道健康狀態(tài)為正數(shù)則繼續(xù)分配任務(wù)；返回流程開始下一個任務(wù)的調(diào)度。

4 實驗測試

目前面向私募股權(quán)平臺的版權(quán)交易平臺運(yùn)行良好，本部分測驗分為功能測試與性能測試兩個方面。功能測試即是否可以完成創(chuàng)建賬戶、轉(zhuǎn)賬、發(fā)布智能合約和挖礦等功能。性能測試通過與單客戶端與單體區(qū)塊鏈服務(wù)后臺系統(tǒng)構(gòu)成的區(qū)塊鏈服務(wù)平臺做并發(fā)性能對比。

本文測試環(huán)境為基于VMware station pro構(gòu)建的虛擬機(jī)。VMware station pro搭建于單機(jī)電腦，其配置為：系統(tǒng)Windows 10專業(yè)版64位；處理器Intel(R) Core(TM) i7- 5600U @2.6 GHz；內(nèi)存12 GB。VMware station pro相關(guān)配置為：版本12.5.7 build-5813279；系統(tǒng)Ubuntu 16.04；內(nèi)存2 GB；CPU 2核；硬盤20 GB；容器Docker CE。

本文系統(tǒng)提供的區(qū)塊鏈系統(tǒng)操作主要分為四類，分別是連接管理、賬戶管理、交易管理與合約發(fā)布，具體功能與測試情況如表1所示。

表1 本文系統(tǒng)的四類功能

以上功能均完成測試，可以成功運(yùn)行。

因區(qū)塊鏈底層服務(wù)平臺是多客戶端架構(gòu)，為了測試多客戶端在提供服務(wù)方面的能力，分別采用3客戶端、5客戶端和8客戶端三種形式進(jìn)行測試。對于并發(fā)性方面，本文分別在200、600、1 000和1 200并發(fā)量的情況下測試響應(yīng)時間，測試結(jié)果如圖8所示。

可以看出，在200并發(fā)量的時候，單客戶端的完成速度高于多客戶端，這是因為在多客戶端之間的切換需要消耗時間。因此在低并發(fā)情況下，單客戶端架構(gòu)性能優(yōu)于多客戶端架構(gòu)。在并發(fā)量到600及以上的時候，多客戶端架構(gòu)的優(yōu)越性逐漸體現(xiàn)出來，多客戶端的任務(wù)完成時間小于單客戶端的任務(wù)完成時間，而且隨著客戶端的數(shù)量的增加，任務(wù)完成的時間變得更短。在并發(fā)量達(dá)到1 200的時候，單客戶端因為阻塞問題導(dǎo)致無法正常完成功能，但是多客戶端架構(gòu)依然在沒有影響的情況下完成任務(wù)。

從上述實驗結(jié)果可見，本文針對區(qū)塊鏈應(yīng)用場景所設(shè)計的高并發(fā)架構(gòu)可以實現(xiàn)相應(yīng)的讀寫功能，并且在大并發(fā)量情況下的性能優(yōu)于單客戶端架構(gòu)。

5 結(jié) 語

本文設(shè)計和實現(xiàn)的區(qū)塊鏈服務(wù)平臺有效地提高了區(qū)塊鏈技術(shù)在應(yīng)用中并發(fā)性能低和安全性低等問題。對區(qū)塊鏈相關(guān)業(yè)務(wù)的拆分使得服務(wù)的擴(kuò)展更加靈活，能夠在消耗資源最小的情況下按需提升平臺服務(wù)能力?；谌萜骰夹g(shù)構(gòu)建的底層區(qū)塊鏈服務(wù)平臺服務(wù)性能良好，克服了以太坊客戶端提供服務(wù)能力不足的問題?；诖藰?gòu)建的簡單BaaS實驗平臺，在其他區(qū)塊鏈應(yīng)用中同樣適用。面向區(qū)塊鏈業(yè)務(wù)場景設(shè)計的負(fù)載均衡模型，充分考慮了區(qū)塊鏈業(yè)務(wù)的特性，能夠在此業(yè)務(wù)場景下發(fā)揮最大的效果。