劉宏宇，梁秀波，吳俊涵

（浙江大學(xué)軟件學(xué)院，浙江寧波 315048）

0 引言

區(qū)塊鏈即服務(wù)（Blockchain as a Service，BaaS）是一種創(chuàng)建、管理和運(yùn)維企業(yè)級(jí)區(qū)塊鏈網(wǎng)絡(luò)及應(yīng)用的云服務(wù)平臺(tái)，它可以為開發(fā)者提供便捷、高性能的區(qū)塊鏈服務(wù)，并降低開發(fā)成本［1］。按照云計(jì)算服務(wù)的劃分，BaaS 有平臺(tái)即服務(wù)（Platform as a Service，PaaS）和軟件即服務(wù)（Software as a Service，SaaS）兩種形態(tài)，目前絕大多數(shù)以PaaS 為主，對(duì)外提供一種打包封裝好的區(qū)塊鏈技術(shù)平臺(tái)［2］。BaaS平臺(tái)的發(fā)展需要云計(jì)算和區(qū)塊鏈兩個(gè)方向的技術(shù)能力，具有較高的技術(shù)門檻，云計(jì)算巨頭公司提供了大多數(shù)的BaaS平臺(tái)。

IBM 在2016 年2 月宣布推出區(qū)塊鏈服務(wù)平臺(tái)，支持用戶通過Bluemix 的區(qū)塊鏈服務(wù)完成創(chuàng)建、部署、運(yùn)行和監(jiān)控區(qū)塊鏈應(yīng)用程序的任務(wù)；微軟在2016 年8 月正式開放其Azure 云平臺(tái)的BaaS 服務(wù)，支持多種區(qū)塊鏈網(wǎng)絡(luò)（Hyperledger Fabric、Ethereum、Corda 等），提供快速構(gòu)建、管理和擴(kuò)展區(qū)塊鏈網(wǎng)絡(luò)的能力，Azure用戶可以專注于業(yè)務(wù)開發(fā)，實(shí)現(xiàn)高效上鏈；AWS（Amazon Web Services）在2018 年4 月，發(fā)布了區(qū)塊鏈模板服務(wù)，AWS用戶可以選擇Ethereum、Hyperledger Fabric 等常見的開源框架，快速創(chuàng)建和部署區(qū)塊鏈網(wǎng)絡(luò)［3-4］。

中國(guó)互聯(lián)網(wǎng)公司先后推出BaaS 平臺(tái)：2017 年4 月，騰訊發(fā)布了區(qū)塊鏈白皮書和自主研發(fā)的TrustSQL 區(qū)塊鏈平臺(tái)；2018年2月，華為云推出BCS（BlockChain Service）區(qū)塊鏈解決方案，旨在通過與人工智能（Artificial Intelligence，AI）、物聯(lián)網(wǎng)（Internet of Things，IoT）、5G 等前沿技術(shù)的結(jié)合構(gòu)建一個(gè)堅(jiān)實(shí)的技術(shù)底座，使能各行業(yè)數(shù)字化高效轉(zhuǎn)型；2018 年7 月，阿里云商業(yè)產(chǎn)品區(qū)塊鏈服務(wù)（公測(cè)）發(fā)布，該服務(wù)可以幫助用戶快速構(gòu)建穩(wěn)定、安全的生產(chǎn)級(jí)區(qū)塊鏈網(wǎng)絡(luò)，減少在區(qū)塊鏈部署、運(yùn)維、開發(fā)等方面的挑戰(zhàn)，讓用戶專注于核心業(yè)務(wù)創(chuàng)新，實(shí)現(xiàn)快速上鏈；2018 年8 月，京東區(qū)塊鏈開放平臺(tái)正式發(fā)布，該平臺(tái)可以幫助客戶快速構(gòu)建、管理和使用區(qū)塊鏈應(yīng)用［5-6］。

幾乎所有的云計(jì)算巨頭及區(qū)塊鏈創(chuàng)業(yè)公司都提供了BaaS 平臺(tái)，但當(dāng)前的平臺(tái)有一個(gè)顯著的同質(zhì)化的問題，產(chǎn)品功能甚至底層實(shí)現(xiàn)方案大同小異，沒有明顯的差異化。事實(shí)上，大多數(shù)的云計(jì)算公司只是簡(jiǎn)單地提供了一種開源區(qū)塊鏈平臺(tái)的一鍵化部署管理方案，沒有深入到區(qū)塊鏈技術(shù)的底層，而區(qū)塊鏈公司關(guān)注更多的是區(qū)塊鏈技術(shù)本身，這就導(dǎo)致目前的BaaS底層仍有許多改進(jìn)和優(yōu)化的地方。另外，BaaS研發(fā)的門檻較高，只有大型公司和高收入的公司有能力負(fù)擔(dān)，無論國(guó)內(nèi)外，BaaS 幾乎都是由商業(yè)巨頭把控，行業(yè)的馬太效應(yīng)明顯［7］。商業(yè)BaaS 平臺(tái)雖然提供了對(duì)開源區(qū)塊鏈平臺(tái)的支持，但BaaS 本身是閉源的，對(duì)于BaaS 發(fā)展和需要構(gòu)建自己私有BaaS平臺(tái)的企業(yè)來說都是不友好的。

