面向私募股權的區塊鏈服務系統設計

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

1(復旦大學協同信息與系統實驗室 上海201210) 2(上海計算機軟件技術開發中心 上海 201112)

0 引 言

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

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

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

1 相關工作

1.1 私募股權平臺

私募股權項目平臺通過募集私募股權項目信息，提供私募股權相信信息的隱私保護及信息自動化交易等功能[5]。客戶在平臺發布項目信息招募合伙人，合伙人通過平臺提供的信息篩選尋找合適的投資項目。基于區塊鏈技術的私募股權平臺構建在近年來受到了互聯網金融領域的廣泛關注，構建高性能高并發高可用的區塊鏈服務平臺是研究的重點[6]。區塊鏈技術的去中心化、隱私保護、自動化結算[7]等特點剛好可以滿足私募股權業務場景下的需求。

1.2 高并發架構

近年來行業內對高可用高并發架構的研究也如火如荼地進行，目前業內非常流行的高并發應用架構有微服務、SOA等[8]。微服務是將應用系統根據業務的分類拆分成獨立的集成度夠高的小系統，在生產環境下，根據業務的實際情況對微服務系統的小系統進行擴展迭代等操作[9]。微服務技術近年來在行業內取得了非常大的進展，在高并發場景中有非常重要的應用，阿里巴巴、京東等大型企業化應用均采用此架構。

1.3 負載均衡

僅使用微服務技術是遠遠不夠的，因為現成的微服務解決方案并未考慮區塊鏈相關業務的特殊性。微服務技術往往結合容器化技術進行相應的部署和構建。基于容器構建的區塊鏈服務平臺在HyperLedger的應用中非常廣泛。Ethereum在市場上的占有的分額比較高，但是缺少高效的BaaS平臺方案。實踐中發現，Ethereum客戶端在容器中運行會導致容器狀態受到影響，而容器的狀態又會影響到其提供服務的能力，因此需要一定的負載均衡與回收策略。

云計算領域有多種負載均衡策略如輪詢、加權、最少連接等[10]。但此類方法并未考慮服務節點的狀態。文獻[11]將任務分組，且使用組內任務優先級相等，組內截至時間短的任務優先得到調度，實現了較高的任務調度效率。優秀的負載均衡策略應該有效地減少總任務完成的時間，同時保證較好的系統的負載均衡，提高服務資源的利用率[12]。文獻[13]提出了相空分析方法，將集群中每個服務器的資源占用參數投影到以這些參數為坐標軸的相空間中，將服務器參數變化看作相空間中點的運動。文獻[14]在計算空間分析方法的基礎上，提出了負載均衡度概念，設計了最小負載均衡優先算法并對該算法的基本理論進行了研究和分析。

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

2 架構設計

2.1 應用架構

區塊鏈技術的應用架構種類龐多，大多數中小型企業往往采用單體應用的架構模式。單體應用架構有不便擴展、安全性低、并發低等特性。本文結合微服務思想設計了區塊鏈的微服務應用框架，在單體應用的基礎上首先對業務進行了橫向的讀寫拆分，從安全限流的角度對業務進行了縱向拆分并加入了熔斷和消息緩存等中間件機制。

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

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

本文基于區塊鏈的私募股權平臺總架構如圖1所示。

在本文架構中，由于網絡故障等原因，服務可能出現故障，而調用出現故障的服務會導致線程阻塞和服務癱瘓。服務之間的依賴性會導致故障在整個系統中傳播，使得整個微服務系統雪崩式崩潰。為防止上述服務雪崩，本文基于熔斷器設計模式，當對特定服務的調用不可用達到一個閾值，熔斷器將會被打開，故障服務斷開，其注冊在服務注冊中心的API狀態變為不可用。區塊鏈后臺服務模塊架構如圖2所示。

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

2.2 問題分析

在2.1節所描述的架構中，底層的多個客戶端向應用層提供區塊鏈服務，客戶端運行在容器中。通過實驗監控發現，容器的狀態受到執行業務影響較大，且容器的狀態對容器的執行業務能力影響較大。因此，設計合理的調度機制，將應用層的任務分配給合適的區塊鏈客戶端進行處理。

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

3 調度模型設計

3.1 負載均衡依據

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

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

