Fabric架構
Faric網絡
Fabric模塊
Fabric交易流
根據Hyperledger Fabric 1.0架構，Fabric交易的整個生命週期可以分爲7個階段。我們可以從一個簡單的例子分析下Fabric交易的7個階段，然後讀者可以清晰的理解每個環節，每個處理過程，這可以幫助開發人員理解Fabric的架構體系，只有深刻理解了Fabric的架構設計原理，在開發過程中遇到問題才能快速解決。
如下圖反應了交易的整個生命週期以及交易於賬本的交互。
第一階段
在交易的第一階段，客戶端應用發起智能合約A的一個交易請求給背書節點E0。智能合約A配置的背書策略要求只需要E0,E1和E2簽名。其他節點不包含在策略的要求中，因此可以不簽名。注意圖中的紅色和藍色小矩形塊分別代表不同的子鏈或者叫通道，這個通道是1.0架構引入的新概念，用來實現各條業務鏈的數據隔離，保護交易的隱私性，避免像比特幣那樣的交易對所有人都公開。
如圖所示，這裏說明一下，圖中的C代表共識網絡（Consensus Network）,黃色的圓角矩形表示在peer上部署的智能合約。如E0，E1，E2上部署了A，B兩個智能合約，E3上部署了A，D兩個智能合約，而E4，E5上部署了Y，Z兩個智能合約。
第二階段
背書節點E0使用 MSP（MSP=Member Service Provider）驗證簽名，判斷是否客戶端應用被正確授權可以執行發起交易請求。背書節點獲取交易請求中的參數（鏈代碼）作爲輸入參數，然後E0會與交易對應ChainCode所屬的docker實例通信，併爲其提供模擬執行的State Database的讀寫集，也就是說ChainCode會執行完智能合約中的業務邏輯，但是並不會在stub.PutState的時候寫數據庫，ChainCode所屬的docker實例執行完ChainCode後產生交易執行結果，然後將執行結構返回給E0。這個執行結果包括下列數據：響應值，讀集合和寫集合。不過，這個時候，並不會更新賬本。這些值的集合，連同背書節點的簽名和一個YES/NO 的陳述一起放到 proposal response 中返回給客戶端應用（圖中的Client App）。
第三階段
客戶端應用驗證背書節點簽名，然後繼續發送背書請求給E1和E2，過程跟與E0的交互時一樣。
第四階段
背書節點E1和E2發送背書處理結果給客戶端應用。客戶端應用收集完所有背書節點的簽名後，檢查是否指定的背書策略已經滿足。根據 Fabric 的架構設計，即使應用選擇不檢查交易的背書反饋，或者繼續發送一個沒有經過背書處理的交易，在commit交易的驗證階段，這個背書策略仍然會被peer 強制執行。
第五階段
客戶端應用將交易和響應信息封裝到一個事務消息（transaction message）中，然後廣
播到共識網絡（這裏的共識網絡又稱爲排序服務Ordering Service，後續統一稱爲共識網絡）。交易中包含讀寫集，背書節點簽名和通道 ID。
共識網絡節點不會關注交易細節和交易消息的具體內容，只是簡單地從網絡中接收來自所有通道的交易，然後按通道按時間順序排序，處理的結果是一個Batch的交易，也就是一個區塊，這個區塊的產生有兩種情況，一種情況是區塊中的交易很多，區塊的大小達到了配置文件中配置的大小，而另一種情況是區塊中的交易很少，沒有達到配置的大小，那麼共識網絡節點就會等，等到大小足夠大或者超時時間。這些設置是在configtx.yaml中配置的。
開發人員如果要自定義出塊的時間和每個區塊內交易的數量，可以參考文檔：
https://link.zhihu.com/?target=https%3A//github.com/hyperledger/fabric/blob/release/sampleconfig/configtx.yaml
主要的相關的配置項如下：
這裏主要的配置項是BatchTimeout和MaxMessageCount。
BatchTimeout是配置多久產生一個區塊，默認是2秒，通常在項目實踐中，我們發現交易量並不大，如果配置的時間過小就會產生很多空的區塊，配置時間太長，則發現等待產生區塊的時間太長。具體時間由交易頻率和業務量決定。我們實際項目中，通常配置在30秒。
MaxMessageCount是配置在一個區塊中允許的交易數的最大值。默認值是10。交易數設置過小，導致區塊過多，增加orderer的負擔，因爲要orderer要不斷的打包區塊，然後deliver給通道內的所有peer,這樣還容易增加網絡負載，引起網絡擁堵。我們實際項目中通常配置500，不過具體還應該看業務情況，因爲如果每個交易包含的數據的size如果太大，那麼500個交易可能導致一個區塊太大，因此需要根據實際業務需求權衡。
讀者可能有一個疑問，這裏有2個參數可以配置區塊的出塊策略，那麼究竟那個因素優先發生作用呢？實際上根據Fabric設計的出塊策略，BatchTimeout和MaxMessageCount的任何一個參數條件滿足，都會觸發產生新的區塊。舉個例子，假設我們配置了出塊時間BatchTimeout爲30秒，塊內交易最大數量MaxMessageCount爲500。第一種情況，當出塊時間爲20秒(時間上還沒達到出塊要求)，但是交易數已經累積到500個了，這個時候也會觸發新的區塊產生。第二種情況，交易數才1個，但是出塊時間已經30秒了，這個時間也會觸發新的區塊產生，儘管這個新的區塊裏只有一個交易。
Fabric的這種出塊策略設計相比還是比較靈活的，可配置的。相比而言，在比特幣中，大家都知道出塊機制是固定的，就是每隔10分鐘（600秒）產生一個區塊，就一個陌生，不可更改。而以太坊類似，也是基於事件的出塊策略，只是時間更短，每15秒產生一個區塊。因此，Fabric的出塊策略在設計上還是比較進步的。
第六階段
共識服務節點將打包的區塊廣播道同一個通道的所有peer，通過Fabric提供的deliver RPC服務，共識服務節點和peer節點之間的通信細節，我們在稍後詳細介紹。必須說明的是，E4和E5不在同樣的通道上（或者說不屬於同樣的子賬本），因此E4,E5不會收到任何更新消息。另外，共識網絡節點只是涉及到排序交易和打包區塊，不會執行智能合約。
第七階段
Peers收到共識網絡發來的區塊後，會先進行以下校驗：
n 再次驗證區塊中的交易以確保背書策略滿足。
n 檢查區塊的數據是否正確。
n 對每個交易進行驗證，確保自從讀集合數據在交易執行生成後，讀集合變量對應的賬本的狀態沒有變化，也就是驗證交易中的讀寫數據集是否與State Database的數據版本一致。
驗證通過後，區塊中的交易打上合法和非法交易的標籤，然後添加區塊到通道對應的鏈上，同時把所有驗證通過的交易的讀寫集中的寫的部分寫入狀態數據庫State Database。對於每個合法交易，寫集合被提交到當前的狀態數據庫。同時，一個區塊事件產生併發出，通知客戶應用，交易已經不可更改的添加到了鏈上，也是告訴應用客戶端，交易是合法還是非法。
另外對於區塊鏈，本身是文件系統，不是數據庫，所有也會有把區塊中的數據在LevelDB中建立索引。
作者：vdes
鏈接：https://www.jianshu.com/p/8e2fa2b5a0b2
來源：簡書
