作者 | 余珊

本文根據 QCon 北京 2018 站上的演講整理而成，原題《區塊鏈 Hyperledger Fabric 的落地挑戰與阿里云探索經驗分享》。

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

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

區塊鏈的類型有很多，公有鏈、私有鏈、聯盟鏈等等，在阿里云這邊，我們的工作更多是關注聯盟鏈這種類型。區塊鏈本身不是一個全新的技術，它是基于一些業界已有的關鍵技術去構成的一套體系，包括比如基于拜占庭等共識算法。還有基于密碼學的一些技術基礎，像非對稱密鑰、數字簽名等等技術。此外，它本質是一個分布式系統架構，所以會涉及到一些分布式計算如高可用，水平擴展，Gossip 通訊協議等等一些技術。

區塊鏈要解決的核心問題，是在缺乏信任基礎的商業環境下，各方如何來進行交易和協作的問題。大家看到有很多講區塊鏈價值，比如說提升了協作效率，降低了時間成本，提升了信息透明度等等，根源都在于我們缺乏信任以及或信任度不足的情況下，在傳統模式引入的各種冗余的流程、冗余的模式、中介機構所導致的。同時區塊鏈也會帶來像去中心化 / 多中心化這樣的結果，但是去中心化不是區塊鏈的目的，真正目的是要解決跨企業的信任問題。

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

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

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

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

比如說在商品溯源這個場景，區塊鏈實現的是商品從出廠到中間經過物流、倉儲、經銷商、零售、電商平臺，再到消費者，這個過程中它的產品溯源信息的不可篡改的特性。但是在這業務場景落地有一個很關鍵的挑戰，雖然區塊鏈實現了鏈上數據的不可篡改，但也要解決實體商品本身如何跟區塊鏈上的數據做一個可信的關聯。因為我們要避免出現標簽是真的，區塊鏈溯源數據都是真的，但是實體商品是假的。這個環節不是區塊鏈就可以把它全部解決，我們還要結合像防偽技術等等，去形成更完整的溯源方案。

在數字內容版權這個領域，區塊鏈的價值在于可實現對無論視頻、音頻、電影、音樂、電子書等等內容的創作權的存證確認，以及更進一步的，在消費、交易環節給創作者做公平的收益分享。要在這個場景落地也有一些很關鍵的挑戰，就是怎么保證在內容、交易和消費的環節，將消費數字內容的工具和流程均納入到區塊鏈這種利益分配的體系，這是區塊鏈在這個場景落地的一個很關鍵挑戰。

在供應鏈金融，核心企業在供應鏈中往往處于很強勢的地位，那么如何把核心企業的信用資質傳導到供應鏈的上游和下游，比如上游的多級供應商，以及下游的多級經銷商，讓他們可以基于核心企業的背書，得到更低成本、更高效的融資，這是供應鏈金融區塊鏈一個核心價值。但里面的關鍵落地挑戰在于，怎么能吸引到整個供應鏈上下游那么多企業都愿意參與到區塊鏈這個業務體系來。

基因醫療數據存儲和共享，這個場景有一定共通性，因為它也會適用于像金融大數據，或者是互聯網大數據，這些數據資產的存儲和共享。這里面區塊鏈價值在于，可以對數據資產的所有權做一個確認，并且在這種數據資產交易的平臺或者體系里面，可以根據所有者的這些不可篡改的確權存證來保證數據交易的利益的在各方實現分配。但里面也有一些關鍵挑戰，例如怎樣去保證數據交易在數據使用這個環節，數據資產不會發生泄露或者被違規使用，或者被購買方二次倒賣等等，這是數據資產業務落地的一個關鍵挑戰。各個行業區塊鏈落地也都面臨著很多挑戰，上面舉的是一些比較典型的例子。

對于企業來說，現在關心區塊鏈，并且想和業務結合的企業越來越多。我們與阿里云的客戶、以及我們的合作伙伴進行了很多探討，以及內部我們也正在開發一些落地方案。

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

另外業務場景選擇，有很多企業場景，如果能用傳統的中心化方案或者系統去解決的話，那么就要反思是否有必要去用區塊鏈。如果說有一些場景是涉及到跨企業協作，并且確實缺乏信任基礎的，這個就可以考慮應用區塊鏈。

下面是業務流程優化，區塊鏈在業務應用里面是有一個特點，尤其在聯盟鏈，它涉及到跨企業的業務流程，所以不像傳統的流程只限于企業內部，只是幾個部門之間的協作，跨企業的業務流程需要在保證各方平等、自治的基礎上，建立起業務流程以及進一步優化，這些都是必須考慮的問題。

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

