朱冠燁， 裴倫浩， 郭彥輝

（中國(guó)聯(lián)合網(wǎng)絡(luò)通信有限公司濟(jì)南軟件研究院， 濟(jì)南 250000）

1 研究背景

1.1 區(qū)塊鏈平臺(tái)

區(qū)塊鏈?zhǔn)前凑找欢ǖ墓沧R(shí)規(guī)則將數(shù)據(jù)存儲(chǔ)于不同區(qū)塊，并以一定的哈希規(guī)則組合相連的數(shù)據(jù)結(jié)構(gòu)，通過密碼學(xué)的方式保證其不可篡改的分布式賬本［1］。 憑借“不可篡改”、“可追溯”等優(yōu)良特性，近年來區(qū)塊鏈技術(shù)發(fā)展如火如荼，眾多大型企業(yè)紛紛將區(qū)塊鏈技術(shù)作為重點(diǎn)的突破方向。 比較經(jīng)典的區(qū)塊鏈應(yīng)用，如比特幣、以太坊、超級(jí)賬本等，在各行業(yè)已經(jīng)投入使用。 聯(lián)通鏈BCS 系統(tǒng)是由中國(guó)聯(lián)通軟件研究院自研的區(qū)塊鏈產(chǎn)品，BCS 是集區(qū)塊鏈部署、運(yùn)維、節(jié)點(diǎn)管控、應(yīng)用等能力于一身的可視化操作平臺(tái)，支持以租戶的方式在聯(lián)通云上快速構(gòu)建穩(wěn)定、安全的生產(chǎn)級(jí)區(qū)塊鏈網(wǎng)絡(luò)，降低用戶對(duì)區(qū)塊鏈底層技術(shù)的獲取成本，實(shí)現(xiàn)業(yè)務(wù)數(shù)據(jù)快速、穩(wěn)定、安全上鏈。

傳統(tǒng)的區(qū)塊鏈部署方法較為冗雜，部署時(shí)需要進(jìn)行各主機(jī)的適配和區(qū)塊鏈調(diào)度的聯(lián)調(diào)，使用過程中主機(jī)資源不足時(shí)，進(jìn)行資源擴(kuò)展的過程較為復(fù)雜，常常影響業(yè)務(wù)數(shù)據(jù)的使用。 隨著云技術(shù)越來越成熟，騰訊云、阿里云、聯(lián)通云等提供了各類資源池和環(huán)境沙箱，資源支撐彈性調(diào)度。 基于此，本文從云環(huán)境出發(fā)，進(jìn)行了區(qū)塊鏈平臺(tái)搭建的嘗試。

1.2 容器和kubernetes

容器是指與系統(tǒng)其他部分隔離開的一系列進(jìn)程，類似于一個(gè)封閉的箱子，該箱子提供了某些應(yīng)用所需的全部依賴［2］。 由于容器的封閉性及其完備性，使得容器化的程序具有較高的可移植性。 容器技術(shù)的出現(xiàn)，使得復(fù)雜的業(yè)務(wù)過程可以進(jìn)行解耦，按照功能模塊進(jìn)行微服務(wù)拆分，各模塊各司其職，當(dāng)某個(gè)模塊運(yùn)行中斷時(shí)也不會(huì)使其他模塊受到影響。 因此，如果對(duì)區(qū)塊鏈平臺(tái)進(jìn)行微服務(wù)拆分，當(dāng)某個(gè)子模塊出現(xiàn)資源不足或者故障時(shí)，也不會(huì)影響區(qū)塊鏈平臺(tái)的業(yè)務(wù)使用。

kubernetes（k8s）是一個(gè)開源，以集群方式部署調(diào)度容器應(yīng)用，彈性伸縮以及運(yùn)維容器集群的系統(tǒng)［3］。 區(qū)塊鏈服務(wù)底層基于k8s 引擎調(diào)度，因各節(jié)點(diǎn)之間調(diào)用復(fù)雜，各節(jié)點(diǎn)又可能面臨資源擴(kuò)縮的問題，傳統(tǒng)的本地集群部署方式運(yùn)維復(fù)雜，因此，區(qū)塊鏈云化部署變得十分必要。

2 基于微服務(wù)的區(qū)塊鏈平臺(tái)部署

2.1 區(qū)塊鏈微服務(wù)架構(gòu)

