本文是在2018年11月15日由Linux基金會(huì)CNCF主辦的KubeCon & CloudNativeCon China 2018大會(huì)的“Running Blockchain as a Service (BaaS) on Kubernetes”演講內(nèi)容基礎(chǔ)上整理而成，從技術(shù)上介紹了阿里云如何將基于區(qū)塊鏈Hyperledger Fabric的BaaS和容器集群技術(shù)Kubernetes進(jìn)行結(jié)合的設(shè)計(jì)理念和實(shí)踐經(jīng)驗(yàn)分享。

大家好！我是來(lái)自于阿里云區(qū)塊鏈團(tuán)隊(duì)的余珊，今天給大家分享的是《在Kubernetes上運(yùn)行區(qū)塊鏈服務(wù)（BaaS）》這個(gè)主題。

以上是今天分享的內(nèi)容大綱，其中重點(diǎn)在第三部分，我們將對(duì)BaaS結(jié)合Kubernetes的一些典型問(wèn)題進(jìn)行深入探討。

首先我們分享一下在我們眼中的區(qū)塊鏈和BaaS的定義是什么。

從狹義上來(lái)說(shuō)，區(qū)塊鏈?zhǔn)且环N分布式共享賬本技術(shù)，基于智能合約，在各參與方之間達(dá)成對(duì)交易的共識(shí)，并實(shí)現(xiàn)賬本交易歷史的不可篡改。這個(gè)定義是大家所熟知的，并且是從技術(shù)和功能上進(jìn)行的概括。

而從廣義上來(lái)說(shuō)，我們認(rèn)為，區(qū)塊鏈也是一種在機(jī)構(gòu)、個(gè)人、機(jī)器之間，構(gòu)建分布式信任網(wǎng)絡(luò)、連接可信數(shù)據(jù)、實(shí)現(xiàn)價(jià)值流動(dòng)的新的架構(gòu)和協(xié)作模式。這也是跳出技術(shù)和功能維度，從更高維度去進(jìn)行的理解和總結(jié)。

對(duì)于另一個(gè)概念"BaaS"，即"Blockchain as a Service", 我們認(rèn)為，是云平臺(tái)之上的區(qū)塊鏈平臺(tái)服務(wù)，提供了區(qū)塊鏈系統(tǒng)的部署、運(yùn)維、治理能力，以及提供了區(qū)塊鏈應(yīng)用運(yùn)行和管理的能力。

區(qū)塊鏈從其類型上可分為私有鏈、公有鏈、聯(lián)盟鏈三種類型，而從系統(tǒng)拓?fù)渖衔覀兛梢詫⑵鋵?duì)應(yīng)為下述三種模式。對(duì)于傳統(tǒng)的中心化系統(tǒng)或私有鏈來(lái)說(shuō)，它基本屬于一種星型中心化系統(tǒng)。對(duì)于公有鏈來(lái)說(shuō)，是一種將所有參與企業(yè)和個(gè)人都對(duì)等連接在一起的完全去中心化系統(tǒng)。而對(duì)于聯(lián)盟鏈來(lái)說(shuō)，是一種帶分層結(jié)構(gòu)的多中心化系統(tǒng)。而阿里云今天主要關(guān)注的是面向企業(yè)場(chǎng)景的聯(lián)盟鏈技術(shù)類型。

下面我們來(lái)探討一下為什么將區(qū)塊鏈與容器技術(shù)以及Kubernetes進(jìn)行結(jié)合。

首先，我們來(lái)分析一下區(qū)塊鏈的特點(diǎn)。我們將其分為區(qū)塊鏈系統(tǒng)和區(qū)塊鏈業(yè)務(wù)應(yīng)用兩類。

• 區(qū)塊鏈系統(tǒng)是以數(shù)據(jù)為核心、高度分布式、Full-Mesh網(wǎng)絡(luò)拓?fù)洹ong-Running、復(fù)雜系統(tǒng)類型。

  • 數(shù)據(jù)為核心：其中最重要的是賬本上的數(shù)據(jù)。
  • 高度分布式：因?yàn)閰^(qū)塊鏈節(jié)點(diǎn)可能部署于不同機(jī)房、不同region、不同國(guó)家等等。
  • Full-Mesh: 區(qū)塊鏈節(jié)點(diǎn)之間要依賴全連通的網(wǎng)絡(luò)以實(shí)現(xiàn)共識(shí)、賬本同步等過(guò)程。
  • Long-Running：區(qū)塊鏈服務(wù)和節(jié)點(diǎn)是長(zhǎng)時(shí)間運(yùn)行，而不是像Web應(yīng)用或批處理任務(wù)那樣短生命周期的。
  • 復(fù)雜系統(tǒng)類型：區(qū)塊鏈系統(tǒng)不是一兩個(gè)模塊構(gòu)成的簡(jiǎn)單應(yīng)用，而是往往一整天解決方案或系統(tǒng)的形式。