下面的話，像技術方案選型，就涉及到區塊鏈技術本身的不同流派、不同區塊鏈類型等等的選擇，以及相應的開發編程語言、開發框架的選擇，還有底層部署云平臺技術的選擇。平臺設計實施，這包含了整個平臺方案以及業務部署方案的設計實施。高可用和災備，這里面涉及到跨企業區塊鏈業務協作體系，怎么既要保證本企業業務服務的可持續性，也要保證在跨企業協作中，不會因為一個企業的節點，導致了整個聯盟鏈的業務的癱瘓，所以這都是要考慮的很關鍵的問題。

像安全合規治理，這是大家應用區塊鏈最關心的一個點，因為我都把我的業務數據放在一個跨企業的聯盟鏈上面，我是非常重視里面的數據安全，商業隱私的保護，尤其大家如果還涉及到，比如說進軍海外市場，涉及到和美國政府或歐盟打交道，這些很嚴格的數據保護的要求，隱私保護的政策等等，這方面也是我們應用區塊鏈必須要考慮的。

另外平臺應用運維，這里面就涉及到因為區塊鏈的不可篡改特性，導致上面的配置、數據、應用的管理相比傳統有很大的不同和挑戰。下面是運營，市場營銷宣傳，我看業界很多公司做得很好，這塊我就不用多說了。生態系統參與包含了企業去應用區塊鏈，同時要考慮，是否要跟外部的，比如說區塊鏈相關的官方組織，以及開源社區的技術參與，以及業務生態系統的參與，比如說，基于某個業務形成的這些行業聯盟，以及行業協會等等的參與。

所以這里面涉及到的問題是覆蓋了很多維度，今天可能不能對所有問題都有一個標準的答案。但我們會對其中一些地方，分享我們的一些探索經驗。

面的話，是介紹我們在探索過程中用到的工具，就是去年 10 月份，我們在杭州云棲大會發布的基于阿里云容器服務的區塊鏈解決方案。這其實是我們在區塊鏈領域探索的第一小步，目前我們也在緊張地開發一些更新的產品形態和更多的落地方案。

這里面它核心解決是什么問題？對很多企業來說應用區塊鏈，關注的是怎么快速地去把業務和區塊鏈結合，實現業務應用上線，我想聚焦的是業務創新本身，沒有足夠的比如人員團隊或者是時間去進行區塊鏈整個底層的建設，所以這是企業一方面的訴求。

另一方面的訴求是由區塊鏈的技術特性決定的，因為它的不可篡改的特性會導致了在開發業務應用的時候，區塊鏈系統里面的數據，區塊鏈的整個網絡的配置，不是說管理員去改幾個參數，或者是去做 roll back、delete 等等就可以恢復成一套全新的環境。你需要把整個環境鏟掉，然后重新把它再搭建起來才能進下一輪的開發測試等等。這就導致了在業務應用的開發過程迭代的效率問題。這類的話，我們的區塊鏈解決方案可以提供基于界面化的一鍵自動化配置部署，讓企業可以在幾分鐘內就可以得到一套企業級的區塊鏈開發測試環境，這是我們當時解決用戶痛點的一個出發點。

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

下面我們就重點講講我們在這三個領域上面的探索經驗。

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

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

這個問題不好回答，因為由于區塊鏈比如 Hyperledger Fabric 本身的交易流程以及底層技術架構復雜性，業界也沒有很好的估算的方法。我們進行了對 Fabric 架構和代碼的分析，以及通過一些容量的測試，得出了一些估算方法，下面跟大家分享一下。

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

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

有了這個定性的分析結果之后，我們再進一步看看如何定量的去得出估算的結果。這里是經過剛才講的一系列架構代碼分析，以及容量測試，得到的一個估算公式。可能它還不是非常完美的，但是在實際應用中已經能提供非常有用的信息。我大概解釋一下，區塊鏈有個多鏈的概念，就是 Fabric 有個多鏈的概念，通過 Channel 去實現，每個 Channel 代表了一種業務，這種業務有獨立的賬本，跟其他的 Channel 是隔離的關系。我們可以讓用戶提供一個輸入，比如說它可以估算每種業務每天平均交易筆數作為基礎，因為這里我們進行的是容量估計，而不是做 Performance 峰值估計，這是第一個輸入參數。

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

其次就是業務 Channel 數量，我搭起來一套 Fabric 區塊鏈網絡，不希望只服務于一種業務，希望可以支持多種業務，那么要乘上相應的業務 Channel 數量。要支持業務年的時間，還有 Peer 節點數量，Peer 節點是因為每個 Peer 上面會存儲區塊鏈的 block file 來記錄賬本，乘 2，2 到 1 之間是個很有意思的，它涉及到每個 Peer 既有 block file，也有 StateDB，比如企業級我們現在用 CoachDB，但這個數據特征是跟你的業務類型緊密相關的，如果說你每個交易都是創建一個新的 key value，跟你多筆交易 update 同一個 key value，對 StateDB 的開銷是不一樣的。