BCS 系統(tǒng)架構(gòu)如圖1 所示。 通常一個(gè)完整的區(qū)塊鏈平臺(tái)系統(tǒng)調(diào)用邏輯如下：前端業(yè)務(wù)層用于和不同的業(yè)務(wù)系統(tǒng)對(duì)接，提供區(qū)塊鏈對(duì)外服務(wù)的接口，例如提供數(shù)據(jù)上鏈、查詢等操作支撐，當(dāng)用戶發(fā)送前臺(tái)的區(qū)塊鏈操作請(qǐng)求之后，請(qǐng)求會(huì)轉(zhuǎn)發(fā)到區(qū)塊鏈SDK調(diào)度層，即區(qū)塊鏈平臺(tái)后臺(tái)服務(wù)，后臺(tái)服務(wù)會(huì)對(duì)前臺(tái)的請(qǐng)求進(jìn)行判斷和轉(zhuǎn)發(fā)，如果是對(duì)平臺(tái)本身的操作，則進(jìn)行數(shù)據(jù)庫(kù)交互；如果請(qǐng)求到了智能合約，則轉(zhuǎn)發(fā)到智能合約層［4］；如果請(qǐng)求到了區(qū)塊鏈引擎或者k8s 引擎，則轉(zhuǎn)發(fā)至相應(yīng)的服務(wù)接口處。 當(dāng)請(qǐng)求涉及到區(qū)塊鏈操作時(shí)，區(qū)塊鏈底層服務(wù)會(huì)對(duì)交易進(jìn)行排序、打包、記賬等一系列操作，生成新的交易區(qū)塊并廣播到所有區(qū)塊，該過程在區(qū)塊鏈底層服務(wù)層完成，完成一次完整的前臺(tái)請(qǐng)求調(diào)用區(qū)塊鏈服務(wù)。

圖1 BCS 系統(tǒng)架構(gòu)圖Fig. 1 BCS system architecture diagram

2.2 基于微服務(wù)的云部署方案

按照區(qū)塊鏈平臺(tái)的工作流程，本文提出了基于微服務(wù)拆分的區(qū)塊鏈平臺(tái)部署方法，如圖2 所示。首先需要進(jìn)行云集群的搭建，目前市面上流行的云開發(fā)環(huán)境都提供了直接可用的k8s 集群環(huán)境；之后申請(qǐng)?jiān)骗h(huán)境配套的數(shù)據(jù)庫(kù)、共享存儲(chǔ)等資源；根據(jù)區(qū)塊鏈各個(gè)模塊的功能特點(diǎn)，進(jìn)行區(qū)塊鏈平臺(tái)微服務(wù)拆分、服務(wù)鏡像構(gòu)建、部署；最后，對(duì)部署的平臺(tái)進(jìn)行可用性驗(yàn)證。

圖2 基于微服務(wù)拆分的區(qū)塊鏈平臺(tái)部署方法Fig. 2 Blockchain platform deployment method based on microservices

2.3 微服務(wù)構(gòu)建與部署

每個(gè)模塊需要構(gòu)建其服務(wù)鏡像，以區(qū)塊鏈引擎模塊為例，對(duì)鏡像構(gòu)建以及應(yīng)用部署過程介紹如下：

在編寫鏡像構(gòu)建的Dockerfile 時(shí)，需要先將啟動(dòng)fabric 的配置文件，根據(jù)實(shí)際環(huán)境進(jìn)行修改；在構(gòu)建鏡像時(shí)，需要將fabric 的引擎程序和區(qū)塊鏈節(jié)點(diǎn)模板放在同一目錄下，并將啟動(dòng)區(qū)塊鏈節(jié)點(diǎn)的配置共享文件放在共享存儲(chǔ)的磁盤上，鏡像構(gòu)建完畢，推送至鏡像倉(cāng)庫(kù)。

部署時(shí)需要編寫該服務(wù)模塊啟動(dòng)使用的yaml文件，使用deployment 的方式將該服務(wù)啟動(dòng)起來。首先需要為該pod 提供掛載的PV 和PVC，配置好鏡像拉取策略進(jìn)行鏡像拉取，指定好服務(wù)的pod 對(duì)應(yīng)的資源量和指定容器的服務(wù)端口。 需要注意的是，因?yàn)閰^(qū)塊鏈引擎需要調(diào)用智能合約部分，需要指定好智能合約的上傳路徑，在環(huán)境變量中進(jìn)行配置，將GOPATH 環(huán)境變量配置在啟動(dòng)文件中。

最后通過kubernetes 中service 的部署方式，將容器的服務(wù)端口暴露出去，實(shí)現(xiàn)不同服務(wù)模塊之間互訪，完成配置。 所有的服務(wù)部署完畢，通過嘗試調(diào)用智能合約是否成功即可查看平臺(tái)是否部署成功。

3 平臺(tái)可用性驗(yàn)證

3.1 智能合約驗(yàn)證