• 區(qū)塊鏈業(yè)務(wù)應(yīng)用：沒有統(tǒng)一的標(biāo)準(zhǔn)，可能包含各種應(yīng)用類型，包括無(wú)狀態(tài)應(yīng)用、有狀態(tài)應(yīng)用、Web應(yīng)用、數(shù)據(jù)型應(yīng)用等等類型。

接下來(lái)，我們分析一下區(qū)塊鏈結(jié)合容器技術(shù)會(huì)帶來(lái)哪些優(yōu)勢(shì)：

• 容器技術(shù)為區(qū)塊鏈系統(tǒng)和業(yè)務(wù)應(yīng)用提供了標(biāo)準(zhǔn)化的軟件打包、分發(fā)的能力。
• 容器技術(shù)實(shí)現(xiàn)了區(qū)塊鏈運(yùn)行環(huán)境的一致性，以及與底層基礎(chǔ)架構(gòu)的解耦，使得區(qū)塊鏈系統(tǒng)和業(yè)務(wù)應(yīng)用可以很方便地移植和運(yùn)行在各種平臺(tái)之上。

進(jìn)一步的，我們發(fā)現(xiàn)，區(qū)塊鏈?zhǔn)褂肒ubernetes集群技術(shù)可獲得以下幾方面的優(yōu)勢(shì)：

• Kubernetes提供了靈活的區(qū)塊鏈所需要的底層資源的調(diào)度能力，如計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)等。
• Kubernetes強(qiáng)大的運(yùn)維管理能力，使得我們的區(qū)塊鏈服務(wù)的產(chǎn)品上線速度以及運(yùn)維的效率大大提升。
• Kubernetes支持各種應(yīng)用類型以及微服務(wù)架構(gòu)，因此對(duì)于上面區(qū)塊鏈系統(tǒng)和區(qū)塊鏈業(yè)務(wù)應(yīng)用各自的需求都能很好地滿足。
• 使用Kubernetes，可以更好地跟云平臺(tái)進(jìn)行集成，因?yàn)榻裉煸跇I(yè)界它已經(jīng)成為了各大云廠商云原生應(yīng)用的標(biāo)準(zhǔn)底座了。
• Kubernetes還提供了豐富的安全和隔離功能，這對(duì)我們區(qū)塊鏈的安全防護(hù)體系是很大的增強(qiáng)。
• 另外，圍繞Kubernetes有著非常活躍的社區(qū)和豐富的技術(shù)和業(yè)務(wù)生態(tài)，因此為結(jié)合區(qū)塊鏈的研發(fā)提供了強(qiáng)大的技術(shù)支持和資源。

這里解答圖中的一個(gè)疑問(wèn)，微服務(wù)架構(gòu)是否適合區(qū)塊鏈，這要結(jié)合上面的區(qū)塊鏈特點(diǎn)分析來(lái)看待：

• 對(duì)區(qū)塊鏈系統(tǒng)來(lái)說(shuō)，內(nèi)部組件之間是強(qiáng)耦合、強(qiáng)依賴的關(guān)系，比較難解耦，內(nèi)部各組件本身不是通用化的服務(wù)定位，也不是REST化服務(wù)接口，更多是例如gRPC調(diào)用，因此不是太適合微服務(wù)架構(gòu)。
• 但是對(duì)區(qū)塊鏈業(yè)務(wù)應(yīng)用來(lái)說(shuō)，則很適合考慮與微服務(wù)架構(gòu)進(jìn)行結(jié)合。

上面這幅圖展示了阿里云區(qū)塊鏈產(chǎn)品形態(tài)的演進(jìn)歷史，同時(shí)也可以看出我們?cè)趨^(qū)塊鏈結(jié)合容器以及Kubernetes方面所在的工作。

