Hyperledger是被業界非常看到的聯盟鏈的實現，包括IBM、Intel、R3、各個大型商業銀行等都參與其中，帶給我們關于區塊鏈技術與軟件工業、金融、保險、物流等領域碰撞結合的想象空間；在這個聯盟中，有超過1/4的成員都來自中國，這更是我們對于它的一舉一動都非常關注。很大程度上，Hyperledger和它背后的聯盟體系就代表著區塊鏈在產業環境中的未來。

作為最重要的子項目，在聯盟推出Fabric 0.6版本后，最新的Fabirc 1.0 版本也即將問世，今天我們來走馬觀花地領略一下最新版本（1.0）的總體架構，對于這個承載產業夢想的新生事物有個基本的認識。

說明：本文章僅僅是個概覽，具體的細節可以參考官網和github站點文檔；本人也只是從這些地方將信息匯集了一下，權作為是”借花獻佛“了。

• Fabric1.0總體架構

Hyperledger的fabric當前的穩定版本是0.6版，在講解1.0版本之前，我們先看看0.6版本的總體架構：

對應的0.6版本的運行時架構：

0.6版本的架構特點是：

結構簡單： 應用-成員管理-Peer的三角形關系，主要業務功能全部集中于Peer節點；

架構問題：由于peer節點承擔了太多的功能，所以帶來擴展性、可維護性、安全性、業務隔離等方面的諸多問題，所以0.6版本在推出后，并沒有大規模被行業使用，只是在一些零星的案例中進行業務驗證；

針對上述問題，1.0版本做了很大的改進和重構：

這是最新的1.0運行時架構：

1.0 架構要點：

分拆Peer的功能，將Blockchain的數據維護和共識服務進行分離，共識服務從Peer節點中完全分離出來，獨立為Orderer節點提供共識服務；

基于新的架構，實現多通道（channel）的結構，實現了更為靈活的業務適應性（業務隔離、安全性等方面）

支持更強的配置功能和策略管理功能，進一步增強系統的靈活性和適應性；

備注：最新的1.0版本中，上圖中的Membership服務已經改名為fabric-ca

• 1.0版本架構目標

從Fabric的新架構設計的建議文檔看，1.0版本的設計目標如下：

chaincode信任的靈活性：支持多個ordering服務節點，增強共識的容錯能力和對抗orderer作惡的能力

2. 擴展性： 將endorsement和ordering進行分離，實現多通道（實際是分區）結構，增強系統的擴展性；同時也將chaincode執行、ledger、state維護等非常消耗系統性能的任務與共識任務分離，保證了關鍵任務（ordering）的可靠執行

保密性：新架構對于chaincode在數據更新、狀態維護等方面提供了新的保密性要求，提高系統的業務、安全方面的能力

共識服務的模塊化：支持可插拔的共識結構，支持多種共識服務的接入和服務實現

• 架構特點

Hyperledger fabirc 1.0 版本的在0.6版本基礎上，針對安全、保密、部署、維護、實際業務場景需求等方面進行了很多改進，特別是Peer節點的功能分離，給系統架構具備了支持多通道、可插拔的共識的能力，使得Fabric脫離了0.6版本帶給人的青澀感（僅僅是個”驗證與演示“版的，呵呵），已經接近于工業應用的需求；

我們現在看看 1.0版本的關鍵架構：

• 多鏈與多通道

Fabric 1.0 的重要特征是支持多chain和多channel；

所謂的chain（鏈）實際上是包含Peer節點、賬本、ordering通道的邏輯結構，它將參與者與數據（包含chaincode在）進行隔離，滿足了不同業務場景下的”不同的人訪問不同數據“的基本要求。

同時，一個peer節點也可以參與到多個chain中（通過接入多個channel）；如下圖所示

關于通道：通道是有共識服務（ordering）提供的一種通訊機制，類似于消息系統中的發布-訂閱（PUB/SUB)中的topic；基于這種發布-訂閱關系，將peer和orderer連接在一起，形成一個個具有保密性的通訊鏈路（虛擬），實現了業務隔離的要求；通道也與賬本（ledger）-狀態（worldstate）緊密相關；如下圖所示：

共識服務與（P1、PN）、（P1、P2、P3）、（P2、P3）組成了三個相互獨立的通道，加入到不同通道的Peer節點能夠維護各個通道對應的賬本和狀態；也其實也對應現實世界中，不同業務場景下的參與方，例如銀行、保險公司；物流企業、生產企業等實體結構；我們可以看到channel機制實際上是的Fabric建模實際業務流程的能力大大增強了，大家可以發揮想象力去找到可能的應用領域

• 交易（數據）流程說明

新版本的架構變化導致新的交易流程的變化，我們簡述如下：

總體流程如下圖所示：

應用程序通過SDK發送請求道Peer節點（一個或多個）

peer節點分別執行交易（通過chaincode），但是并不將執行結果提交到本地的賬本中（可以認為是模擬執行，交易處于掛起狀態），參與背書的peer將執行結果返回給應用程序（其中包括自身對背書結果的簽名）

應用程序 收集背書結果并將結果提交給Ordering服務節點

Ordering服務節點執行共識過程并生成block，通過消息通道發布給Peer節點，由peer節點各自驗證交易并提交到本地的ledger中（包括state狀態的變化）

上述過程對應的執行序列圖如下：

在新的架構中，Peer節點負責維護區塊鏈的賬本（ledger）和狀態（State），本地的賬本稱為PeerLedger，其結構如下：

我們可以看到，整個區塊結構分為文件系統存儲的Block結構和數據庫維護的State狀態，其中state的存儲結構是可以替換的，可選的實現包括各種KV數據庫（LEVELDB，CouchDB等）；

上邊就是我們對Fabric 1.0版本的簡要介紹，由于Fabric的復雜性，后續我也會針對1.0版本中的技術細節和實現機制進行專題說明，敬請關注；

同時，1.0 版本的代碼和文檔每天都在更新，請大家關注官網和github，這里是最好學習天地。

最后說民一下大家比較關心的版本計劃：

• 1.0版本的版本計劃

下邊是劇透的官方開發計劃，只是“Proposed“，也許隨時會有變化哦：

從官方公布的計劃看，1.0版本應該可以在3月份完成release，讓我們期待這個最新版本的誕生吧。

總結

以上是生活随笔為你收集整理的Hyperledger Fabric1.0架构概览的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。