另一方面，因為像 CoachDB 它應用了 Google 的 Snappy 壓縮技術，真正的交易的 Payload 進到 StateDB 里面存成 key value，它不是原生的數據大小，而是它會經過一段時間壓縮之后，數據量會大大的減小，當然壓縮比例會跟業務數據的本身這些數據的一些特征會有關系，這就是一個比較彈性的，因為涉及到我剛才講的 StateDB 的特性。此外 Orderer 的節點數量，這里面就涉及到，因為 Orderer 它保存了一套完整的數據賬本，那么它跟 Peer 的賬本是一致的，這塊還有相應的開銷。

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

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

第二個就是我們要注意到底什么東西是適合放在區塊鏈的，這不僅僅是容量規劃的問題，而是整個業務場景選擇的問題，因為首先區塊鏈的特征是適合保存證據，它不是用來作為原始的數據存儲，或大數據存儲的基礎設施。另外的話，如果你的業務場景，頻繁地去更新同一個 Key，比如銀行里面轉賬、支付交易，那么我們就要思考這種是否適合區塊鏈一個特質，因為區塊鏈在業界也有一個不成文的共識，它本身不涉及用于支撐高頻交易業務的。另外還有 Block 開銷，因為剛才講了 transaction 是封裝在 Block 里面的，這個 Block 本身從數據結構上大概有 1.9KB 的基本開銷，Block 數量跟 transaction 數量比例是不定的，因為有下面幾個原因，看到數字貨幣像比特幣，它的出塊是根據礦工挖礦，也就做一系列的窮舉計算以及做哈希計算得到一個滿足難度條件的隨機數等等，這是數字貨幣出塊。

但是在 Fabric 里面出塊，它只需要滿足這樣三條標準，比如 Block 里面包含的 transaction 筆數達到上限，它就可以去出一個塊。或者是 Block 里面包含的 transaction 總的 byte 字節數達到了上限，或者是從第一條 transaction 進入 Block 之后，等待時間到達上限都可以產生一個塊。因為這三條標準導致了 transaction 數量與 Block 數量是沒有嚴格的對應的關系，順便說一句，這三個標準跟 IBM MQ 做網絡批量的高效傳輸三條標準是基本一致的，業界有很多設計是很巧合的。

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

我們分享完第一個探索經驗，下面將從運維角度，怎么對 Hyperledger Fabric 日志來實現企業級的運維分析。可能在座的很多同仁會有過使用 Fabric 日志的一些經驗，比如說我們可以通過像 Kubernetes 控制臺，去查看某一個 Peer 節點、Orderer 節點的日志信息，或者通過命令行運行 kubectl logs 或 docker logs 命令，也可以看到每個節點的容器的日志信息。但問題是這些手段滿足不了企業級運維和業務分析的需求，這里所面向的對象很可能是區塊鏈運維系統的團隊，甚至某些場合下會涉及到業務相關的團隊。

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

第二個例子，對企業來說，可能要對一些比較敏感的，或者是高優先級，或者是對風險有關的一些日志信息，實現自動告警的功能，并且這些告警可以去對接，比如短信，郵件，企業及時通信工具如釘釘等等一些工具。在下面這個示例中，我們就可以去對某一個區塊鏈應用系統來設定一些告警規則，檢查在某一個 Peer 節點上是否有運行某個特定，如某個高敏感性 chaincode 應用，設置這樣一條規則，在配置好規則以后，后面當我業務系統一旦滿足這個條件，那么就會自動通過郵件，以及短信，向用戶自動發送告警，并且運維人員在告警記錄里面可以看到告警的這個過程。

再下一個實踐就是，我們企業是希望能夠獲得一種關于區塊鏈業務系統運行情況的可視化的統計圖表，以及報表數據輸出。這里我們做了一個圖表分析，就是在這幾個 Peer 節點上，我們其實是做了幾個事情：在一個 Peer 上面調用了 10 次智能合約，在另一個 Peer 上面調用了 100 次智能合約。在我們實際的日志的圖表分析里面，就可以看出業務調用情況的體現，因為這里基準的這些日志數量是進行賬本數據同步的一些日志，那么額外的這一部分的 Delta 日志數量是對應這 10 次 chaincode 調用的，另外這部分更大的 Delta 日志數量就是在這 Peer 上進行 100 次 chaincode 調用的情況。 這些日志分析圖表可以作為業務團隊去分析，比如說在不同業務區域，進入區塊鏈業務系統流量的差別，或者說跟不同企業對接的區塊鏈業務系統，它的流量差異等等，都可以作為一個業務分析的依據，以及說后續可以導出成 Excel 的形式。