針對(duì)上述問題，本文選擇基于開源的Hyperledger Fabric聯(lián)盟鏈和Kubernetes容器編排技術(shù)研究構(gòu)建BaaS的底層核心技術(shù)，通過對(duì)Fabric 源代碼的解析和改造更好地適配Kubernetes。此外學(xué)術(shù)界和產(chǎn)業(yè)界也在積極探索Serverless Function 新技術(shù)和區(qū)塊鏈的融合應(yīng)用［8-9］，本文跟蹤了相關(guān)內(nèi)容，并提出一種基于函數(shù)計(jì)算思想改造Fabric 的BaaS 平臺(tái)方案。

1 相關(guān)技術(shù)

1.1 BaaS核心技術(shù)

BaaS 實(shí)質(zhì)上是一種利用各種云計(jì)算技術(shù)打包封裝指定區(qū)塊鏈平臺(tái)并對(duì)外提供一鍵部署和管理區(qū)塊鏈能力的云服務(wù)。BaaS有PaaS和SaaS兩種類型，PaaS提供部署指定區(qū)塊鏈平臺(tái)的能力，SaaS 則可以直接提供某種類型的區(qū)塊鏈應(yīng)用服務(wù)［10-11］。PaaS 類型的區(qū)塊鏈服務(wù)是業(yè)界當(dāng)前主流的區(qū)塊鏈云化方案。在區(qū)塊鏈服務(wù)層，本文調(diào)研了一些主流云計(jì)算公司的BaaS平臺(tái)對(duì)區(qū)塊鏈的支持情況，詳細(xì)情況如表1所示。

表1 主要公有云的BaaS平臺(tái)Tab.1 BaaS platforms for major public clouds

1.2 Hyperledger Fabric

Hyperledger Fabric（簡(jiǎn)稱Fabric）是一個(gè)帶有準(zhǔn)入機(jī)制的企業(yè)級(jí)聯(lián)盟鏈項(xiàng)目，它的前身是IBM 的OpenBlockchain 項(xiàng)目。目前Fabric 已經(jīng)成為企業(yè)區(qū)塊鏈平臺(tái)的典范，也是絕大多數(shù)廠商構(gòu)建BaaS 平臺(tái)的首要選擇。Fabric 是一種許可網(wǎng)絡(luò)，而不是在沒有身份的公共網(wǎng)絡(luò)中建立分散的信任；Fabric 各參與方可以僅僅將需要共享的數(shù)據(jù)分享給他人，實(shí)現(xiàn)保密交易；Fabric 采用可插拔的架構(gòu)設(shè)計(jì)，各行各業(yè)可以針對(duì)特定需求量身定制各種插件［12］。

1.3 Kubernetes容器編排技術(shù)

Kubernetes 是一個(gè)用于自動(dòng)部署、擴(kuò)展和管理容器的開源平臺(tái)，吸收了Borg 系統(tǒng)的許多功能特性［13］。Kubernetes 字面意思為“舵手”，其圖標(biāo)對(duì)應(yīng)為一個(gè)方向舵，另外Kubernetes單詞中間有8 個(gè)字母故也簡(jiǎn)稱K8s。Google 在大規(guī)模工作負(fù)載的運(yùn)維管理上經(jīng)歷十幾年先后構(gòu)建了Borg、Omega 以及Kubernetes 等系統(tǒng)，并在2014 年開源了Kubernetes 系統(tǒng)。2017 年Docker 公司宣布在其核心產(chǎn)品中內(nèi)置Kubernetes 服務(wù)，2018年Kubernetes 和容器成為所有云廠商的既定標(biāo)準(zhǔn)，以“云”為核心的軟件研發(fā)思想逐步形成［14］。

1.4 Serverless Function技術(shù)

Serverless 本意是指一種不需要專門服務(wù)器的技術(shù)，例如對(duì)等網(wǎng)絡(luò)（Peer-to-Peer，P2P）無需設(shè)置服務(wù)器，因?yàn)槊總€(gè)節(jié)點(diǎn)既是服務(wù)器又是客戶端；但在云環(huán)境下Serverless 已經(jīng)轉(zhuǎn)變?yōu)橐环N開發(fā)人員不必關(guān)心服務(wù)器的設(shè)計(jì)思想、架構(gòu)模式［15］。Serverless 有兩種類型：1）后端即服務(wù)（Backend as a Service，BaaS），主要是指承載數(shù)據(jù)存儲(chǔ)的服務(wù)，例如消息隊(duì)列、內(nèi)容分發(fā)網(wǎng)絡(luò)、云對(duì)象存儲(chǔ)等；2）函數(shù)即服務(wù)（Function as a Service，F(xiàn)aaS），是指一種將用戶自定義代碼運(yùn)行在無狀態(tài)的計(jì)算容器中并由事件觸發(fā)的計(jì)算服務(wù)［16］。

