Hyperledger 源碼分析之 Fabric
排序服務在超級賬本 Fabric 網絡中起到十分核心的作用。所有交易在發送給 Committer 進行驗證接受之前，需要先經過排序服務進行全局排序。
在目前架構中，排序服務的功能被抽取出來，作為單獨的 fabric-orderer 子產品來實作，代碼主要在
fabric/orderer
目錄下。
下面以 Kafka 作為共識插件為例，講解 Orderer 節點的核心過程。
工作原理
Orderer 節點（Ordering Service Node，OSN）在網絡中起到代理作用，多個 Orderer 節點會連接配接到 Kafka 叢集，利用 Kafka 的共識功能，完成對網絡中交易的排序和打包成區塊的工作。
Fabric 網絡提供了多通道特性，為了支援這一特性，同時保障每個 Orderer 節點上資料的一緻性，排序服務進行了一些特殊設計。
對于每個通道，Orderer 将其映射到 Kafka 叢集中的一個 topic （topic 名稱與 channelID 相同）上。由于 Orderer 目前并沒有使用 Kafka Topic 的多分區負載均衡特性，預設每個 topic 隻建立了一個分區（0 号分區）。
此外，Orderer 還在本地維護了針對每個通道的賬本（區塊鍊）結構，其中每個區塊包括了一組排序後的交易消息，并且被分割為獨立區塊。
核心過程
核心過程如下所示。
- 用戶端通過 gRPC 連接配接發送交易資訊到 Orderer 節點的
Broadcast()
- Orderer 節點收到請求後，提取消息進行解析、檢查，通過檢查後封裝為 Kafka 消息，通過 Produce 接口發送到 Kakfa 叢集對應的 topic 分區中。目前消息數達到
BatchSize.MaxMessageCount
BatchTimeout
- Kafka 叢集維護多個 topic 分區。Kakfa 通過共識算法來確定寫入到分區後的消息的一緻性。即一旦寫入分區，任何 Orderer 節點看到的都是相同的消息隊列。
- Orderer 節點在啟動後，還預設對本地賬本對應的 Kafka 分區資料進行監聽，不斷從 Kafka 拉取（Consume）新的交易消息，并對消息進行處理。滿足一定政策情況下（收到 TTX-C 或配置消息）還會将消息打包為區塊。
分塊決策
收到分塊消息 TTC-X，或收到配置交易，則切分消息為區塊。
===== 關于 TechFirst 公衆号 =====
專注金融科技、人工智能、雲計算、大資料相關領域的熱門技術與前瞻方向。
發送關鍵詞（如區塊鍊、雲計算、大資料、容器），擷取熱門點評與技術幹貨。
歡迎投稿！