讀取m個容器在不處理寫任務時刻和均處理完寫任務后的狀態信息并求取到原點的距離：

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

(1)

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

(2)

在狀態空間中的投影點分布如圖5所示。

計算平均值并以之做狀態分界圓：

(3)

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

(4)

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

(5)

由健康參數的定義可知，當LBH≥0時，此時系統有大多數的容器處于閑置狀態，此時健康狀態良好，且LBH越大健康狀態越好；當LBH<0時，健康狀態情況較差。

3.2 任務調度模型

本文將n個獨立的任務分配到m臺容器節點上，m

ti=tmemory+tio_memory

(6)

式中：tmemory是任務所需的內存大小；tio_memory是任務處理時需要的IO內存大小。

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

coni=(conmemory,conio_memory)

(7)

式中：conmemory是容器剩余可用內存；conio_memory是容器現有可用IO內存。

本調度模型的目標是讓系統承受盡量大的并發，其目標函數與約束條件如下：

max n

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

ti_iomemory≤conj_iomemoryj=1,2,…,m

(8)

即僅在約束條件滿足的時候才能將任務分配給相應的節點。

3.3 構建優先級模型

在區塊鏈環境下，任務可以分為讀任務和寫任務，讀任務不消耗容器資源因此優先使用第二區域的容器，在第二區域容器均無空閑時選擇第三區域的容器。對于寫任務，可以分為發布合約任務、操作賬戶任務、調用合約任務，發布合約任務較少，操作賬戶任務次之，調用合約任務較多。本文根據任務出現的頻率對其先后執行順序，優先執行處理出現次數較少的任務。

任務優先級模型具體描述如下：讀任務與寫任務分開執行；讀寫任務可能在第二區域沖突，此時因為讀任務耗時短且不消耗系統資源，優先執行；讀任務按時間先后順序執行；寫任務分為發布合約任務、操作賬戶任務和調用合約任務，其在實際業務場景中出現頻次依次增加，同時重要性會減小，因此優先級為降序排列。

具體任務優先級如圖6所示。

圖6 任務流優先級

3.4 任務分配模型

任務的優先級決定了任務的調度順序，本文根據容器的健康參數將容器分為三個區域。將讀任務交給第二區域的容器處理，寫任務交給第一區域的容器處理。第三區域的容器進行定時回收重啟處理。在各個區域內部，本文結合區塊鏈場景下的任務的性質及資源的使用和分配情況，構建動態優先級。

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

任務分配模型描述如下：對于寫任務，優先分配到Ⅰ區，當Ⅰ區沒有節點時分配到Ⅱ區；對于讀任務，優先分配到Ⅱ區，當Ⅱ區沒有節點時分配到Ⅰ區。

3.5 算法描述

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

4 實驗測試

目前面向私募股權平臺的版權交易平臺運行良好，本部分測驗分為功能測試與性能測試兩個方面。功能測試即是否可以完成創建賬戶、轉賬、發布智能合約和挖礦等功能。性能測試通過與單客戶端與單體區塊鏈服務后臺系統構成的區塊鏈服務平臺做并發性能對比。

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

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

表1 本文系統的四類功能

以上功能均完成測試，可以成功運行。

因區塊鏈底層服務平臺是多客戶端架構，為了測試多客戶端在提供服務方面的能力，分別采用3客戶端、5客戶端和8客戶端三種形式進行測試。對于并發性方面，本文分別在200、600、1 000和1 200并發量的情況下測試響應時間，測試結果如圖8所示。

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

從上述實驗結果可見，本文針對區塊鏈應用場景所設計的高并發架構可以實現相應的讀寫功能，并且在大并發量情況下的性能優于單客戶端架構。

5 結 語

本文設計和實現的區塊鏈服務平臺有效地提高了區塊鏈技術在應用中并發性能低和安全性低等問題。對區塊鏈相關業務的拆分使得服務的擴展更加靈活，能夠在消耗資源最小的情況下按需提升平臺服務能力。基于容器化技術構建的底層區塊鏈服務平臺服務性能良好，克服了以太坊客戶端提供服務能力不足的問題。基于此構建的簡單BaaS實驗平臺，在其他區塊鏈應用中同樣適用。面向區塊鏈業務場景設計的負載均衡模型，充分考慮了區塊鏈業務的特性，能夠在此業務場景下發揮最大的效果。