死磕hyperledger fabric原始碼|Order節點概述
文章及程式碼：https://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檢查，也不儲存任何隱私資料（明文），只負責儲存所有通道賬本上的區塊資料。