在2017年10月，我們開始提供基于容器服務(wù)的區(qū)塊鏈解決方案，支持Hyperledger Fabric，為企業(yè)提供一鍵式的區(qū)塊鏈自動(dòng)部署能力，當(dāng)時(shí)是基于Docker Swarm集群技術(shù)。緊接著在2017年12月，我們推出了支持Kubernetes的容器服務(wù)區(qū)塊鏈解決方案，并且在業(yè)界也是較早開始使用Helm Chart部署區(qū)塊鏈的。在今年7月底，我們正式推出了阿里云區(qū)塊鏈服務(wù)BaaS，支持Hyperledger Fabric，同樣也是基于Kubernetes。而在今年9月杭州云棲大會(huì)上，阿里云BaaS也正式支持了螞蟻區(qū)塊鏈，在這背后螞蟻區(qū)塊鏈也通過(guò)適配改造工作實(shí)現(xiàn)了在Kubernetes上的部署運(yùn)行。

這一頁(yè)展示的是阿里云BaaS的產(chǎn)品架構(gòu)大圖。其中最核心的是BaaS，目前已經(jīng)支持Hyperledger Fabric和螞蟻區(qū)塊鏈。它們的運(yùn)行實(shí)例底座都是基于阿里云容器服務(wù)Kubernetes集群。今天的演講內(nèi)容主要是圍繞Hyperledger Fabric跟Kubernetes結(jié)合這方面展開討論的。

上面這一頁(yè)展示了阿里云容器服務(wù)Kubernetes版的產(chǎn)品架構(gòu)圖。

這里我們展示了一套跨region的Hyperledger Fabric聯(lián)盟鏈的部署架構(gòu)圖。在聯(lián)盟管理方的Kubernetes集群上部署了Orderer organization和Peer Organization, 而在其他業(yè)務(wù)參與方所在region的Kubernetes上部署了各自的Peer Organization. 這里的CA、Peer、Orderer、Kafka、ZooKeeper的每個(gè)實(shí)例都是用了Kubernetes的Service和Deployment類型對(duì)象來(lái)定義。

此外區(qū)塊鏈的業(yè)務(wù)應(yīng)用可以部署在Kubernetes上或者其他環(huán)境上，通過(guò)SLB映射到集群worker節(jié)點(diǎn)的NodePort上，來(lái)訪問(wèn)區(qū)塊鏈的各個(gè)service。

接下來(lái)我們進(jìn)入重點(diǎn)的第三部分，對(duì)于實(shí)現(xiàn)BaaS運(yùn)行在Kubernetes的過(guò)程，我們?cè)?jīng)遇到的一些有代表性的問(wèn)題，以及我們的解決思路和實(shí)踐經(jīng)驗(yàn)。

首先是關(guān)于區(qū)塊鏈BaaS的打包、發(fā)布、服務(wù)編排等方面的問(wèn)題。

對(duì)于以Hyperledger Fabric為代表的區(qū)塊鏈系統(tǒng)來(lái)說(shuō)，這方面面臨的主要問(wèn)題是：區(qū)塊鏈系統(tǒng)本身較為復(fù)雜，在一套典型部署里可能涉及到三十多個(gè)容器、近二十個(gè)服務(wù)、十來(lái)個(gè)容器鏡像；而且這些服務(wù)相互之間有較強(qiáng)的依賴。

對(duì)于這個(gè)問(wèn)題，我們的解決思路是：

• 在打包部署方面，從一開始我們便選用了容器鏡像以及Kuberentes的Helm Chart作為標(biāo)準(zhǔn)的格式和工具。這里尤其提一下，為了保證聯(lián)盟鏈各組織創(chuàng)建的獨(dú)立性和靈活性，我們采用的是一類組織（例如Orderer Org或Peer Org）使用一套chart的方式。
• 在存儲(chǔ)庫(kù)管理方面，目前使用的是阿里云OSS作為Chart Repo（當(dāng)然可以使用功能更豐富的如ChartMuseum等工具），使用阿里云容器鏡像服務(wù)作為鏡像倉(cāng)庫(kù)。這里我們還采用了region化的鏡像倉(cāng)庫(kù)配置，加快大體積鏡像的下載速度，同時(shí)采用imagePullSecret保護(hù)鏡像的安全。
• 在配置方式方面，我們采用了Kubernetes的ConfigMap和Secrets來(lái)存儲(chǔ)主要的配置和安全信息，以及使用Chart Values來(lái)讓管控可以根據(jù)客戶的輸入去定制BaaS聯(lián)盟鏈實(shí)例。
• 在服務(wù)編排方面，為了滿足服務(wù)的依賴性需求，我們結(jié)合了Chart Template，Chart的Hook（鉤子）機(jī)制，以及Kubernetes的Init Container加上Shell腳本方式，實(shí)現(xiàn)各種服務(wù)尤其在啟動(dòng)過(guò)程中的依賴和順序保證。