2 核心系統(tǒng)概要設(shè)計(jì)

2.1 系統(tǒng)功能

基于相關(guān)技術(shù)需求，設(shè)計(jì)了核心系統(tǒng)的相關(guān)功能，如表2所示。系統(tǒng)功能主要分為底層云計(jì)算平臺(tái)、Fabric 靜態(tài)組件部署管理、動(dòng)態(tài)組件鏈碼部署管理以及基于函數(shù)計(jì)算思想改造鏈碼管理幾個(gè)項(xiàng)目，每個(gè)項(xiàng)目下又劃分了若干個(gè)功能點(diǎn)。

底層云計(jì)算平臺(tái)是區(qū)塊鏈網(wǎng)絡(luò)的實(shí)際運(yùn)行環(huán)境，它提供了計(jì)算、存儲(chǔ)等資源。計(jì)算資源主要由Kubernetes 平臺(tái)管理，存儲(chǔ)資源由分布式文件系統(tǒng)提供。作為底層支撐平臺(tái)，它必須滿足高可用的特性，保證在部分節(jié)點(diǎn)失效的情況下仍可有效提供服務(wù)，并能通過一定的運(yùn)維手段恢復(fù)失效節(jié)點(diǎn)。上層區(qū)塊鏈平臺(tái)數(shù)據(jù)不斷增長(zhǎng)的存儲(chǔ)需求，要求底層的存儲(chǔ)資源能夠動(dòng)態(tài)擴(kuò)展，本文使用分布式文件系統(tǒng)管理存儲(chǔ)資源，通過增加存儲(chǔ)設(shè)備實(shí)現(xiàn)存儲(chǔ)資源的在線擴(kuò)展。存儲(chǔ)資源管理系統(tǒng)獨(dú)立于容器計(jì)算平臺(tái)，這使得底層平臺(tái)還要為Kubernetes 提供一個(gè)存儲(chǔ)接入的功能，從而方便地為上層業(yè)務(wù)提供持久化存儲(chǔ)。

BaaS 平臺(tái)一個(gè)基本的要求就是將區(qū)塊鏈平臺(tái)部署在云計(jì)算平臺(tái)上。Fabric 組件根據(jù)不同的啟動(dòng)時(shí)間，可以分為靜態(tài)組件和動(dòng)態(tài)組件兩部分。靜態(tài)組件指的是證書頒發(fā)機(jī)構(gòu)（Certificate Authority，CA）、Peer、Orderer以及共識(shí)算法所依賴的外部組件，這些組件隨區(qū)塊鏈網(wǎng)絡(luò)的啟動(dòng)而啟動(dòng)。Fabric動(dòng)態(tài)組件鏈碼和其他組件的不同點(diǎn)在于它是通過實(shí)例化命令啟動(dòng)的。Fabric 項(xiàng)目提供了Docker-Compose 的部署樣例，只需做適當(dāng)修改即可將靜態(tài)組件部署到Kubernetes 上。在實(shí)驗(yàn)環(huán)境中，鏈碼和Peer服務(wù)部署在同一個(gè)宿主機(jī)上，鏈碼鏡像的編譯、存儲(chǔ)在同一個(gè)Docker 服務(wù)中，可以方便地安裝與實(shí)例化鏈碼。但是在云計(jì)算環(huán)境下，鏈碼可能會(huì)被調(diào)度到不同的計(jì)算節(jié)點(diǎn)上，所以跨節(jié)點(diǎn)實(shí)例化鏈碼需要構(gòu)建鏈碼鏡像的分發(fā)能力，實(shí)現(xiàn)鏈碼鏡像從Peer 節(jié)點(diǎn)到部署節(jié)點(diǎn)的傳輸。最后一個(gè)項(xiàng)目仍是針對(duì)鏈碼的，鏈碼的函數(shù)計(jì)算改造，主要涉及對(duì)Fabric 鏈碼原有生命周期的改造，使其在調(diào)用前啟動(dòng)容器，調(diào)用完成即退出，讓出計(jì)算資源。

表2 核心系統(tǒng)功能Tab.2 Core system functions

2.2 系統(tǒng)架構(gòu)

BaaS 底層的區(qū)塊鏈平臺(tái)云化管理，可以分為云計(jì)算和區(qū)塊鏈兩層結(jié)構(gòu)。本文所涉及的核心系統(tǒng)同樣可以分為兩層，底層為高可用Kubernetes 平臺(tái)和分布式文件系統(tǒng)，上層為Fabric區(qū)塊鏈平臺(tái)，系統(tǒng)架構(gòu)如圖1所示。

