作者 | 余珊

本文根據(jù) QCon 北京 2018 站上的演講整理而成，原題《區(qū)塊鏈 Hyperledger Fabric 的落地挑戰(zhàn)與阿里云探索經(jīng)驗(yàn)分享》。

這是今天的主題大綱，我們開始先會回顧一下區(qū)塊鏈的概念技術(shù)和業(yè)務(wù)，我們會探討一下區(qū)塊鏈在企業(yè)場景落地的一些關(guān)鍵考慮的問題，下面也會介紹一下我們阿里云推出區(qū)塊鏈的一些相關(guān)的工具。最后的話，我們會做一些重點(diǎn)分享，我們在區(qū)塊鏈落地，從規(guī)劃、運(yùn)維、到應(yīng)用這方面去分享我們的一些探索經(jīng)驗(yàn)。

首先我們先回顧一下區(qū)塊鏈的基本概念，最近一兩年大家無論主動或被動的已經(jīng)受到了很多區(qū)塊鏈技術(shù)和業(yè)務(wù)科普的洗禮。 首先，區(qū)塊鏈?zhǔn)鞘裁?？它是一種分布式共享賬本技術(shù)，在參與區(qū)塊鏈網(wǎng)絡(luò)的交易各方以及監(jiān)管方可以共享賬本，這個(gè)賬本有這樣一個(gè)特性，一旦交易經(jīng)過各方的確認(rèn)，交易的數(shù)據(jù)就不可實(shí)現(xiàn)任何的更改。第二，交易歷史是全程可以回溯的，交易信息里面涉及到些商業(yè)機(jī)密，交易方的身份等等都得到隱私的保護(hù)，交易本身是通過智能合約 Smart Contract 去自動執(zhí)行的。

區(qū)塊鏈的類型有很多，公有鏈、私有鏈、聯(lián)盟鏈等等，在阿里云這邊，我們的工作更多是關(guān)注聯(lián)盟鏈這種類型。區(qū)塊鏈本身不是一個(gè)全新的技術(shù)，它是基于一些業(yè)界已有的關(guān)鍵技術(shù)去構(gòu)成的一套體系，包括比如基于拜占庭等共識算法。還有基于密碼學(xué)的一些技術(shù)基礎(chǔ)，像非對稱密鑰、數(shù)字簽名等等技術(shù)。此外，它本質(zhì)是一個(gè)分布式系統(tǒng)架構(gòu)，所以會涉及到一些分布式計(jì)算如高可用，水平擴(kuò)展，Gossip 通訊協(xié)議等等一些技術(shù)。

區(qū)塊鏈要解決的核心問題，是在缺乏信任基礎(chǔ)的商業(yè)環(huán)境下，各方如何來進(jìn)行交易和協(xié)作的問題。大家看到有很多講區(qū)塊鏈價(jià)值，比如說提升了協(xié)作效率，降低了時(shí)間成本，提升了信息透明度等等，根源都在于我們?nèi)狈π湃我约盎蛐湃味炔蛔愕那闆r下，在傳統(tǒng)模式引入的各種冗余的流程、冗余的模式、中介機(jī)構(gòu)所導(dǎo)致的。同時(shí)區(qū)塊鏈也會帶來像去中心化 / 多中心化這樣的結(jié)果，但是去中心化不是區(qū)塊鏈的目的，真正目的是要解決跨企業(yè)的信任問題。

其實(shí)業(yè)界在區(qū)塊鏈的實(shí)現(xiàn)技術(shù)上有很豐富的類型，這列舉了一些影響力比較大的主流技術(shù)。其中一個(gè)在開源界影響比較大的是 Linux 基金會 Hyperledger 這樣一個(gè)傘形項(xiàng)目，下面包含了很多區(qū)塊鏈技術(shù)實(shí)現(xiàn)以及一些工具。其中獲得最廣泛采用的是 Hyperledger Fabric 這個(gè)項(xiàng)目，項(xiàng)目初期是由 IBM 和 DAH 一起貢獻(xiàn)的源代碼，現(xiàn)在全球參與的項(xiàng)目成員數(shù)量已經(jīng)是非常多了，其次還有 Sawtooth，Iroha 等等。

其他的實(shí)現(xiàn)技術(shù)還有以太坊，以太坊早期是從以太幣發(fā)展起來的，那么現(xiàn)在也有一些面向商業(yè)場景以及聯(lián)盟鏈的分支技術(shù)。還有像 R3 Corda，R3 Corda 是面向金融場景開發(fā)的一種區(qū)塊鏈技術(shù)，與之相比， Hyperledger Fabric 更多是面向通用行業(yè)、通用業(yè)務(wù)場景的。此外還有各個(gè)廠商自研的區(qū)塊鏈技術(shù)，例如阿里這邊有螞蟻金服自研的螞蟻區(qū)塊鏈技術(shù)。