對(duì)于企業(yè)來(lái)說(shuō)，業(yè)務(wù)系統(tǒng)的高可用性是非常重要的，尤其是對(duì)生產(chǎn)環(huán)境的系統(tǒng)運(yùn)行和應(yīng)用訪問(wèn)。這里我們分享一下在BaaS的每一個(gè)層面上的高可用設(shè)計(jì)思路，以及Kubernetes在其中起到怎樣的幫助。

首先在云基礎(chǔ)架構(gòu)和云資源服務(wù)層，我們通過(guò)云數(shù)據(jù)中心的多可用區(qū)、所依賴的云服務(wù)本身的高可用性和高可靠性來(lái)提供保障。

在BaaS管控層，通過(guò)管控組件的多實(shí)例化部署避免單點(diǎn)故障。

在容器服務(wù)的Kubernetes集群，采用3個(gè)master節(jié)點(diǎn)和多個(gè)worker節(jié)點(diǎn)的方式提供應(yīng)用底座的高可用。

在Hyperledger Fabric這一層，它的Orderer、Peer、Kafka、ZooKeeper、CA等類型節(jié)點(diǎn)均有集群或高可用互備的設(shè)計(jì)，比如任一節(jié)點(diǎn)掛掉的話，其他節(jié)點(diǎn)依然能正常提供服務(wù)。但這里有一個(gè)關(guān)鍵的點(diǎn)，就是在Kubernetes集群上部署的時(shí)候，為了避免這些本應(yīng)高可用互備的Fabric節(jié)點(diǎn)的pod被調(diào)度到同一個(gè)worker node上，我們采用了Kubernetes Pod Anti-Affinity的功能區(qū)將高可用集群的pod調(diào)度到不同的worker上，這樣保證了真正高可用的部署，提高了對(duì)故障的容忍度。

在區(qū)塊鏈業(yè)務(wù)應(yīng)用層，則需要各個(gè)企業(yè)客戶對(duì)應(yīng)用進(jìn)行周全的高可用設(shè)計(jì)和實(shí)現(xiàn)。在運(yùn)行時(shí)，應(yīng)用訪問(wèn)Fabric各個(gè)服務(wù)的這一環(huán)節(jié)，我們BaaS內(nèi)置了云平臺(tái)的SLB負(fù)載均衡能力（包含對(duì)服務(wù)端口的健康檢查），以及Fabric的Service Discovery，來(lái)保證即使后端部分節(jié)點(diǎn)或服務(wù)不可用時(shí)，應(yīng)用的調(diào)用鏈路都會(huì)被調(diào)度到可用的節(jié)點(diǎn)或服務(wù)上。

下面我們談?wù)凚aaS數(shù)據(jù)持久化存儲(chǔ)的問(wèn)題。雖然上面已經(jīng)介紹了BaaS的高可用性設(shè)計(jì)，但我們?nèi)孕杩紤]如何將鏈上賬本數(shù)據(jù)、區(qū)塊鏈關(guān)鍵配置等重要內(nèi)容持久化保存到可靠的外部存儲(chǔ)而不是容器內(nèi)部，這樣便可以在服務(wù)器節(jié)點(diǎn)全部發(fā)生故障，或者系統(tǒng)重啟、備份恢復(fù)等場(chǎng)合依然可以實(shí)現(xiàn)對(duì)系統(tǒng)和數(shù)據(jù)的恢復(fù)。

首先，作為背景，我們分析了如果使用本地盤方式可能存在的問(wèn)題：

• Kubernetes本身對(duì)pod的調(diào)度默認(rèn)并沒有限定worker節(jié)點(diǎn)，因此如果使用本地盤，就會(huì)因?yàn)樵谥貑⒒蚧謴?fù)過(guò)程中調(diào)度導(dǎo)致的pod漂移而無(wú)法讀取原來(lái)worker節(jié)點(diǎn)上的本地盤。
• 對(duì)于第一個(gè)問(wèn)題，Kubernetes提供了NodeSelector的機(jī)制可以讓pod可以綁定worker節(jié)點(diǎn)進(jìn)行部署，不會(huì)調(diào)度到其他worker節(jié)點(diǎn)上，這樣就可以保證能始終訪問(wèn)到一個(gè)本地盤。但這又帶來(lái)另一個(gè)問(wèn)題，即在容災(zāi)的場(chǎng)景，如果這個(gè)節(jié)點(diǎn)包括其本地盤受到損壞無(wú)法恢復(fù)時(shí)，會(huì)導(dǎo)致整個(gè)pod也無(wú)法恢復(fù)。