底層高可用Kubernetes 系統(tǒng)是上層業(yè)務(wù)的托管平臺(tái)，承載了上層所有的服務(wù)壓力。作為一個(gè)容器管理平臺(tái)，Kubernetes要為上層Fabric提供高效的容器編排管理能力，將應(yīng)用組件合理地分散到計(jì)算集群中健康的節(jié)點(diǎn)上。Kubernetes 具有高效的服務(wù)治理能力，利用系統(tǒng)提供的應(yīng)用容器健康檢測(cè)功能，可以選擇相關(guān)策略自動(dòng)恢復(fù)失效組件。憑借這些能力，開發(fā)者可以在Kubernetes 平臺(tái)上很方便地實(shí)施Fabric相關(guān)組件的高可用管理。同時(shí)，Kubernetes的高可用也保證了在部分控制節(jié)點(diǎn)失效的情況下，仍能提供容器編排能力，確保上層服務(wù)的可靠運(yùn)行。

區(qū)塊鏈網(wǎng)絡(luò)層位于高可用Kubernetes 平臺(tái)之上，這一層完成區(qū)塊鏈所有的業(yè)務(wù)邏輯。Fabric 有靜態(tài)組件和動(dòng)態(tài)鏈碼兩部分：靜態(tài)是指相關(guān)組件在部署網(wǎng)絡(luò)時(shí)啟動(dòng)；動(dòng)態(tài)主要指鏈碼在區(qū)塊鏈業(yè)務(wù)運(yùn)行階段實(shí)例化時(shí)啟動(dòng)。動(dòng)態(tài)和靜態(tài)的劃分，關(guān)系到Fabric網(wǎng)絡(luò)在Kubernetes上的部署設(shè)計(jì)。在鏈碼管理上，該架構(gòu)增加了函數(shù)計(jì)算管理模塊，改造后的鏈碼容器共享計(jì)算節(jié)點(diǎn)，調(diào)用任務(wù)結(jié)束立即退出容器，讓出計(jì)算資源。

該架構(gòu)上還有一個(gè)獨(dú)立于Kubernetes 計(jì)算集群的分布式文件系統(tǒng)（Distributed File System，DFS）集群。以HDFS（Hadoop Distributed File System）為例介紹外部存儲(chǔ)。HDFS是一個(gè)分布式文件系統(tǒng)，它提供一種高可靠的、可動(dòng)態(tài)擴(kuò)展的數(shù)據(jù)存儲(chǔ)能力。HDFS 接入到Kubernetes 系統(tǒng)，可以為上層的區(qū)塊鏈服務(wù)提供可動(dòng)態(tài)擴(kuò)展存儲(chǔ)空間的持久化存儲(chǔ)服務(wù)。Fabric的賬本數(shù)據(jù)最終存儲(chǔ)在了可靠的分布式文件系統(tǒng)上。

圖1 BaaS底層架構(gòu)Fig.1 BaaS underlying architecture

2.3 系統(tǒng)流程

本文在鏈碼部署管理上引入了函數(shù)計(jì)算思想，改變了鏈碼容器原有的生命周期，部署流程如圖2 所示。引入函數(shù)計(jì)算的系統(tǒng)在鏈碼實(shí)例化消息發(fā)出后，F(xiàn)abric 靜態(tài)組件Peer 會(huì)完成鏈碼容器鏡像的編譯，并將鏡像上傳到存儲(chǔ)中心，但不會(huì)啟動(dòng)鏈碼容器。函數(shù)計(jì)算下的鏈碼容器是按需啟動(dòng)的，在區(qū)塊鏈系統(tǒng)發(fā)起一筆交易產(chǎn)生鏈碼調(diào)用時(shí)，才會(huì)觸發(fā)鏈碼容器的啟動(dòng)。鏈碼容器在完成計(jì)算返回結(jié)果后，會(huì)立即結(jié)束其生命周期讓出計(jì)算資源。

圖2 引入函數(shù)計(jì)算的Fabric鏈碼部署流程Fig.2 Fabric chaincode deployment process with function calculation

3 核心系統(tǒng)具體實(shí)現(xiàn)

3.1 高可用架構(gòu)設(shè)計(jì)

Kubernetes 分為Master 和Node（Slave）兩個(gè)部分，其中Node 的高可用由系統(tǒng)本身完成，保證將Pod 調(diào)度到健康的工作節(jié)點(diǎn)上。Kubernetes高可用主要是指Master組件的高可用。本文所設(shè)計(jì)的高可用架構(gòu)如圖3 所示，可以發(fā)現(xiàn)集群外還增加了一個(gè)高可用負(fù)載均衡器，這個(gè)均衡器主要承擔(dān)Apiserver的高可用任務(wù)。整個(gè)架構(gòu)按照集群內(nèi)外分為兩部分：集群內(nèi)多Master節(jié)點(diǎn)的高可用和集群外基于主備切換的負(fù)載均衡器高可用。Kubernetes 上Kubelet 是通過Systemctl 服務(wù)管理的，除它之外所有組件都可以直接部署在Kubernetes 上，本文借用這種能力來設(shè)計(jì)Kubernetes的高可用方案。