這一頁大概總結(jié)一下在 Hyperledger Fabric 的發(fā)展過程中它的架構(gòu)演進(jìn)的過程，在 Hyperledger Fabric v0.6 采用的是左圖這樣一種架構(gòu)體系。它跟很多廠商自研的區(qū)塊鏈技術(shù)是一種類似的架構(gòu)，它主要由 Peer 節(jié)點(diǎn)構(gòu)成，Peer 上面保存了賬本，賬本在不同 Peer 之間會共享以及同步復(fù)制，Peer 上面也會運(yùn)行共識算法以及智能合約。后來 Hyperledger Fabric 從 1.0 開始采用了一種新的架構(gòu)，它的優(yōu)勢是可以實(shí)現(xiàn)架構(gòu)的水平擴(kuò)展和解耦，它的共識算法可以實(shí)現(xiàn)可插拔的模式，來解決傳統(tǒng)比如拜占庭共識算法帶來的節(jié)點(diǎn)數(shù)要在一開始就固定好，后期無法動態(tài)擴(kuò)展這些問題。

區(qū)塊鏈的業(yè)務(wù)應(yīng)用場景非常的豐富，相信大家在國內(nèi)外也看到了很多落地的案例，這里我也大概列舉了一些。比如說公益慈善、信用證、資產(chǎn)證券化、資產(chǎn)托管等等，我也會介紹一下在一些重點(diǎn)的場景上面，區(qū)塊鏈的價(jià)值以及面臨的挑戰(zhàn)是什么。

比如說在商品溯源這個(gè)場景，區(qū)塊鏈實(shí)現(xiàn)的是商品從出廠到中間經(jīng)過物流、倉儲、經(jīng)銷商、零售、電商平臺，再到消費(fèi)者，這個(gè)過程中它的產(chǎn)品溯源信息的不可篡改的特性。但是在這業(yè)務(wù)場景落地有一個(gè)很關(guān)鍵的挑戰(zhàn)，雖然區(qū)塊鏈實(shí)現(xiàn)了鏈上數(shù)據(jù)的不可篡改，但也要解決實(shí)體商品本身如何跟區(qū)塊鏈上的數(shù)據(jù)做一個(gè)可信的關(guān)聯(lián)。因?yàn)槲覀円苊獬霈F(xiàn)標(biāo)簽是真的，區(qū)塊鏈溯源數(shù)據(jù)都是真的，但是實(shí)體商品是假的。這個(gè)環(huán)節(jié)不是區(qū)塊鏈就可以把它全部解決，我們還要結(jié)合像防偽技術(shù)等等，去形成更完整的溯源方案。

在數(shù)字內(nèi)容版權(quán)這個(gè)領(lǐng)域，區(qū)塊鏈的價(jià)值在于可實(shí)現(xiàn)對無論視頻、音頻、電影、音樂、電子書等等內(nèi)容的創(chuàng)作權(quán)的存證確認(rèn)，以及更進(jìn)一步的，在消費(fèi)、交易環(huán)節(jié)給創(chuàng)作者做公平的收益分享。要在這個(gè)場景落地也有一些很關(guān)鍵的挑戰(zhàn)，就是怎么保證在內(nèi)容、交易和消費(fèi)的環(huán)節(jié)，將消費(fèi)數(shù)字內(nèi)容的工具和流程均納入到區(qū)塊鏈這種利益分配的體系，這是區(qū)塊鏈在這個(gè)場景落地的一個(gè)很關(guān)鍵挑戰(zhàn)。

在供應(yīng)鏈金融，核心企業(yè)在供應(yīng)鏈中往往處于很強(qiáng)勢的地位，那么如何把核心企業(yè)的信用資質(zhì)傳導(dǎo)到供應(yīng)鏈的上游和下游，比如上游的多級供應(yīng)商，以及下游的多級經(jīng)銷商，讓他們可以基于核心企業(yè)的背書，得到更低成本、更高效的融資，這是供應(yīng)鏈金融區(qū)塊鏈一個(gè)核心價(jià)值。但里面的關(guān)鍵落地挑戰(zhàn)在于，怎么能吸引到整個(gè)供應(yīng)鏈上下游那么多企業(yè)都愿意參與到區(qū)塊鏈這個(gè)業(yè)務(wù)體系來。