因此，我們?cè)谠O(shè)計(jì)BaaS中的選擇是阿里云的NAS文件系統(tǒng)存儲(chǔ)、以及阿里云的云盤。在數(shù)據(jù)可靠性方面，NAS和云盤可以分別提供99.999999999%和99.9999999%的數(shù)據(jù)可靠性。此外，我們都選用了SSD類型以保證I/O性能。

在Kubernetes部署的時(shí)候，Fabric的節(jié)點(diǎn)通過(guò)Persistent Volume和Persistent Volume Claim掛載上相應(yīng)的存儲(chǔ)，并且這些存儲(chǔ)是為每一個(gè)Fabric的業(yè)務(wù)organization獨(dú)立分配的，保證了業(yè)務(wù)數(shù)據(jù)的隔離性。

在和參加KubeCon大會(huì)的一些區(qū)塊鏈用戶交流的時(shí)候，有朋友提到隨著賬本數(shù)據(jù)的持續(xù)增長(zhǎng)，可以怎樣解決存儲(chǔ)問(wèn)題。在我們的實(shí)踐中，我們發(fā)現(xiàn)阿里云的NAS有一些很適合區(qū)塊鏈賬本存儲(chǔ)的一些特點(diǎn)：

• 首先，阿里云NAS可提供存儲(chǔ)容量動(dòng)態(tài)無(wú)縫擴(kuò)容，在這過(guò)程中Fabric節(jié)點(diǎn)或區(qū)塊鏈業(yè)務(wù)應(yīng)用均無(wú)需重啟或停機(jī)，對(duì)存儲(chǔ)擴(kuò)容過(guò)程完全無(wú)感知。
• 其次，有用戶擔(dān)心隨著存儲(chǔ)數(shù)據(jù)量的增大，存儲(chǔ)的性能是否會(huì)明顯下降。恰恰相反的是，在阿里云NAS隨著所使用的數(shù)據(jù)量變得越大，NAS所提供的吞吐性能會(huì)變得更高，這樣可以打消企業(yè)用戶在長(zhǎng)期生產(chǎn)運(yùn)行方面的顧慮。

在上圖的右邊是Fabric不同類型的區(qū)塊鏈節(jié)點(diǎn)使用不同類型存儲(chǔ)的一個(gè)示意圖。

接下來(lái)我們探討一下在設(shè)計(jì)搭建BaaS聯(lián)盟鏈跨企業(yè)的網(wǎng)絡(luò)方面遇到的挑戰(zhàn)。

對(duì)于大多數(shù)區(qū)塊鏈技術(shù)而言，包括Hyerpedger Fabric, 在網(wǎng)絡(luò)上要求區(qū)塊鏈節(jié)點(diǎn)之間形成Full Mesh全連通網(wǎng)絡(luò)，以實(shí)現(xiàn)節(jié)點(diǎn)間的賬本數(shù)據(jù)同步、區(qū)塊廣播、節(jié)點(diǎn)發(fā)現(xiàn)、交易背書等過(guò)程，同時(shí)企業(yè)也要求保障跨企業(yè)鏈路的安全性。對(duì)于這些需求，我們梳理了業(yè)界目前常見的幾類解決方案如下，并進(jìn)一步分析它們存在的一些不足之處。

方案一是采用單一VPC的聯(lián)盟鏈網(wǎng)絡(luò)方案，在這種模式下，聯(lián)盟鏈的所有區(qū)塊鏈節(jié)點(diǎn)均被部署到一套Kubernetes集群網(wǎng)絡(luò)或VPC內(nèi)。這種方案實(shí)質(zhì)上是一種私有鏈的模式，失去了聯(lián)盟鏈的各方自治的價(jià)值。

方案二是基于公網(wǎng)的聯(lián)盟鏈網(wǎng)絡(luò)方案，區(qū)塊鏈節(jié)點(diǎn)分布式部署在不同區(qū)域，通過(guò)公網(wǎng)IP對(duì)外提供服務(wù)以及實(shí)現(xiàn)互相通信。這種方案可以較靈活、較低成本低滿足大多數(shù)基本需求，但對(duì)于高級(jí)需求如企業(yè)級(jí)安全網(wǎng)絡(luò)則不能很好地滿足。