Master 節(jié)點(diǎn)上的Etcd 組件本身就是一個(gè)基于Raft 協(xié)議的高可用分布式鍵值數(shù)據(jù)庫(kù)，只需為它配置多個(gè)實(shí)例即可。Master 上的其他組件，根據(jù)有無狀態(tài)分為兩種部署方案：無狀態(tài)組件Apiserver 采用“多實(shí)例+負(fù)載均衡器”的高可用設(shè)計(jì)；有狀態(tài)組件Scheduler 和ControllerManager 采用“多實(shí)例+競(jìng)爭(zhēng)鎖”的高可用設(shè)計(jì)。集群外的負(fù)載均衡器采用“虛擬IP+雙節(jié)點(diǎn)”的主備設(shè)計(jì)，保證主代理服務(wù)失效后備份服務(wù)器能夠立刻提供服務(wù)。同時(shí)負(fù)載均衡器還應(yīng)具備主動(dòng)健康檢測(cè)功能，保證將流量分配到健康的服務(wù)上。

圖3 Kubernetes高可用架構(gòu)Fig.3 High availability architecture for Kubernetes

圖3 中的Apiserver 高可用依賴一個(gè)外部高可用負(fù)載均衡器，本節(jié)基于虛擬IP、Keepalived、Nginx 等技術(shù)設(shè)計(jì)了一種雙節(jié)點(diǎn)主備自動(dòng)切換高可用負(fù)載均衡器，系統(tǒng)架構(gòu)如圖4 所示。每臺(tái)物理服務(wù)器上都需要安裝Keepalived 和Nginx 服務(wù)。主備服務(wù)器上Keepalived需要配置物理網(wǎng)卡、虛擬IP、state、認(rèn)證信息及優(yōu)先級(jí)，其中主服務(wù)器的state設(shè)置為MASTER，備份服務(wù)器設(shè)置為BACKUP。Keepalived 和虛擬IP 完成Nginx 主備切換的高可用，Keepalived基于虛擬路由冗余協(xié)議實(shí)現(xiàn)了虛擬IP 和服務(wù)器的自動(dòng)綁定，初始狀態(tài)主節(jié)點(diǎn)綁定虛擬IP 提供服務(wù)。主節(jié)點(diǎn)失效，虛擬IP 會(huì)自動(dòng)漂移到備份服務(wù)器，此時(shí)由備份節(jié)點(diǎn)提供服務(wù)。負(fù)載均衡器還需要主動(dòng)探測(cè)代理的Apiserver 健康狀態(tài)，保證將流量轉(zhuǎn)發(fā)到可用的服務(wù)上。官方版本的Nginx 提供被動(dòng)健康檢測(cè)方法，即目標(biāo)服務(wù)異常，下次將流量分配到其他服務(wù)上，后端Apiserver 異常，仍有機(jī)會(huì)被Nginx 轉(zhuǎn)發(fā)過來流量。本文基于ngx_healthcheck_module 插件為Nginx 提供了主動(dòng)健康檢測(cè)能力，保證將流量分配到健康的Apiserver上。

圖4 高可用負(fù)載均衡器架構(gòu)Fig.4 High-availability load balancer architecture

3.2 Fabric靜態(tài)組件部署設(shè)計(jì)

Fabric 區(qū)塊鏈平臺(tái)是一個(gè)復(fù)雜的分布式系統(tǒng)，云化部署復(fù)雜度較高。本文將Fabric 的組件分為了靜態(tài)和動(dòng)態(tài)兩種，靜態(tài)組件如CA、Orderer、Peer 等構(gòu)成了分布式系統(tǒng)的主要的基本框架。靜態(tài)組件在Fabric 網(wǎng)絡(luò)部署時(shí)就可以啟動(dòng)完畢（不包括運(yùn)行中動(dòng)態(tài)加入節(jié)點(diǎn)）。圖5 描述了一個(gè)具備兩個(gè)組織的部署架構(gòu)，該架構(gòu)中Fabric 所有組件部署在Kubernetes上，所有資源通過Kubernetes 進(jìn)行管理。圖5 中的O1 代表Orderer1。

圖5 Fabric云化部署架構(gòu)Fig.5 Fabric cloudification deployment architecture

CA 是Fabric 提供信任的基礎(chǔ)，主要提供簽發(fā)、管理證書以及身份識(shí)別等功能。CA 是一個(gè)C/S 架構(gòu)的服務(wù)，Server 端可以實(shí)現(xiàn)高可用擴(kuò)展，但是必須共享存儲(chǔ)以統(tǒng)一管理身份證書信息。Orderer是Fabric的核心，也是最為復(fù)雜的組件之一。Fabric 的插件化設(shè)計(jì)支持多種算法，Orderer 是實(shí)現(xiàn)插件化共識(shí)的基本框架。Peer 節(jié)點(diǎn)是Fabric 執(zhí)行交易和賬本管理的組件。交易執(zhí)行意味著鏈碼管理，F(xiàn)abric 系統(tǒng)存在系統(tǒng)鏈碼和用戶鏈碼兩種類型，系統(tǒng)鏈碼有CSCC（Configuration System ChainCode）、LSCC（Lifestyle System ChainCode）、QSCC（Querier System ChainCode）、ESCC（Endorser System ChainCode）、VSCC（Validator System ChainCode）五種分別完成通道配置、鏈碼生命周期管理、交易查詢、交易背書、交易驗(yàn)證等功能。

