> 死磕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`檢查，也不儲存任何隱私資料（明文），只負責儲存所有通道賬本上的區塊資料。 ## 參考 > https://github.com/blockchai