方案三是基于專線互聯(lián)的聯(lián)盟鏈網(wǎng)絡(luò)方案，它采用運(yùn)營(yíng)商專線方式將不同網(wǎng)絡(luò)或數(shù)據(jù)中心進(jìn)行兩兩互聯(lián)，在業(yè)界一些企業(yè)中得到了采用。但這里面主要存在兩方面的問(wèn)題，首先是如果聯(lián)盟鏈參與企業(yè)采用了不同電信運(yùn)營(yíng)商的專線方案的話，項(xiàng)目實(shí)施的復(fù)雜性和成本都會(huì)很高；其次，如果幾家企業(yè)已經(jīng)建好了這樣一個(gè)聯(lián)盟網(wǎng)絡(luò)，對(duì)于新來(lái)的參與企業(yè)，它的接入復(fù)雜度和成本也是一個(gè)不小的問(wèn)題。

針對(duì)上述各種問(wèn)題，我們?cè)诎⒗镌艬aaS基礎(chǔ)之上，結(jié)合了CEN云企業(yè)網(wǎng)，提供了一種安全的聯(lián)盟鏈網(wǎng)絡(luò)方案，主要面向高端需求的企業(yè)用戶。

方案的核心，是采用CEN云企業(yè)網(wǎng)打通不同企業(yè)的VPC網(wǎng)絡(luò)，就像一張跨企業(yè)的環(huán)網(wǎng)，這樣不同企業(yè)不同的VPC內(nèi)的網(wǎng)絡(luò)就可以在CEN內(nèi)實(shí)現(xiàn)全連通。

在實(shí)現(xiàn)網(wǎng)絡(luò)連通之后，因?yàn)榘⒗镌艬aaS聯(lián)盟鏈中的Peer，Orderer，CA等服務(wù)是通過(guò)域名來(lái)訪問(wèn)的，目的是提升應(yīng)用訪問(wèn)的靈活性，而在CEN的這套方案中，我們可以結(jié)合云解析PrivateZone，來(lái)實(shí)現(xiàn)企業(yè)環(huán)網(wǎng)內(nèi)各企業(yè)VPC之間的統(tǒng)一域名解析。而且上述的網(wǎng)絡(luò)連通性和域名解析僅限于聯(lián)盟內(nèi)部，不會(huì)暴露到外網(wǎng)。

除了在公共云環(huán)境之外，對(duì)于那些將區(qū)塊鏈節(jié)點(diǎn)部署于本地IDC的企業(yè)來(lái)說(shuō)，他們也可以通過(guò)VPN或者專線方式，接入到云上已和CEN打通的任一VPC中，便可實(shí)現(xiàn)和聯(lián)盟任意節(jié)點(diǎn)的通信。

作為一個(gè)小提醒，在方案實(shí)施環(huán)節(jié)，需要注意提前規(guī)劃好不同VPC內(nèi)的內(nèi)網(wǎng)地址分配，避免在環(huán)網(wǎng)中發(fā)生沖突。

這樣我們便形成了一套真正跨企業(yè)、跨賬戶，打通各個(gè)VPC的安全聯(lián)盟鏈網(wǎng)絡(luò)方案。

下面我們將探討一個(gè)非常有挑戰(zhàn)性的問(wèn)題。眾所周知，智能合約是區(qū)塊鏈的一個(gè)核心。Hyperledger Fabric中的智能合約即chaincode是運(yùn)行于容器當(dāng)中。在上面這幅圖里我們總結(jié)了Hyperledger Fabric的chaincode容器生成過(guò)程的示意圖：

Peer通過(guò)Docker Client發(fā)起對(duì)Docker Daemon的調(diào)用，以fabric-ccenv為基礎(chǔ)鏡像創(chuàng)建出一個(gè)chaincode構(gòu)建容器（chaincode builder container）

Peer將chaincode源代碼傳入chaincode構(gòu)建容器，在里面完成智能合約編譯

Peer再調(diào)用Docker Daemon創(chuàng)建以fabric-baseos為基礎(chǔ)鏡像的chaincode鏡像，并將在第2步編譯好的chaincode二進(jìn)制文件內(nèi)置在chaincode鏡像中。

啟動(dòng)運(yùn)行chaincode容器。

從上述過(guò)程我們分析一下這里面存在的一些問(wèn)題：

• 由于該過(guò)程是獨(dú)立于Kubernetes體系之外運(yùn)行的，難以對(duì)chaincode容器進(jìn)行生命周期管理。
• 無(wú)法基于Kubernetes的namaspace隔離、NetworkPolicy等機(jī)制實(shí)現(xiàn)對(duì)chaincode容器的安全管理。

