基于Kubernetes的Fabric鏈碼管理及高可用技術

劉宏宇，梁秀波，吳俊涵

（浙江大學軟件學院，浙江寧波 315048）

0 引言

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

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

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

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

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

1 相關技術

1.1 BaaS核心技術

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

表1 主要公有云的BaaS平臺Tab.1 BaaS platforms for major public clouds

1.2 Hyperledger Fabric

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

1.3 Kubernetes容器編排技術

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

1.4 Serverless Function技術

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

2 核心系統(tǒng)概要設計

2.1 系統(tǒng)功能

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

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

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

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

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

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

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

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

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

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

2.3 系統(tǒng)流程

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

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

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

3.1 高可用架構(gòu)設計

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

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

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

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

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

3.2 Fabric靜態(tài)組件部署設計

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

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

CA 是Fabric 提供信任的基礎，主要提供簽發(fā)、管理證書以及身份識別等功能。CA 是一個C/S 架構(gòu)的服務，Server 端可以實現(xiàn)高可用擴展，但是必須共享存儲以統(tǒng)一管理身份證書信息。Orderer是Fabric的核心，也是最為復雜的組件之一。Fabric 的插件化設計支持多種算法，Orderer 是實現(xiàn)插件化共識的基本框架。Peer 節(jié)點是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）五種分別完成通道配置、鏈碼生命周期管理、交易查詢、交易背書、交易驗證等功能。

3.3 Fabric鏈碼部署設計

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

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

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

鏈碼部署管理的改造涉及客戶端部分：Peer 服務端實現(xiàn)了多種鏈碼容器管理插件，部署鏈碼時需要客戶端指明使用哪一個插件。Peer客戶端提供解析配置文件的形式確定鏈碼部署環(huán)境，具體是客戶端配置文件的vm.type 參數(shù)?？蛻舳藢㈡湸a使用的虛擬執(zhí)行環(huán)境類型存儲在了CDS（ChaincodeDeploymentSpec）結(jié)構(gòu)中，而CDS 是在鏈碼安裝時確定的，所以還需要在鏈碼安裝部分加上對Kubernetes 的支持。鏈碼部分的改造實現(xiàn)擬全部封裝在k8sontroller 包中，除了K8sDockerVM 接口的實現(xiàn)外，還有如表3 所示的一些Kubernetes 客戶端接口的封裝實現(xiàn)。這些函數(shù)完成鏈碼部署時的相關資源的創(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ù)區(qū)塊鏈和函數(shù)計算服務的相似性，鏈碼是Fabric 上基于函數(shù)計算改造最具潛力的組件。Fabric 中一筆交易的完成需要多數(shù)節(jié)點達成共識，并落到區(qū)塊中，部分鏈碼容器失效并不影響區(qū)塊鏈整體網(wǎng)絡。當有新的交易需要執(zhí)行計算時，F(xiàn)abric 會再次拉起容器。Fabric 的這項能力為實現(xiàn)鏈碼容器函數(shù)計算化管理提供了可能。Fabric 鏈碼是一個只提供計算服務的組件，它的所有數(shù)據(jù)均來自于Peer服務，這種特性滿足函數(shù)計算服務對代碼無狀態(tài)性的要求。Fabric 鏈碼的生命周期如圖7 所示，完成鏈碼調(diào)用任務需要依次經(jīng)歷鏈碼安裝、實例化的過程。Peer 服務端的鏈碼容器在實例化后一直處于Running狀態(tài)等待調(diào)用，只有在鏈碼升級或者鏈碼本身內(nèi)部錯誤才會結(jié)束鏈碼容器。而函數(shù)計算服務管理鏈碼，首先要做的就是改變鏈碼的生命周期，要求鏈碼容器在調(diào)用時再實例化啟動，調(diào)用結(jié)束即退出。

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

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

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

圖8 鏈碼啟動簡化流程Fig.8 Simplified flowchart of chaincode activation

3.5 鏈碼性能測試

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

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

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

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

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

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

4 結(jié)語

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

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

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