基因醫(yī)療數(shù)據(jù)存儲和共享，這個(gè)場景有一定共通性，因?yàn)樗矔m用于像金融大數(shù)據(jù)，或者是互聯(lián)網(wǎng)大數(shù)據(jù)，這些數(shù)據(jù)資產(chǎn)的存儲和共享。這里面區(qū)塊鏈價(jià)值在于，可以對數(shù)據(jù)資產(chǎn)的所有權(quán)做一個(gè)確認(rèn)，并且在這種數(shù)據(jù)資產(chǎn)交易的平臺或者體系里面，可以根據(jù)所有者的這些不可篡改的確權(quán)存證來保證數(shù)據(jù)交易的利益的在各方實(shí)現(xiàn)分配。但里面也有一些關(guān)鍵挑戰(zhàn)，例如怎樣去保證數(shù)據(jù)交易在數(shù)據(jù)使用這個(gè)環(huán)節(jié)，數(shù)據(jù)資產(chǎn)不會發(fā)生泄露或者被違規(guī)使用，或者被購買方二次倒賣等等，這是數(shù)據(jù)資產(chǎn)業(yè)務(wù)落地的一個(gè)關(guān)鍵挑戰(zhàn)。各個(gè)行業(yè)區(qū)塊鏈落地也都面臨著很多挑戰(zhàn)，上面舉的是一些比較典型的例子。

對于企業(yè)來說，現(xiàn)在關(guān)心區(qū)塊鏈，并且想和業(yè)務(wù)結(jié)合的企業(yè)越來越多。我們與阿里云的客戶、以及我們的合作伙伴進(jìn)行了很多探討，以及內(nèi)部我們也正在開發(fā)一些落地方案。

對一個(gè)企業(yè)來說，要應(yīng)用區(qū)塊鏈到底需要考慮哪些維度的問題？大概分為這幾個(gè)類別。比如說在業(yè)務(wù)方面，我們首先要做一件事是要有“人”的保證，這個(gè)人才的團(tuán)隊(duì)包含很多方面，需要區(qū)塊鏈的技術(shù)人才，需要部署區(qū)塊鏈底層，或者業(yè)務(wù)底層的云平臺的技術(shù)人才，需要有業(yè)務(wù)應(yīng)用開發(fā)的團(tuán)隊(duì)去支持，需要有業(yè)務(wù)方面的一些專家，所以這是人才團(tuán)隊(duì)的維度。

另外業(yè)務(wù)場景選擇，有很多企業(yè)場景，如果能用傳統(tǒng)的中心化方案或者系統(tǒng)去解決的話，那么就要反思是否有必要去用區(qū)塊鏈。如果說有一些場景是涉及到跨企業(yè)協(xié)作，并且確實(shí)缺乏信任基礎(chǔ)的，這個(gè)就可以考慮應(yīng)用區(qū)塊鏈。

下面是業(yè)務(wù)流程優(yōu)化，區(qū)塊鏈在業(yè)務(wù)應(yīng)用里面是有一個(gè)特點(diǎn)，尤其在聯(lián)盟鏈，它涉及到跨企業(yè)的業(yè)務(wù)流程，所以不像傳統(tǒng)的流程只限于企業(yè)內(nèi)部，只是幾個(gè)部門之間的協(xié)作，跨企業(yè)的業(yè)務(wù)流程需要在保證各方平等、自治的基礎(chǔ)上，建立起業(yè)務(wù)流程以及進(jìn)一步優(yōu)化，這些都是必須考慮的問題。

應(yīng)用開發(fā)模式，解決的是如何在你的業(yè)務(wù)人員或開發(fā)人員與區(qū)塊鏈底層技術(shù)之間構(gòu)建起一個(gè)橋梁，把區(qū)塊鏈底層的這些 API 調(diào)用、SDK 調(diào)用變成你的業(yè)務(wù)模型、業(yè)務(wù)流程，讓業(yè)務(wù)人員能夠理解和使用。接下來是可視化分析，區(qū)塊鏈本身運(yùn)行是類似于一個(gè)黑盒子，如果我們在企業(yè)落地，我們關(guān)心是它對業(yè)務(wù)貢獻(xiàn)的商業(yè)價(jià)值，怎樣把這種一個(gè)黑盒的系統(tǒng)變成對商業(yè)的決策者來說是可視化、可量化，并且可用于做 BI 分析的設(shè)計(jì)。數(shù)據(jù)建模和管理指的是，區(qū)塊鏈里面賬本存儲的是 key value，是區(qū)塊鏈對應(yīng)的業(yè)務(wù)場景的數(shù)據(jù)建模存儲的內(nèi)容。那么區(qū)塊鏈業(yè)務(wù)數(shù)據(jù)怎么和企業(yè)的主數(shù)據(jù)之間去建立起關(guān)聯(lián)，以及做后期的數(shù)據(jù)模型的管理？這些也是企業(yè)需要考慮的。

下面的話，像技術(shù)方案選型，就涉及到區(qū)塊鏈技術(shù)本身的不同流派、不同區(qū)塊鏈類型等等的選擇，以及相應(yīng)的開發(fā)編程語言、開發(fā)框架的選擇，還有底層部署云平臺技術(shù)的選擇。平臺設(shè)計(jì)實(shí)施，這包含了整個(gè)平臺方案以及業(yè)務(wù)部署方案的設(shè)計(jì)實(shí)施。高可用和災(zāi)備，這里面涉及到跨企業(yè)區(qū)塊鏈業(yè)務(wù)協(xié)作體系，怎么既要保證本企業(yè)業(yè)務(wù)服務(wù)的可持續(xù)性，也要保證在跨企業(yè)協(xié)作中，不會因?yàn)橐粋€(gè)企業(yè)的節(jié)點(diǎn)，導(dǎo)致了整個(gè)聯(lián)盟鏈的業(yè)務(wù)的癱瘓，所以這都是要考慮的很關(guān)鍵的問題。

