Hyperledger Fabric Ordering Service過程

排序服務在超級帳本 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，則發送分塊消息 TTC-X 到 Kafka。
• Kafka 集羣維護多個 topic 分區。Kakfa 經過共識算法來確保寫入到分區後的消息的一致性。即一旦寫入分區，任何 Orderer 節點看到的都是相同的消息隊列。
• Orderer 節點在啓動後，還默認對本地帳本對應的 Kafka 分區數據進行監聽，不斷從 Kafka 拉取（Consume）新的交易消息，並對消息進行處理。知足必定策略狀況下（收到 TTX-C 或配置消息）還會將消息打包爲區塊。

分塊決策

收到分塊消息 TTC-X，或收到配置交易，則切分以前從 Kafka 中收到的消息爲區塊，記錄到本地帳本結構中。

 

來源：https://github.com/yeasy/hyperledger_code_fabric/blob/master/process/orderer_workflow.md