3.3 Fabric鏈碼部署設(shè)計(jì)

鏈碼是區(qū)塊鏈的核心，也是整個(gè)部署方案中最具挑戰(zhàn)性的地方。將鏈碼納入到Kubernetes 的環(huán)境中是最理想的部署方案，但社區(qū)和業(yè)界的方案均沒有實(shí)現(xiàn)這一點(diǎn)，這主要是因?yàn)镕abric 的代碼本身沒有對(duì)這塊內(nèi)容的支持。本節(jié)所要介紹的部署方案就是要通過解構(gòu)、二次開發(fā)Fabric 代碼將鏈碼納入Kubernetes環(huán)境。

Peer 服務(wù)在鏈碼管理上完成了鏈碼安裝、Docker 鏡像編譯、創(chuàng)建容器、啟動(dòng)容器以及健康檢測(cè)等工作。原生Peer 服務(wù)，啟動(dòng)時(shí)要指定好Docker Daemon 服務(wù)地址，隨后鏈碼實(shí)例化過程的鏡像編譯和創(chuàng)建均在同一個(gè)宿主機(jī)上進(jìn)行，但是Kubernetes 是一個(gè)分布式的計(jì)算集群，鏈碼容器會(huì)被調(diào)度到不同的節(jié)點(diǎn)上，也就是獲得部署鏈碼容器任務(wù)的宿主機(jī)可能沒有鏈碼鏡像。通過鏈碼鏡像編譯和容器創(chuàng)建分離，鏡像編譯仍在Peer服務(wù)綁定的Docker Daemon中進(jìn)行，然后再將鏡像分發(fā)到執(zhí)行創(chuàng)建任務(wù)的節(jié)點(diǎn)上。

集群內(nèi)鏡像分發(fā)可以構(gòu)建一個(gè)鏡像倉(cāng)庫(kù)實(shí)現(xiàn)，高可用鏡像倉(cāng)庫(kù)采用的Harbor 的主從復(fù)制模式構(gòu)建，同時(shí)為了降低集群內(nèi)的網(wǎng)絡(luò)帶寬占用和提高鏡像分發(fā)速度，基于Dragonfly 構(gòu)建P2P鏡像下載加速器，相較于原生方式，可將容器分發(fā)速度提高57 倍，網(wǎng)絡(luò)出口流量降低99.5%［17］。引入鏡像倉(cāng)庫(kù)后，Peer和部署節(jié)點(diǎn)之間增加了向倉(cāng)庫(kù)Push和Pull鏡像的兩步操作，完整的工作流如圖6 所示。原生Peer 通過Docker SDK 向Docker Daemon 發(fā)起鏡像編譯和創(chuàng)建容器的任務(wù)，現(xiàn)在鏈碼實(shí)例化分為鏡像編譯和創(chuàng)建兩個(gè)過程：鏡像編譯仍通過Peer 完成，但是要將鏡像Push 到集群內(nèi)的鏡像倉(cāng)庫(kù)；容器創(chuàng)建，則需要在Peer 中集成Kubernetes 的SDK 完成容器的部署，獲得部署任務(wù)的工作節(jié)點(diǎn)從遠(yuǎn)程倉(cāng)庫(kù)拉取鏈碼鏡像并創(chuàng)建鏈碼實(shí)例。

鏈碼部署管理的改造涉及客戶端部分：Peer 服務(wù)端實(shí)現(xiàn)了多種鏈碼容器管理插件，部署鏈碼時(shí)需要客戶端指明使用哪一個(gè)插件。Peer客戶端提供解析配置文件的形式確定鏈碼部署環(huán)境，具體是客戶端配置文件的vm.type 參數(shù)?？蛻舳藢㈡湸a使用的虛擬執(zhí)行環(huán)境類型存儲(chǔ)在了CDS（ChaincodeDeploymentSpec）結(jié)構(gòu)中，而CDS 是在鏈碼安裝時(shí)確定的，所以還需要在鏈碼安裝部分加上對(duì)Kubernetes 的支持。鏈碼部分的改造實(shí)現(xiàn)擬全部封裝在k8sontroller 包中，除了K8sDockerVM 接口的實(shí)現(xiàn)外，還有如表3 所示的一些Kubernetes 客戶端接口的封裝實(shí)現(xiàn)。這些函數(shù)完成鏈碼部署時(shí)的相關(guān)資源的創(chuàng)建。

圖6 Kubernetes環(huán)境中鏈碼部署流Fig.6 Chaincode deployment flow in Kubernetes environment

