一、Fabric架構
二、Fabric網絡
三、Fabric模塊
四、Fabric交易流
根據Hyperledger Fabric 1.0架構，Fabric交易的整個生命週期可以分爲7個階段。如下圖反應了交易的整個生命週期以及交易於賬本的交互。
（1）在交易的第一階段，客戶端應用發起智能合約A的一個交易請求給背書節點E0。智能合約A配置的背書策略要求只需要E0,E1和E2簽名。其他節點不包含在策略的要求中，因此可以不簽名。注意圖中的紅色和藍色小矩形塊分別代表不同的子鏈或者叫通道，這個通道是1.0架構引入的新概念，用來實現各條業務鏈的數據隔離，保護交易的隱私性，避免像比特幣那樣的交易對所有人都公開。
如圖所示，這裏說明一下，圖中的C代表共識網絡（Consensus Network）,黃色的圓角矩形表示在peer上部署的智能合約。如E0，E1，E2上部署了A，B兩個智能合約，E3上部署了A，D兩個智能合約，而E4，E5上部署了Y，Z兩個智能合約
（2）背書節點E0使用 MSP（MSP=Member Service Provider）驗證簽名，判斷是否客戶端應用被正確授權可以執行發起交易請求。背書節點獲取交易請求中的參數（鏈代碼）作爲輸入參數，然後E0會與交易對應ChainCode所屬的docker實例通信，併爲其提供模擬執行的State Database的讀寫集，也就是說ChainCode會執行完智能合約中的業務邏輯，但是並不會在stub.PutState的時候寫數據庫，ChainCode所屬的docker實例執行完ChainCode後產生交易執行結果，然後將執行結構返回給E0。這個執行結果包括下列數據：響應值，讀集合和寫集合。不過，這個時候，並不會更新賬本。這些值的集合，連同背書節點的簽名和一個YES/NO 的陳述一起放到 proposal response 中返回給客戶端應用（圖中的Client App）。
（3）客戶端應用驗證背書節點簽名，然後繼續發送背書請求給E1和E2，過程跟與E0的交互時一樣。
（4）背書節點E1和E2發送背書處理結果給客戶端應用。客戶端應用收集完所有背書節點的簽名後，檢查是否指定的背書策略已經滿足。根據 Fabric 的架構設計，即使應用選擇不檢查交易的背書反饋，或者繼續發送一個沒有經過背書處理的交易，在commit交易的驗證階段，這個背書策略仍然會被peer 強制執行。
（5）客戶端應用將交易和響應信息封裝到一個事務消息（transaction message）中，然後廣播到共識網絡（這裏的共識網絡又稱爲排序服務Ordering Service，後續統一稱爲共識網絡）。交易中包含讀寫集，背書節點簽名和通道 ID。
共識網絡節點不會關注交易細節和交易消息的具體內容，只是簡單地從網絡中接收來自所有通道的交易，然後按通道按時間順序排序，處理的結果是一個Batch的交易，也就是一個區塊，這個區塊的產生有兩種情況，一種情況是區塊中的交易很多，區塊的大小達到了配置文件中配置的大小，而另一種情況是區塊中的交易很少，沒有達到配置的大小，那麼共識網絡節點就會等，等到大小足夠大或者超時時間。這些設置是在configtx.yaml（/hyperledger/fabric/blob/release/sampleconfig/configtx.yaml）中配置的。
# Batch
Timeout: The amount of time to wait before creating a batch.
BatchTimeout: 2s
# Batch Size:
Controls the number of messages batched into a block.
BatchSize:
# Max Message
Count: The maximum number of messages to permit in a
# batch.
MaxMessageCount:
10
# Absolute Max Bytes: The absolute
maximum number of bytes allowed for
# the serialized messages in a batch.
If the "kafka" OrdererType is
# selected, set 'message.max.bytes' and
'replica.fetch.max.bytes' on the
# Kafka brokers to a value that is
larger than this one.
AbsoluteMaxBytes: 10 MB
# Preferred Max Bytes: The preferred
maximum number of bytes allowed for
# the serialized messages in a batch. A
message larger than the
# preferred max bytes will result in a
batch larger than preferred max
# bytes.
PreferredMaxBytes: 512 KB
# Max
Channels is the maximum number of channels to allow on the ordering
# network.
When set to 0, this implies no maximum number of channels.
MaxChannels:
0
這裏主要的配置項是BatchTimeout和MaxMessageCount。
BatchTimeout是配置多久產生一個區塊，默認是2秒，通常在項目實踐中，我們發現交易量並不大，如果配置的時間過小就會產生很多空的區塊，配置時間太長，則發現等待產生區塊的時間太長。具體時間由交易頻率和業務量決定。我們實際項目中，通常配置在30秒。
MaxMessageCount是配置在一個區塊中允許的交易數的最大值。默認值是10。交易數設置過小，導致區塊過多，增加orderer的負擔，因爲要orderer要不斷的打包區塊，然後deliver給通道內的所有peer,這樣還容易增加網絡負載，引起網絡擁堵。我們實際項目中通常配置500，不過具體還應該看業務情況，因爲如果每個交易包含的數據的size如果太大，那麼500個交易可能導致一個區塊太大，因此需要根據實際業務需求權衡。
（6）共識服務節點將打包的區塊廣播道同一個通道的所有peer，通過Fabric提供的deliver RPC服務，共識服務節點和peer節點之間的通信細節，暫不詳細介紹。必須說明的是，E4和E5不在同樣的通道上（或者說不屬於同樣的子賬本），因此E4,E5不會收到任何更新消息。另外，共識網絡節點只是涉及到排序交易和打包區塊，不會執行智能合約。
（7）Peers收到共識網絡發來的區塊後，會先進行以下校驗：
- 再次驗證區塊中的交易以確保背書策略滿足。
- 檢查區塊的數據是否正確。
- 對每個交易進行驗證，確保自從讀集合數據在交易執行生成後，讀集合變量對應的賬本的狀態沒有變化，也就是驗證交易中的讀寫數據集是否與State Database的數據版本一致。
驗證通過後，區塊中的交易打上合法和非法交易的標籤，然後添加區塊到通道對應的鏈上，同時把所有驗證通過的交易的讀寫集中的寫的部分寫入狀態數據庫State Database。對於每個合法交易，寫集合被提交到當前的狀態數據庫。同時，一個區塊事件產生併發出，通知客戶應用，交易已經不可更改的添加到了鏈上，也是告訴應用客戶端，交易是合法還是非法。
另外對於區塊鏈，本身是文件系統，不是數據庫，所有也會有把區塊中的數據在LevelDB中建立索引。
