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，讓我們期待這個最新版本的誕生吧。