像安全合規(guī)治理，這是大家應(yīng)用區(qū)塊鏈最關(guān)心的一個(gè)點(diǎn)，因?yàn)槲叶及盐业臉I(yè)務(wù)數(shù)據(jù)放在一個(gè)跨企業(yè)的聯(lián)盟鏈上面，我是非常重視里面的數(shù)據(jù)安全，商業(yè)隱私的保護(hù)，尤其大家如果還涉及到，比如說進(jìn)軍海外市場，涉及到和美國政府或歐盟打交道，這些很嚴(yán)格的數(shù)據(jù)保護(hù)的要求，隱私保護(hù)的政策等等，這方面也是我們應(yīng)用區(qū)塊鏈必須要考慮的。

另外平臺應(yīng)用運(yùn)維，這里面就涉及到因?yàn)閰^(qū)塊鏈的不可篡改特性，導(dǎo)致上面的配置、數(shù)據(jù)、應(yīng)用的管理相比傳統(tǒng)有很大的不同和挑戰(zhàn)。下面是運(yùn)營，市場營銷宣傳，我看業(yè)界很多公司做得很好，這塊我就不用多說了。生態(tài)系統(tǒng)參與包含了企業(yè)去應(yīng)用區(qū)塊鏈，同時(shí)要考慮，是否要跟外部的，比如說區(qū)塊鏈相關(guān)的官方組織，以及開源社區(qū)的技術(shù)參與，以及業(yè)務(wù)生態(tài)系統(tǒng)的參與，比如說，基于某個(gè)業(yè)務(wù)形成的這些行業(yè)聯(lián)盟，以及行業(yè)協(xié)會等等的參與。

所以這里面涉及到的問題是覆蓋了很多維度，今天可能不能對所有問題都有一個(gè)標(biāo)準(zhǔn)的答案。但我們會對其中一些地方，分享我們的一些探索經(jīng)驗(yàn)。

面的話，是介紹我們在探索過程中用到的工具，就是去年 10 月份，我們在杭州云棲大會發(fā)布的基于阿里云容器服務(wù)的區(qū)塊鏈解決方案。這其實(shí)是我們在區(qū)塊鏈領(lǐng)域探索的第一小步，目前我們也在緊張地開發(fā)一些更新的產(chǎn)品形態(tài)和更多的落地方案。

這里面它核心解決是什么問題？對很多企業(yè)來說應(yīng)用區(qū)塊鏈，關(guān)注的是怎么快速地去把業(yè)務(wù)和區(qū)塊鏈結(jié)合，實(shí)現(xiàn)業(yè)務(wù)應(yīng)用上線，我想聚焦的是業(yè)務(wù)創(chuàng)新本身，沒有足夠的比如人員團(tuán)隊(duì)或者是時(shí)間去進(jìn)行區(qū)塊鏈整個(gè)底層的建設(shè)，所以這是企業(yè)一方面的訴求。

另一方面的訴求是由區(qū)塊鏈的技術(shù)特性決定的，因?yàn)樗牟豢纱鄹牡奶匦詴?dǎo)致了在開發(fā)業(yè)務(wù)應(yīng)用的時(shí)候，區(qū)塊鏈系統(tǒng)里面的數(shù)據(jù)，區(qū)塊鏈的整個(gè)網(wǎng)絡(luò)的配置，不是說管理員去改幾個(gè)參數(shù)，或者是去做 roll back、delete 等等就可以恢復(fù)成一套全新的環(huán)境。你需要把整個(gè)環(huán)境鏟掉，然后重新把它再搭建起來才能進(jìn)下一輪的開發(fā)測試等等。這就導(dǎo)致了在業(yè)務(wù)應(yīng)用的開發(fā)過程迭代的效率問題。這類的話，我們的區(qū)塊鏈解決方案可以提供基于界面化的一鍵自動化配置部署，讓企業(yè)可以在幾分鐘內(nèi)就可以得到一套企業(yè)級的區(qū)塊鏈開發(fā)測試環(huán)境，這是我們當(dāng)時(shí)解決用戶痛點(diǎn)的一個(gè)出發(fā)點(diǎn)。

這個(gè)是解決方案的大體架構(gòu)，這里我也不做太多介紹了。大家可以看一下，這里面體現(xiàn)了如何在 Kubernetes 集群技術(shù)上去搭建一套 Hyperledger Fabric 區(qū)塊鏈服務(wù)的最基本的要素的展現(xiàn)，企業(yè)在進(jìn)行區(qū)塊鏈技術(shù)選型時(shí)候也可以參考這些緯度，去選擇區(qū)塊鏈平臺。

