死磕hyperledger fabric源碼|Order節點概述
- 2021 年 2 月 27 日
- 筆記
- fabric源碼分析, Hyperledger Fabric, Order節點, 以太坊, 區塊鏈, 比特幣
死磕hyperledger fabric源碼|Order節點概述
文章及代碼：//github.com/blockchainGuide/
分支：v1.1.0
前言及源碼目錄
Orderer排序節點這塊內容主要包括了節點啟動流程、Broadcast廣播交易服務、Orderer共識排序服務以及Deliver區塊分發服務。其相關源碼目錄文件如下：
/orderer
|-common
|-blockcutter:交易切割打包模塊
|-bootstrap:引導啟動模塊，生成創世塊
|-broadcast:交易廣播服務模塊
|-localconfig:本地配置模塊
|-metadata：獲取元數據模塊
|-msgprocessor:消息處理器模塊
|-multichannel：多管道註冊管理器模塊
|-performance：性能測量模塊
|-server：Order排序服務器模塊
|-consensus
|-kafka:kafka共識組件模塊
|-solo:solo共識組件模塊
|-consensus.go:定義共識組件相關接口
|-main.go:orderer主程序
/common
|-deliver:定義Deliver服務器及處理器接口
/core
|-deliverservice
|-blocksprovider:區塊提供者模塊
|-client.go:提供broadcastClient客戶端
|-deliveryClient：Deliver服務客戶端
|-requester.go:請求區塊數據
/protos
|-orderer:protobuf消息定義模塊
主要功能
Orderer排序節點在Hyperledger Fabric系統架構中處於核心角色地位，管理着系統通道與所有應用通道，負責通道創建、通道配置更新等操作，並處理客戶端提交的交易消息請求，對交易進行排序並按規則打包成新區塊，提交賬本並維護通道賬本數據，為全網節點提供Broadcast交易廣播服務、Orderer共識排序服務、Deliver區塊分發服務等。通常，Hyperledger Fabric啟動時需要先啟動Orderer排序節點，創建系統通道提供正常服務後，再啟動其他角色的Peer節點進入正常工作狀態。其服務模塊關係與架構示如圖：
Orderer節點啟動後基於創世區塊初始化系統通道，創建Orderer排序服務器，封裝了Broadcast服務處理句柄、Deliver服務處理句柄與多通道註冊管理器對象，並提供Broadcast()交易廣播服務接口與 Deliver()區塊分發服務接口。
其中，Orderer排序服務器基於Broadcast()接口接收交易廣播服務請求，調用Broadcast服務處理句柄的Handle()方法進行處理，建立消息處理循環，接收與處理客戶端提交的普通交易消息、配置交易消息等請求消息，經過濾後發送至通道綁定的共識組件鏈對象（Solo類型、Kafka類型等）進行排序。接着，再將排序後的交易添加到本地待處理的緩存交易消息列表，並按照交易出塊規則構造新區塊，提交到Orderer節點指定通道賬本的區塊數據文件中，同時負責創建新的應用通道、更新通道配置等通道管理工作。目前，Orderer排序服務器負責接收與處理兩類交易消息，具體如下。
-
配置交易消息（ConfigMsg）：通道頭部類型是
CONFIG_UPDATE的通道配置交易消息，含有最新的通道配置信息，經過通道消息處理器過濾後，轉換為通道頭部類型為ORDERER_TRANSACTION或CONFIG的配置交易消息（Envelope類型），分別用於創建新的應用通道或更新通道配置，同時，將通道配置交易消息單獨打包成新區塊，並提交到系統通道賬本與應用通道賬本。 -
普通交易消息（NormalMsg）：通道頭部類型是
ENDORSER_TRANSACTION等的標準交易消息（經過Endorser背書的交易消息或其他非配置交易消息），含有改變世界狀態的模擬執行結果讀寫集，經過Endorser節點簽名背書後打包發送到Orderer節點請求處理，經過通道消息處理器過濾後，將合法交易提交到共識組件鏈對象進行排序，再按照交易出塊規則（出塊時間周期、打包最大交易數量、區塊位元組數限制等）生成新區塊，並提交到通道賬本。
同時，Orderer排序服務器提供Deliver()區塊分發服務接口，將接收的服務請求交由Deliver服務處理句柄的Handle()方法處理，建立消息處理循環，負責接收與處理客戶端提交的區塊請求消息，封裝了指定區塊請求範圍的區塊搜索信息（SeekInfo類型）。接着，Deliver服務處理句柄循環從本地賬本獲取區塊數據，依次發送給請求節點（如Leader主節點）。如果賬本中還未生成指定區塊，則Deliver服務處理句柄默認一直阻塞等待，直到該區塊創建完成並提交賬本後再回復給請求節點。
另外，Orderer排序服務器還提供了多通道註冊管理器Registrar對象，負責管理系統通道與所有應用通道，封裝了所有通道的鏈支持對象字典、共識組件字典、區塊賬本工廠對象等組件，維護所有通道上的通道配置、區塊賬本對象、共識組件等核心資源，創建通道上的共識組件鏈對象提供Orderer共識排序服務，負責對交易消息排序，切割打包構造新區塊並提交賬本，同時負責創建新的應用通道與更新通道配置，其相當於Orderer節點上的「資源管理器」。
實際上，Orderer排序服務器上的通道共識組件鏈對象利用Golang通道（Solo共識組件）或Kafka集群（Kafka共識組件）作為共識排序後端，對經過通道消息處理器過濾的合法交易消息進行排序，對交易順序等達成一致性觀點。同時，在新通道創建時或啟動恢復現有通道時，啟動通道綁定的鏈支持對象以及共識組件鏈對象，構建交易消息處理循環，接收共識組件已經完成排序的交易消息，並添加到本地待處理的緩存交易消息列表中，包括配置交易消息、普通交易消息等，採用相互獨立的消息處理流程分別處理 。
注意，目前Orderer節點賬本只包括區塊數據文件與區塊索引數據庫，負責保存區塊數據即公有數據（包含公共數據與隱私數據哈希值），不存在狀態數據庫、歷史數據庫、隱私數據庫等。不同於Peer節點，Orderer節點在提交區塊到本地賬本前不需要驗證交易背書策略與執行MVCC檢查，也不保存任何隱私數據（明文），只負責存儲所有通道賬本上的區塊數據。