針對(duì)上面分析發(fā)現(xiàn)的問(wèn)題，我們研究了幾種問(wèn)題解決的思路。

第一種思路，是將chaincode容器納入到Kubernete的體系（如pod）進(jìn)行管理。

這在我們的角度看來(lái)，其實(shí)是最理想的方案。因?yàn)樗粌H可以實(shí)現(xiàn)chaincode容器全生命周期與Fabric其他類型節(jié)點(diǎn)一致的管理方式，并且可以結(jié)合Kubernetes的NetowrkPolicy控制chaincode容器的網(wǎng)絡(luò)訪問(wèn)策略。

其實(shí)此前Hyperledger Fabric社區(qū)已經(jīng)創(chuàng)建了一個(gè)相關(guān)的需求即JIRA（FAB-7406），但目前仍未實(shí)現(xiàn)。

假設(shè)未來(lái)在此功能實(shí)現(xiàn)之后，我們進(jìn)一步展望一下，還可以將智能合約的容器調(diào)度運(yùn)行于Serverless Kubernetes之上，提供kernal級(jí)別的隔離，保證應(yīng)用容器之間的安全隔離。

第二種思路，如社區(qū)和網(wǎng)上的一些觀點(diǎn)所提到的，將chaincode容器放入Docker-in-Docker（DIND）環(huán)境運(yùn)行。

這個(gè)思路背后的出發(fā)點(diǎn)，主要是為了降低對(duì)宿主機(jī)Docker Daemon的依賴以及動(dòng)態(tài)生成chaincode鏡像和容器的不可管理性。

對(duì)于這個(gè)思路，我們也基于Hyperledger Fabric和Kubernetes進(jìn)行了試驗(yàn)，在右邊的這部分Kubernetes部署模板yaml代碼里，綠色框的部分是用于配置DIND的容器作為peer pod的一個(gè)sidecar，同時(shí)將DIND容器內(nèi)的Docker Daemon通過(guò)本地端口2375以環(huán)境變量的形式配置到peer的參數(shù)中，使得peer可以將chaincode創(chuàng)建相關(guān)請(qǐng)求發(fā)送到DIND內(nèi)。

通過(guò)對(duì)結(jié)果的觀察和分析，我們發(fā)現(xiàn)了以下這幾點(diǎn)。

DIND的思路有如下一些優(yōu)點(diǎn)：

無(wú)需依賴宿主節(jié)點(diǎn)的/var/run/docker.sock。

無(wú)需專門清理每個(gè)Kubernetes worker節(jié)點(diǎn)的chaincode鏡像。

但DIND有著一些更為明顯的不足：

每次創(chuàng)建部署或恢復(fù)peer節(jié)點(diǎn)會(huì)變得很慢，因?yàn)镈IND內(nèi)需要去拉取fabric-ccenv鏡像，其大小約1.4GB；而如果用傳統(tǒng)部署方式的話，只需在worker節(jié)點(diǎn)拉取一次鏡像即可。

Chaincode的實(shí)例化（instantiate）過(guò)程稍微變慢，推測(cè)這和DIND容器本身運(yùn)行所需的開銷有一定關(guān)系。

當(dāng)peer節(jié)點(diǎn)或者整個(gè)組織（organization）刪掉重建之后（復(fù)用原有的數(shù)據(jù)目錄），啟動(dòng)速度比起傳統(tǒng)方式會(huì)慢很多，這背后的原因和第1點(diǎn)相同。

在業(yè)界實(shí)踐中，DIND方法主要用于CI/CD的場(chǎng)景，但對(duì)于生產(chǎn)環(huán)境使用的話，則在穩(wěn)定性等方面仍有較多的挑戰(zhàn)。

DIND的思路仍然不能解決chaincode容器的安全訪問(wèn)控制和隔離的問(wèn)題。

第三種思路，是我們目前在BaaS中采用的方法，即綜合各種配置的手段先解決最主要的問(wèn)題。這包括以下幾個(gè)方面的工作：

首先，通過(guò)Fabric peer的合理配置（如圖中右上角的示例配置）保證chaincode和peer的通信。

其次，使用docker rm和docker rmi命令清理chaincode容器和鏡像（它們均包含“dev-”前綴）。這里面有不同的可選位置。
2.1 適合事后清理的可選位置是采用DaemonSet結(jié)合lifecycle.preStop.exec.command的位置來(lái)運(yùn)行這些清理命令。

2.2 適合事前清理的可選位置是在initContainer中運(yùn)行上述清理命令。