下面我們就重點(diǎn)講講我們在這三個(gè)領(lǐng)域上面的探索經(jīng)驗(yàn)。

第一個(gè)是基于 Hyperledger Fabric 的業(yè)務(wù)和數(shù)據(jù)存儲容量的估算方法。下面這個(gè)圖展示的是 Hyperledger Fabric 的完整交易流程以及部署架構(gòu)，給大家介紹一下基于 Hyperledger Fabric 的區(qū)塊鏈交易是怎么進(jìn)行的。首先業(yè)務(wù)應(yīng)用會通過 CA 服務(wù)去進(jìn)行身份的注冊以及登錄之后，就可以去連接不同組織的背書 Peer 節(jié)點(diǎn)，把交易請求發(fā)送給背書的 Peer 節(jié)點(diǎn)，進(jìn)行區(qū)塊鏈交易模擬運(yùn)行，模擬運(yùn)行是通過里面的 Chaincode 容器去進(jìn)行的，再把模擬交易結(jié)果返回給 Client，再發(fā)給上面的 Orderer 服務(wù)，去把這些模擬運(yùn)行的交易結(jié)果變成一個(gè)個(gè)區(qū)塊，這就是區(qū)塊鏈里面出塊的那個(gè)環(huán)節(jié)。Orderer 服務(wù)內(nèi)部是把 transaction 交易信息放到后臺 Kafka 隊(duì)列，再從隊(duì)列取出后組成一個(gè)個(gè)區(qū)塊的。組成區(qū)塊之后，Orderer 會把區(qū)塊廣播發(fā)送給整個(gè)業(yè)務(wù)網(wǎng)絡(luò)里的 Peer 節(jié)點(diǎn)，每個(gè) Peer 節(jié)點(diǎn)收到這些塊之后，就會對里面的 transaction 做一個(gè) validation，再把里面合法的交易 commit 到區(qū)塊鏈的這些賬本里面，這就是區(qū)塊鏈 Hyperledger Fabric 一個(gè)交易的整體流程。

但對一個(gè)企業(yè)來說，我如果要搭建一個(gè)基于區(qū)塊鏈的業(yè)務(wù)系統(tǒng)，我光了解這個(gè)流程是不夠的，尤其是企業(yè)的架構(gòu)師、或者預(yù)算和采購的團(tuán)隊(duì)，以及甚至 CTO 他會問這個(gè)問題：你這套系統(tǒng)到底能支撐我多大的業(yè)務(wù)量？尤其區(qū)塊鏈里面最重要的是交易數(shù)據(jù)，那么為了對交易數(shù)據(jù)做持久化，我要規(guī)劃多大的存儲資源才能滿足我企業(yè)業(yè)務(wù)未來一年、兩年、三年的運(yùn)行的需要，這是我們遇到的很多客戶在落地前問的第一個(gè)問題。

這個(gè)問題不好回答，因?yàn)橛捎趨^(qū)塊鏈比如 Hyperledger Fabric 本身的交易流程以及底層技術(shù)架構(gòu)復(fù)雜性，業(yè)界也沒有很好的估算的方法。我們進(jìn)行了對 Fabric 架構(gòu)和代碼的分析，以及通過一些容量的測試，得出了一些估算方法，下面跟大家分享一下。

首先我們對整個(gè) Fabric 技術(shù)架構(gòu)的存儲增長的熱點(diǎn)做了一個(gè)定性的分析，可以看到在 Orderer 這個(gè)節(jié)點(diǎn)，每個(gè) Orderer 它會保存賬本的一個(gè) block file，就是交易歷史文件，它跟我們的交易量是線性相關(guān)的，增長的壓力是比較大的。

其次是 Kafka 集群的隊(duì)列，剛才講的在 Orderer 收到交易數(shù)據(jù)以后是放在 Kafka Broker 的隊(duì)列里面，這里面也會有數(shù)據(jù)容量的增長，這塊是黃色，代表它增長壓力是中等的，后面會解釋一下。其次在整個(gè)網(wǎng)絡(luò)里面每個(gè) Peer 又有兩部分，在 Peer 的 Ledger 里面也有 block file，這塊也是隨著交易量會有一個(gè)線性增長。其次 StateDB 是存儲賬本的世界狀態(tài)，這一部分也會跟交易相關(guān)，但是它不是一個(gè)直接線性相關(guān)的關(guān)系。