表3 K8sDockerVM中的K8s接口Tab.3 K8s interfaces in K8sDockerVM

3.4 函數(shù)計(jì)算管理鏈碼設(shè)計(jì)

根據(jù)區(qū)塊鏈和函數(shù)計(jì)算服務(wù)的相似性，鏈碼是Fabric 上基于函數(shù)計(jì)算改造最具潛力的組件。Fabric 中一筆交易的完成需要多數(shù)節(jié)點(diǎn)達(dá)成共識(shí)，并落到區(qū)塊中，部分鏈碼容器失效并不影響區(qū)塊鏈整體網(wǎng)絡(luò)。當(dāng)有新的交易需要執(zhí)行計(jì)算時(shí)，F(xiàn)abric 會(huì)再次拉起容器。Fabric 的這項(xiàng)能力為實(shí)現(xiàn)鏈碼容器函數(shù)計(jì)算化管理提供了可能。Fabric 鏈碼是一個(gè)只提供計(jì)算服務(wù)的組件，它的所有數(shù)據(jù)均來自于Peer服務(wù)，這種特性滿足函數(shù)計(jì)算服務(wù)對(duì)代碼無狀態(tài)性的要求。Fabric 鏈碼的生命周期如圖7 所示，完成鏈碼調(diào)用任務(wù)需要依次經(jīng)歷鏈碼安裝、實(shí)例化的過程。Peer 服務(wù)端的鏈碼容器在實(shí)例化后一直處于Running狀態(tài)等待調(diào)用，只有在鏈碼升級(jí)或者鏈碼本身內(nèi)部錯(cuò)誤才會(huì)結(jié)束鏈碼容器。而函數(shù)計(jì)算服務(wù)管理鏈碼，首先要做的就是改變鏈碼的生命周期，要求鏈碼容器在調(diào)用時(shí)再實(shí)例化啟動(dòng)，調(diào)用結(jié)束即退出。

無論函數(shù)計(jì)算服務(wù)還是區(qū)塊鏈服務(wù)，部署用戶代碼都需要解決代碼的編譯問題。Fabric 鏈碼的編譯是一個(gè)復(fù)雜的過程，不能像函數(shù)計(jì)算服務(wù)一樣提前準(zhǔn)備好代碼和依賴包直接上傳，目前業(yè)界或者社區(qū)的函數(shù)計(jì)算服務(wù)無法完成Fabric 鏈碼的編譯。鑒于實(shí)際情況，本文采用模擬函數(shù)計(jì)算服務(wù)的方法進(jìn)行實(shí)驗(yàn)。函數(shù)計(jì)算服務(wù)的用戶代碼部署可以分為鏡像編譯、分發(fā)、部署等過程，以Knative 函數(shù)計(jì)算服務(wù)為例，用戶代碼被編譯成Docker 鏡像存儲(chǔ)在遠(yuǎn)程鏡像倉(cāng)庫(kù)中，事件觸發(fā)計(jì)算節(jié)點(diǎn)從倉(cāng)庫(kù)中拉取鏡像并啟動(dòng)實(shí)例，完成任務(wù)后退出。Fabric Peer 本身具備鏈碼鏡像的編譯能力，本文設(shè)計(jì)的Kubernetes 部署方案也完成了集群內(nèi)鏈碼鏡像的分發(fā)，所以只需改造鏈碼實(shí)例的調(diào)度任務(wù)即可。

圖7 Fabric 鏈碼的生命周期Fig.7 Fabric chaincode lifecycle

通過在CDS 結(jié)構(gòu)中增加了Serverless 字段和在Chaincode Install 子命令下增加serverless bool 全局參數(shù)，實(shí)現(xiàn)改變鏈碼容器的運(yùn)行模式和完成調(diào)度任務(wù)。引入Serverless 參數(shù)的鏈碼啟動(dòng)流程如圖8 所示。引入Serverless 的鏈碼調(diào)用，會(huì)增加單次鏈碼調(diào)用的處理時(shí)間，但它在空閑時(shí)讓出了計(jì)算資源，可以極大地提高資源的利用率，多租戶網(wǎng)絡(luò)共享計(jì)算池可以顯著降低區(qū)塊鏈的部署運(yùn)維費(fèi)用，降低用戶上鏈的費(fèi)用門檻，同時(shí)計(jì)算資源池對(duì)用戶是透明的，共享資源的同時(shí)又保證了數(shù)據(jù)隱私性。

圖8 鏈碼啟動(dòng)簡(jiǎn)化流程Fig.8 Simplified flowchart of chaincode activation

3.5 鏈碼性能測(cè)試

Kubernetes 環(huán)境和普通Docker 環(huán)境中鏈碼在鏡像管理和運(yùn)行環(huán)境方面存在區(qū)別。本節(jié)通過相同任務(wù)量下任務(wù)完成時(shí)間的長(zhǎng)短來評(píng)估改造后的鏈碼調(diào)用性能，測(cè)試基準(zhǔn)為基于Docker 運(yùn)行環(huán)境的鏈碼完成時(shí)間，測(cè)試環(huán)境為雙組織單節(jié)點(diǎn)部署環(huán)境，共識(shí)采用Solo算法。

