死磕hyperledger fabric源碼|Order節(jié)點概述
文章及代碼：https://github.com/blockchainGuide/
分支：v1.1.0
前言及源碼目錄
Orderer排序節(jié)點這塊內(nèi)容主要包括了節(jié)點啟動流程涯保、Broadcast廣播交易服務(wù)堡牡、Orderer共識排序服務(wù)以及Deliver區(qū)塊分發(fā)服務(wù)朵诫。其相關(guān)源碼目錄文件如下：
/orderer
|-common
? |-blockcutter:交易切割打包模塊 ??????
? |-bootstrap:引導(dǎo)啟動模塊，生成創(chuàng)世塊 ??????
? |-broadcast:交易廣播服務(wù)模塊 ??????
? |-localconfig:本地配置模塊
? |-metadata：獲取元數(shù)據(jù)模塊
? |-msgprocessor:消息處理器模塊
? |-multichannel：多管道注冊管理器模塊
? |-performance：性能測量模塊
? |-server：Order排序服務(wù)器模塊 ??????
|-consensus
? |-kafka:kafka共識組件模塊 ??????
? |-solo:solo共識組件模塊
? |-consensus.go:定義共識組件相關(guān)接口
|-main.go:orderer主程序
/common
|-deliver:定義Deliver服務(wù)器及處理器接口 ??????
/core
|-deliverservice
? |-blocksprovider:區(qū)塊提供者模塊 ??????
? |-client.go:提供broadcastClient客戶端 ??????
? |-deliveryClient：Deliver服務(wù)客戶端 ??????
? |-requester.go:請求區(qū)塊數(shù)據(jù) ??????
/protos
|-orderer:protobuf消息定義模塊
主要功能
Orderer排序節(jié)點在Hyperledger Fabric系統(tǒng)架構(gòu)中處于核心角色地位誉券，管理著系統(tǒng)通道與所有應(yīng)用通道，負(fù)責(zé)通道創(chuàng)建诞丽、通道配置更新等操作鹉勒，并處理客戶端提交的交易消息請求磅轻，對交易進(jìn)行排序并按規(guī)則打包成新區(qū)塊珍逸，提交賬本并維護(hù)通道賬本數(shù)據(jù)，為全網(wǎng)節(jié)點提供Broadcast交易廣播服務(wù)聋溜、Orderer共識排序服務(wù)谆膳、Deliver區(qū)塊分發(fā)服務(wù)等。通常撮躁，Hyperledger Fabric啟動時需要先啟動Orderer排序節(jié)點漱病，創(chuàng)建系統(tǒng)通道提供正常服務(wù)后，再啟動其他角色的Peer節(jié)點進(jìn)入正常工作狀態(tài)。其服務(wù)模塊關(guān)系與架構(gòu)示如圖：
Orderer節(jié)點啟動后基于創(chuàng)世區(qū)塊初始化系統(tǒng)通道杨帽，創(chuàng)建Orderer排序服務(wù)器漓穿，封裝了Broadcast服務(wù)處理句柄、Deliver服務(wù)處理句柄與多通道注冊管理器對象注盈，并提供Broadcast()交易廣播服務(wù)接口與 Deliver()區(qū)塊分發(fā)服務(wù)接口晃危。
其中，Orderer排序服務(wù)器基于Broadcast()接口接收交易廣播服務(wù)請求当凡，調(diào)用Broadcast服務(wù)處理句柄的Handle()方法進(jìn)行處理山害，建立消息處理循環(huán)，接收與處理客戶端提交的普通交易消息沿量、配置交易消息等請求消息，經(jīng)過濾后發(fā)送至通道綁定的共識組件鏈對象（Solo類型冤荆、Kafka類型等）進(jìn)行排序朴则。接著，再將排序后的交易添加到本地待處理的緩存交易消息列表钓简，并按照交易出塊規(guī)則構(gòu)造新區(qū)塊乌妒，提交到Orderer節(jié)點指定通道賬本的區(qū)塊數(shù)據(jù)文件中，同時負(fù)責(zé)創(chuàng)建新的應(yīng)用通道外邓、更新通道配置等通道管理工作撤蚊。目前，Orderer排序服務(wù)器負(fù)責(zé)接收與處理兩類交易消息损话，具體如下侦啸。
配置交易消息（ConfigMsg）：通道頭部類型是
CONFIG_UPDATE的通道配置交易消息，含有最新的通道配置信息丧枪，經(jīng)過通道消息處理器過濾后光涂，轉(zhuǎn)換為通道頭部類型為ORDERER_TRANSACTION或CONFIG的配置交易消息（Envelope類型），分別用于創(chuàng)建新的應(yīng)用通道或更新通道配置拧烦，同時忘闻，將通道配置交易消息單獨打包成新區(qū)塊，并提交到系統(tǒng)通道賬本與應(yīng)用通道賬本恋博。-
普通交易消息（NormalMsg）：通道頭部類型是
ENDORSER_TRANSACTION等的標(biāo)準(zhǔn)交易消息（經(jīng)過Endorser背書的交易消息或其他非配置交易消息）齐佳，含有改變世界狀態(tài)的模擬執(zhí)行結(jié)果讀寫集，經(jīng)過Endorser節(jié)點簽名背書后打包發(fā)送到Orderer節(jié)點請求處理债沮，經(jīng)過通道消息處理器過濾后炼吴，將合法交易提交到共識組件鏈對象進(jìn)行排序，再按照交易出塊規(guī)則（出塊時間周期秦士、打包最大交易數(shù)量缺厉、區(qū)塊字節(jié)數(shù)限制等）生成新區(qū)塊，并提交到通道賬本。
同時提针，Orderer排序服務(wù)器提供Deliver()區(qū)塊分發(fā)服務(wù)接口命爬，將接收的服務(wù)請求交由Deliver服務(wù)處理句柄的Handle()方法處理，建立消息處理循環(huán)辐脖，負(fù)責(zé)接收與處理客戶端提交的區(qū)塊請求消息饲宛，封裝了指定區(qū)塊請求范圍的區(qū)塊搜索信息（SeekInfo類型）。接著嗜价，Deliver服務(wù)處理句柄循環(huán)從本地賬本獲取區(qū)塊數(shù)據(jù)艇抠，依次發(fā)送給請求節(jié)點（如Leader主節(jié)點）。如果賬本中還未生成指定區(qū)塊久锥，則Deliver服務(wù)處理句柄默認(rèn)一直阻塞等待家淤，直到該區(qū)塊創(chuàng)建完成并提交賬本后再回復(fù)給請求節(jié)點。
另外瑟由，Orderer排序服務(wù)器還提供了多通道注冊管理器Registrar對象絮重，負(fù)責(zé)管理系統(tǒng)通道與所有應(yīng)用通道，封裝了所有通道的鏈支持對象字典歹苦、共識組件字典青伤、區(qū)塊賬本工廠對象等組件，維護(hù)所有通道上的通道配置殴瘦、區(qū)塊賬本對象狠角、共識組件等核心資源，創(chuàng)建通道上的共識組件鏈對象提供Orderer共識排序服務(wù)蚪腋，負(fù)責(zé)對交易消息排序丰歌，切割打包構(gòu)造新區(qū)塊并提交賬本，同時負(fù)責(zé)創(chuàng)建新的應(yīng)用通道與更新通道配置辣吃，其相當(dāng)于Orderer節(jié)點上的“資源管理器”动遭。
實際上，Orderer排序服務(wù)器上的通道共識組件鏈對象利用Golang通道（Solo共識組件）或Kafka集群（Kafka共識組件）作為共識排序后端神得，對經(jīng)過通道消息處理器過濾的合法交易消息進(jìn)行排序厘惦，對交易順序等達(dá)成一致性觀點。同時哩簿，在新通道創(chuàng)建時或啟動恢復(fù)現(xiàn)有通道時宵蕉，啟動通道綁定的鏈支持對象以及共識組件鏈對象，構(gòu)建交易消息處理循環(huán)节榜，接收共識組件已經(jīng)完成排序的交易消息羡玛，并添加到本地待處理的緩存交易消息列表中，包括配置交易消息宗苍、普通交易消息等稼稿，采用相互獨立的消息處理流程分別處理 薄榛。
注意，目前Orderer節(jié)點賬本只包括區(qū)塊數(shù)據(jù)文件與區(qū)塊索引數(shù)據(jù)庫让歼，負(fù)責(zé)保存區(qū)塊數(shù)據(jù)即公有數(shù)據(jù)（包含公共數(shù)據(jù)與隱私數(shù)據(jù)哈希值）敞恋，不存在狀態(tài)數(shù)據(jù)庫、歷史數(shù)據(jù)庫谋右、隱私數(shù)據(jù)庫等硬猫。不同于Peer節(jié)點，Orderer節(jié)點在提交區(qū)塊到本地賬本前不需要驗證交易背書策略與執(zhí)行MVCC檢查改执，也不保存任何隱私數(shù)據(jù)（明文）啸蜜，只負(fù)責(zé)存儲所有通道賬本上的區(qū)塊數(shù)據(jù)。