有了這個(gè)定性的分析結(jié)果之后，我們再進(jìn)一步看看如何定量的去得出估算的結(jié)果。這里是經(jīng)過剛才講的一系列架構(gòu)代碼分析，以及容量測試，得到的一個(gè)估算公式?？赡芩€不是非常完美的，但是在實(shí)際應(yīng)用中已經(jīng)能提供非常有用的信息。我大概解釋一下，區(qū)塊鏈有個(gè)多鏈的概念，就是 Fabric 有個(gè)多鏈的概念，通過 Channel 去實(shí)現(xiàn)，每個(gè) Channel 代表了一種業(yè)務(wù)，這種業(yè)務(wù)有獨(dú)立的賬本，跟其他的 Channel 是隔離的關(guān)系。我們可以讓用戶提供一個(gè)輸入，比如說它可以估算每種業(yè)務(wù)每天平均交易筆數(shù)作為基礎(chǔ)，因?yàn)檫@里我們進(jìn)行的是容量估計(jì)，而不是做 Performance 峰值估計(jì)，這是第一個(gè)輸入?yún)?shù)。

其次 Fabric 每一筆交易的基本開銷是 Fabric transaction 這種數(shù)據(jù)結(jié)構(gòu)，這個(gè)數(shù)據(jù)結(jié)構(gòu)我們分析過代碼，大概是 2.9KB 的大小，但是還有其他附加的，比如說 Index 的一些開銷以及 Block 的一些開銷，我們大概取一個(gè)估算值，大概 4K 左右的一個(gè)結(jié)果。那么再加上每一筆交易平均業(yè)務(wù)數(shù)據(jù)大小，那就是你的真正交易 Payload 數(shù)據(jù)，你想把什么數(shù)據(jù)寫在鏈上，這個(gè) Payload 的大小。這里要乘個(gè) 2，乘 2 是個(gè)很關(guān)鍵的點(diǎn)，在剛才講的背書交易的過程，它這個(gè)交易 transaction 數(shù)據(jù)是包含兩部分，一個(gè)叫了 chaincode proposal payload，以及 proposal response payload，它是把我的業(yè)務(wù)數(shù)據(jù)這一部分進(jìn)行了兩次的表述，在我的 transaction 數(shù)據(jù)結(jié)構(gòu)里面，這就是為什么有乘 2 的原因。

其次就是業(yè)務(wù) Channel 數(shù)量，我搭起來一套 Fabric 區(qū)塊鏈網(wǎng)絡(luò)，不希望只服務(wù)于一種業(yè)務(wù)，希望可以支持多種業(yè)務(wù)，那么要乘上相應(yīng)的業(yè)務(wù) Channel 數(shù)量。要支持業(yè)務(wù)年的時(shí)間，還有 Peer 節(jié)點(diǎn)數(shù)量，Peer 節(jié)點(diǎn)是因?yàn)槊總€(gè) Peer 上面會存儲區(qū)塊鏈的 block file 來記錄賬本，乘 2，2 到 1 之間是個(gè)很有意思的，它涉及到每個(gè) Peer 既有 block file，也有 StateDB，比如企業(yè)級我們現(xiàn)在用 CoachDB，但這個(gè)數(shù)據(jù)特征是跟你的業(yè)務(wù)類型緊密相關(guān)的，如果說你每個(gè)交易都是創(chuàng)建一個(gè)新的 key value，跟你多筆交易 update 同一個(gè) key value，對 StateDB 的開銷是不一樣的。

另一方面，因?yàn)橄?CoachDB 它應(yīng)用了 Google 的 Snappy 壓縮技術(shù)，真正的交易的 Payload 進(jìn)到 StateDB 里面存成 key value，它不是原生的數(shù)據(jù)大小，而是它會經(jīng)過一段時(shí)間壓縮之后，數(shù)據(jù)量會大大的減小，當(dāng)然壓縮比例會跟業(yè)務(wù)數(shù)據(jù)的本身這些數(shù)據(jù)的一些特征會有關(guān)系，這就是一個(gè)比較彈性的，因?yàn)樯婕暗轿覄偛胖v的 StateDB 的特性。此外 Orderer 的節(jié)點(diǎn)數(shù)量，這里面就涉及到，因?yàn)?Orderer 它保存了一套完整的數(shù)據(jù)賬本，那么它跟 Peer 的賬本是一致的，這塊還有相應(yīng)的開銷。

然后就是 Kafka，Kafka 的隊(duì)列是有一個(gè)功能是做 retention period 的保證，經(jīng)過 retention period 之后，它可以把隊(duì)列里的消息，就假定是客戶不需要的可以把它清除掉，在 Fabric 里面 kafka Retention 天數(shù)大概是 7 天，當(dāng)然用戶可以自定義了，7 天的量，再乘以 replica，replica 是 kafka 用來做數(shù)據(jù)的高可用的，同一套數(shù)據(jù)在 kafka 會有多套副本。在 Fabric 里面，kafka replica 數(shù)量是 3，這是只需要保存 7×3 的這樣一個(gè)量。這就是整個(gè)估算的方法，下面我給出對應(yīng)的 Excel 公式，大家也可以針對你的情況自己得出一套自動計(jì)算的估算公式。