采用iptables規(guī)則，對(duì)chaincode容器進(jìn)行網(wǎng)絡(luò)隔離。主要是通過(guò)在Helm Chart安裝階段配置Kubernetes worker節(jié)點(diǎn)的iptables規(guī)則，實(shí)現(xiàn)限制chaincode容器對(duì)Kubernetes網(wǎng)絡(luò)和對(duì)外部網(wǎng)絡(luò)的訪問(wèn)（同時(shí)也可以限制進(jìn)入chaincode容器的網(wǎng)絡(luò)訪問(wèn)）。

通過(guò)上述一系列手段，我們得到了對(duì)chaincode容器實(shí)現(xiàn)生命周期管理、安全隔離和網(wǎng)絡(luò)訪問(wèn)限制的一個(gè)實(shí)用的方案。未來(lái)我們也會(huì)繼續(xù)朝著思路一這種最理想方式進(jìn)行更多的探索。

今天阿里巴巴集團(tuán)的區(qū)塊鏈已經(jīng)在多個(gè)行業(yè)、多種場(chǎng)景實(shí)現(xiàn)了結(jié)合以及業(yè)務(wù)落地，包含了如商品溯源、數(shù)字內(nèi)容版權(quán)、供應(yīng)鏈金融、數(shù)據(jù)資產(chǎn)共享、公益慈善、醫(yī)療處方等等。我們的客戶在生產(chǎn)環(huán)境已經(jīng)達(dá)到了百萬(wàn)級(jí)的交易規(guī)模以及百GB的賬本數(shù)據(jù)，這也為我們提供了很豐富的區(qū)塊鏈應(yīng)用實(shí)踐經(jīng)驗(yàn)。

基于這些實(shí)踐，我們想跟大家分享的是，其實(shí)區(qū)塊鏈應(yīng)用設(shè)計(jì)開發(fā)并不復(fù)雜，這一頁(yè)總結(jié)了構(gòu)建于Kubernete之上的區(qū)塊鏈系統(tǒng)和應(yīng)用的基本模式。可以看到，Kubernetes幫我們解決了底層基礎(chǔ)架構(gòu)和資源的復(fù)雜性，提供了應(yīng)用的標(biāo)準(zhǔn)底座；而區(qū)塊鏈服務(wù)BaaS則幫我們解決了區(qū)塊鏈系統(tǒng)配置部署和運(yùn)維的復(fù)雜性，提供了統(tǒng)一的接口，那么對(duì)企業(yè)來(lái)說(shuō)，便可以聚焦在業(yè)務(wù)流程和業(yè)務(wù)邏輯的實(shí)現(xiàn)，及業(yè)務(wù)應(yīng)用的開發(fā)上，以及與業(yè)務(wù)數(shù)據(jù)的交互和管理上來(lái)，實(shí)現(xiàn)核心價(jià)值的最大化。

下面，我們將進(jìn)行阿里云BaaS Hyperledger Fabric的一個(gè)demo，主要展示一下幾方面的過(guò)程：

• 首先，快速創(chuàng)建跨企業(yè)（跨賬號(hào)）、跨region的聯(lián)盟鏈。
• 接著，動(dòng)態(tài)添加新組織、新通道，完成企業(yè)間協(xié)同，包括邀請(qǐng)企業(yè)，以及企業(yè)各自的審批流程。
• 在一些關(guān)鍵操作點(diǎn)上，BaaS內(nèi)置了風(fēng)控保障，強(qiáng)制邀請(qǐng)短信驗(yàn)證才允許完成操作，這看似麻煩的環(huán)節(jié)實(shí)際上是企業(yè)對(duì)生產(chǎn)安全保障以及審計(jì)都非常看重和需要的。
• 最后，我們?cè)贐aaS上部署了經(jīng)典的Marbles虛擬數(shù)字資產(chǎn)交易的應(yīng)用，包含chaincode的部署和client SDK應(yīng)用的部署。

視頻

最后，歡迎有興趣的朋友進(jìn)一步了解和使用阿里云的區(qū)塊鏈服務(wù)BaaS，通過(guò)掃描圖中的兩個(gè)二維碼可快速訪問(wèn)相關(guān)產(chǎn)品主頁(yè)，申請(qǐng)開通免費(fèi)公測(cè)試用，以及訪問(wèn)產(chǎn)品文檔獲得更多使用和開發(fā)指南。

以上就是我今天跟大家分享的全部?jī)?nèi)容，謝謝大家！

?

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的在Kubernetes上运行区块链服务（BaaS）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。