區(qū)塊鏈的應(yīng)用場(chǎng)景很多，依托于區(qū)塊鏈的加密特性以及智能合約的業(yè)務(wù)場(chǎng)景結(jié)合，在運(yùn)營(yíng)商領(lǐng)域，區(qū)塊鏈的核心應(yīng)用場(chǎng)景還是存證相關(guān)的業(yè)務(wù)，常見的場(chǎng)景如關(guān)聯(lián)交易業(yè)務(wù)、供應(yīng)鏈黑名單、供應(yīng)鏈協(xié)同存證等等。 為了支撐以上業(yè)務(wù)數(shù)據(jù)存證上鏈需求，需要開發(fā)相應(yīng)的智能合約函數(shù)，通過對(duì)智能合約的請(qǐng)求頻次統(tǒng)計(jì)發(fā)現(xiàn)，以下兩個(gè)智能合約接口調(diào)用最為頻繁，分別為：stub.PutState（args［0］，［］byte（args［1］）） ， stub.GetState（args［0］），其中前者實(shí)現(xiàn)了將數(shù)據(jù)以key－value 的形式存入狀態(tài)數(shù)據(jù)庫(kù)；后者可以通過key 值對(duì)數(shù)據(jù)進(jìn)行查詢，因此，通過對(duì)智能合約的讀、寫可以測(cè)試平臺(tái)的穩(wěn)定性，本文主要使用智能合約中最常用的存儲(chǔ)鍵值（putstate）和查詢鍵值（querystate）兩個(gè)函數(shù)進(jìn)行測(cè)試。

3.2 區(qū)塊落地策略配置

Fabric 的落地策略會(huì)對(duì)系統(tǒng)的性能產(chǎn)生一定的影響，落地策略主要包括4 個(gè)參數(shù)：BatchTimeout（出塊響應(yīng)時(shí)間），MaxMessageCount（區(qū)塊最大交易數(shù)），AbsoluteMaxBytes （ 區(qū) 塊 最 大 存 儲(chǔ) 量），PreferredMaxBytes（單筆最大交易數(shù)據(jù)量），本文在實(shí)驗(yàn)時(shí)，為了簡(jiǎn)化模型，盡量避免使用時(shí)間超時(shí)出塊策略的同時(shí)，多次調(diào)整參數(shù)后，統(tǒng)一采用響應(yīng)時(shí)間為2 s，最大交易數(shù)為100 筆，最大存儲(chǔ)量為99 MB，單筆最大交易512 KB 來進(jìn)行測(cè)試。

3.3 測(cè)試結(jié)果

為了模擬區(qū)塊鏈平臺(tái)實(shí)際使用時(shí)的情形，本文對(duì)不同的狀態(tài)數(shù)據(jù)庫(kù)進(jìn)行了壓力測(cè)試，通過不同數(shù)據(jù)量的情形分別測(cè)試，得到的結(jié)果如圖3、圖4 所示：隨著數(shù)據(jù)量的增加，請(qǐng)求時(shí)延有增加，但是并沒有出現(xiàn)超時(shí)的情形，CPU 的利用率也保持在合理的范圍內(nèi)，沒有出現(xiàn)異常情形，說明平臺(tái)穩(wěn)定運(yùn)行，滿足生產(chǎn)需求。

圖3 不同狀態(tài)數(shù)據(jù)庫(kù)批量讀寫平均請(qǐng)求時(shí)延曲線Fig. 3 The average request latency for batch reads and writes of two state databases during a single request

圖4 不同狀態(tài)數(shù)據(jù)庫(kù)批量讀寫－Peer 節(jié)點(diǎn)CPU 使用量變化曲線Fig. 4 CPU batch read－writing usage of Node Peer in different state databases

4 結(jié)束語

為了解決區(qū)塊鏈平臺(tái)的云部署問題，本文基于微服務(wù)拆分的方式提出了一種基于微服務(wù)的區(qū)塊鏈平臺(tái)快速云部署方法，解決了動(dòng)態(tài)資源擴(kuò)展復(fù)雜的問題，基于云環(huán)境的區(qū)塊鏈安全性更高。 經(jīng)驗(yàn)證，平臺(tái)性能穩(wěn)定，能滿足正常的生產(chǎn)需求。

區(qū)塊鏈的部署一直較為復(fù)雜，涉及到的節(jié)點(diǎn)交互情形較多，本文通過將容器服務(wù)鏡像直接進(jìn)行封裝，可以通過后續(xù)流水線的方式進(jìn)行一鍵部署，大大簡(jiǎn)化了原有的部署過程。 后續(xù)工作中，將更加關(guān)注區(qū)塊鏈平臺(tái)的應(yīng)用情形，將平臺(tái)推廣到更多的業(yè)務(wù)場(chǎng)景中去。