面再講講，在運(yùn)用估算方法以及注意的點(diǎn)，也反映了區(qū)塊鏈這個(gè)業(yè)務(wù)應(yīng)用系統(tǒng)一些設(shè)計(jì)原則。第一個(gè)，每條業(yè)務(wù) channel 它是有總的大小限制，這個(gè)來自于哪里呢？因?yàn)閯偛胖v到每個(gè) channel 它有一套賬本，賬本核心是 Block，記錄所有的交易數(shù)據(jù)、交易歷史記錄，這個(gè) Block 是以一個(gè)個(gè) append-only 類型的文件來存儲，這些文件大概是有 10 的 6 次方這樣的數(shù)量上限，每個(gè)大小是 64 兆，乘下來，技術(shù)上大小上限是 61TB。剛才看到估算的這些值，但是它的上限，比如說每個(gè) Order 或者每個(gè) Peer，它上面的業(yè)務(wù)數(shù)據(jù)量是不能超過 block file 的上限的。

第二個(gè)就是我們要注意到底什么東西是適合放在區(qū)塊鏈的，這不僅僅是容量規(guī)劃的問題，而是整個(gè)業(yè)務(wù)場景選擇的問題，因?yàn)槭紫葏^(qū)塊鏈的特征是適合保存證據(jù)，它不是用來作為原始的數(shù)據(jù)存儲，或大數(shù)據(jù)存儲的基礎(chǔ)設(shè)施。另外的話，如果你的業(yè)務(wù)場景，頻繁地去更新同一個(gè) Key，比如銀行里面轉(zhuǎn)賬、支付交易，那么我們就要思考這種是否適合區(qū)塊鏈一個(gè)特質(zhì)，因?yàn)閰^(qū)塊鏈在業(yè)界也有一個(gè)不成文的共識，它本身不涉及用于支撐高頻交易業(yè)務(wù)的。另外還有 Block 開銷，因?yàn)閯偛胖v了 transaction 是封裝在 Block 里面的，這個(gè) Block 本身從數(shù)據(jù)結(jié)構(gòu)上大概有 1.9KB 的基本開銷，Block 數(shù)量跟 transaction 數(shù)量比例是不定的，因?yàn)橛邢旅鎺讉€(gè)原因，看到數(shù)字貨幣像比特幣，它的出塊是根據(jù)礦工挖礦，也就做一系列的窮舉計(jì)算以及做哈希計(jì)算得到一個(gè)滿足難度條件的隨機(jī)數(shù)等等，這是數(shù)字貨幣出塊。

但是在 Fabric 里面出塊，它只需要滿足這樣三條標(biāo)準(zhǔn)，比如 Block 里面包含的 transaction 筆數(shù)達(dá)到上限，它就可以去出一個(gè)塊?；蛘呤?Block 里面包含的 transaction 總的 byte 字節(jié)數(shù)達(dá)到了上限，或者是從第一條 transaction 進(jìn)入 Block 之后，等待時(shí)間到達(dá)上限都可以產(chǎn)生一個(gè)塊。因?yàn)檫@三條標(biāo)準(zhǔn)導(dǎo)致了 transaction 數(shù)量與 Block 數(shù)量是沒有嚴(yán)格的對應(yīng)的關(guān)系，順便說一句，這三個(gè)標(biāo)準(zhǔn)跟 IBM MQ 做網(wǎng)絡(luò)批量的高效傳輸三條標(biāo)準(zhǔn)是基本一致的，業(yè)界有很多設(shè)計(jì)是很巧合的。

其他還有一些比較次要的考慮因素，比如說 Fabric 容器鏡像開銷，F(xiàn)abric 涉及到容器鏡像從三五百兆再到 1.5G，1.3G 都有，假如說所有的鏡像單獨(dú)存成文件，大概是 11G 的開銷，當(dāng)然如果我們把鏡像存儲在 Docker Registry 里面比如說 Harbor，或者是云上的鏡像服務(wù)，它占的實(shí)際體積會小很多，因?yàn)榛?docker image 分層文件系統(tǒng)的技術(shù)。但是如果對企業(yè)來說可能要考慮，我要備份多少套的鏡像版本來支撐業(yè)務(wù)的升級、回滾，或者是開發(fā)的需要，這是存儲開銷。此外還有業(yè)務(wù)應(yīng)用跟其他軟件的容器鏡像、以及數(shù)據(jù)的存儲備份等等這些開銷，但這些都是相對次要的一些因素。