測(cè)試方案通過腳本封裝鏈碼調(diào)用，通過參數(shù)指定調(diào)用次數(shù)，并輸出調(diào)用開始和結(jié)束的時(shí)間，每項(xiàng)測(cè)試5 次，并求取平均值，實(shí)驗(yàn)結(jié)果如表4～5所示。根據(jù)兩個(gè)表中的數(shù)據(jù)，可以看出Docker和Kubernetes環(huán)境下，Kubernetes部署的鏈碼調(diào)用性能跟Docker 鏈碼相近。此外，統(tǒng)計(jì)了Docker 和Kubernetes 鏈碼在100 次調(diào)用下成功調(diào)用次數(shù)的平均值分別為18.4 和19.0，兩者調(diào)用的成功率也相近。為了不影響記時(shí)，測(cè)試腳本并未進(jìn)行Sleep操作等待區(qū)塊鏈網(wǎng)絡(luò)數(shù)據(jù)的同步，所以鏈碼調(diào)用的成功率普遍低一些。

表4 Docker鏈碼調(diào)用時(shí)間測(cè)試 單位：sTab.4 Docker chaincode call time test unit：s

表5 Kubernetes鏈碼調(diào)用時(shí)間測(cè)試 單位：sTab.5 Kubernetes chaincode call time test unit：s

此外，也對(duì)Serverless 模式下的鏈碼進(jìn)行了測(cè)試，測(cè)試結(jié)果如表6 所示。函數(shù)計(jì)算有一個(gè)明顯的特點(diǎn)是冷啟動(dòng)時(shí)間較長(zhǎng)，在這種模式下，鏈碼在有調(diào)用需求時(shí)才會(huì)啟動(dòng)容鏈碼容器的創(chuàng)建、啟動(dòng)花費(fèi)了較長(zhǎng)的時(shí)間。Serverless 鏈碼調(diào)用時(shí)間較長(zhǎng)，為區(qū)塊鏈數(shù)據(jù)同步提供了比較充足的時(shí)間，實(shí)驗(yàn)測(cè)得鏈碼調(diào)用成功率要比Docker和Kubernetes高，100次調(diào)用下成功調(diào)用次數(shù)的平均值為68.8。

表6 Serverless鏈碼調(diào)用時(shí)間測(cè)試 單位：sTab.6 Serverless chaincode call time test unit：s

4 結(jié)語(yǔ)

基于業(yè)界典型的BaaS 方案，本文選擇了Fabric 和Kubernetes 兩項(xiàng)基本技術(shù)研究BaaS 的底層實(shí)現(xiàn)。在Kubernetes 方面，主要研究底層技術(shù)設(shè)施的高可用性；在Fabric 方面，主要研究基于高可用Kubernetes 的云化部署技術(shù)。

Fabric 鏈碼的部署管理是本文研究的核心之一，也是Fabric 云化部署方案中最復(fù)雜的一部分。現(xiàn)有的鏈碼管理技術(shù)均沒有將鏈碼納入Kubernetes 環(huán)境中。本文通過對(duì)Fabric Peer的二次開發(fā)，通過新增一個(gè)K8sDockerVM 控制器插件，實(shí)現(xiàn)了對(duì)Kubernetes 在代碼級(jí)別上的支持。此外，本文也通過函數(shù)計(jì)算思想對(duì)鏈碼運(yùn)行機(jī)制進(jìn)行了一個(gè)創(chuàng)新嘗試，實(shí)現(xiàn)了鏈碼實(shí)例執(zhí)行模式的改變，將實(shí)例化后鏈碼容器常駐等待調(diào)用改變?yōu)橛姓{(diào)用需求時(shí)啟動(dòng)。

函數(shù)計(jì)算引入?yún)^(qū)塊鏈網(wǎng)絡(luò)，可以為它帶來幾個(gè)能力：鏈碼高度彈性部署，鏈碼按需部署，用完即釋放資源，可以為用戶大幅降低費(fèi)用。但函數(shù)計(jì)算服務(wù)的冷啟動(dòng)時(shí)間較長(zhǎng)，由Serverless 鏈碼調(diào)用性能測(cè)試結(jié)果也可以看到，調(diào)用時(shí)間比常規(guī)部署方式的鏈碼調(diào)用要久。對(duì)區(qū)塊鏈網(wǎng)絡(luò)來說，混合部署模式可能更加合適：高頻應(yīng)用，鏈碼常駐提供高效的服務(wù)；低頻應(yīng)用，按Serverless 模式部署，按需調(diào)用降低費(fèi)用。混合部署及高頻、低頻應(yīng)用區(qū)分方案是接下來區(qū)塊鏈云化部署的研究方向。