我們分享完第一個(gè)探索經(jīng)驗(yàn)，下面將從運(yùn)維角度，怎么對 Hyperledger Fabric 日志來實(shí)現(xiàn)企業(yè)級的運(yùn)維分析?？赡茉谧暮芏嗤蕰羞^使用 Fabric 日志的一些經(jīng)驗(yàn)，比如說我們可以通過像 Kubernetes 控制臺，去查看某一個(gè) Peer 節(jié)點(diǎn)、Orderer 節(jié)點(diǎn)的日志信息，或者通過命令行運(yùn)行 kubectl logs 或 docker logs 命令，也可以看到每個(gè)節(jié)點(diǎn)的容器的日志信息。但問題是這些手段滿足不了企業(yè)級運(yùn)維和業(yè)務(wù)分析的需求，這里所面向的對象很可能是區(qū)塊鏈運(yùn)維系統(tǒng)的團(tuán)隊(duì)，甚至某些場合下會涉及到業(yè)務(wù)相關(guān)的團(tuán)隊(duì)。

那么到底企業(yè)級的運(yùn)維與業(yè)務(wù)分析需要怎樣的 Fabric 日志的工具或者能力呢？其實(shí)這種區(qū)塊鏈的業(yè)務(wù)系統(tǒng)可以結(jié)合，比如說云平臺的日志服務(wù)，或者像開源的 ELK 方案去搭建出日志分析系統(tǒng)，去跟區(qū)塊鏈整合起來。下面舉幾個(gè)例子說明我們需要哪些能力。第一個(gè)就是我們希望對區(qū)塊鏈業(yè)務(wù)系統(tǒng)的日志實(shí)現(xiàn)實(shí)時(shí)索引以及動態(tài)查詢的能力。比如說這個(gè)例子里面，我們是用阿里云的區(qū)塊鏈解決方案整合了阿里云日志服務(wù)來進(jìn)行示例，這里我們需要對某一個(gè)業(yè)務(wù) Channel 來進(jìn)行實(shí)時(shí)的索引查詢，來看這個(gè)日志的一些分布，以及跟這個(gè)業(yè)務(wù) Channel 相關(guān)的日志信息，可以通過關(guān)鍵字，以及像一些類 SQL 的查詢語句來快速實(shí)現(xiàn)查詢。

第二個(gè)例子，對企業(yè)來說，可能要對一些比較敏感的，或者是高優(yōu)先級，或者是對風(fēng)險(xiǎn)有關(guān)的一些日志信息，實(shí)現(xiàn)自動告警的功能，并且這些告警可以去對接，比如短信，郵件，企業(yè)及時(shí)通信工具如釘釘?shù)鹊纫恍┕ぞ摺Ｔ谙旅孢@個(gè)示例中，我們就可以去對某一個(gè)區(qū)塊鏈應(yīng)用系統(tǒng)來設(shè)定一些告警規(guī)則，檢查在某一個(gè) Peer 節(jié)點(diǎn)上是否有運(yùn)行某個(gè)特定，如某個(gè)高敏感性 chaincode 應(yīng)用，設(shè)置這樣一條規(guī)則，在配置好規(guī)則以后，后面當(dāng)我業(yè)務(wù)系統(tǒng)一旦滿足這個(gè)條件，那么就會自動通過郵件，以及短信，向用戶自動發(fā)送告警，并且運(yùn)維人員在告警記錄里面可以看到告警的這個(gè)過程。

再下一個(gè)實(shí)踐就是，我們企業(yè)是希望能夠獲得一種關(guān)于區(qū)塊鏈業(yè)務(wù)系統(tǒng)運(yùn)行情況的可視化的統(tǒng)計(jì)圖表，以及報(bào)表數(shù)據(jù)輸出。這里我們做了一個(gè)圖表分析，就是在這幾個(gè) Peer 節(jié)點(diǎn)上，我們其實(shí)是做了幾個(gè)事情：在一個(gè) Peer 上面調(diào)用了 10 次智能合約，在另一個(gè) Peer 上面調(diào)用了 100 次智能合約。在我們實(shí)際的日志的圖表分析里面，就可以看出業(yè)務(wù)調(diào)用情況的體現(xiàn)，因?yàn)檫@里基準(zhǔn)的這些日志數(shù)量是進(jìn)行賬本數(shù)據(jù)同步的一些日志，那么額外的這一部分的 Delta 日志數(shù)量是對應(yīng)這 10 次 chaincode 調(diào)用的，另外這部分更大的 Delta 日志數(shù)量就是在這 Peer 上進(jìn)行 100 次 chaincode 調(diào)用的情況。 這些日志分析圖表可以作為業(yè)務(wù)團(tuán)隊(duì)去分析，比如說在不同業(yè)務(wù)區(qū)域，進(jìn)入?yún)^(qū)塊鏈業(yè)務(wù)系統(tǒng)流量的差別，或者說跟不同企業(yè)對接的區(qū)塊鏈業(yè)務(wù)系統(tǒng)，它的流量差異等等，都可以作為一個(gè)業(yè)務(wù)分析的依據(jù)，以及說后續(xù)可以導(dǎo)出成 Excel 的形式。