Order組件即Fabric區塊鏈的共識服務，負責對不同Client發送的交易進行排序，Order組件的現版本中有Solo模式和Kafka兩種實現（Solo模式太簡單僅適用于開發模式，本文后面所述均針對基于Kafka的實現），本文將結合源碼分析闡述Order組件的架構及其運行原理。

1. 整體架構分析

首先我們來了解一下官方的架構設計圖，如下圖該架構使用Kafka集群提供排序服務及其容錯性。這種排序服務包括多個Order節點（OSN）以及Kafka集群組成，排序服務Client可以連接多個OSN但是OSN節點互相不通訊。

圖1. 基于Kafka實現的排序服務

排序服務的基本工作原理是這樣的：

• 排序服務Client向OSN發送交易；
• OSN節點對交易進行相關檢查，符合條件之后會將交易發送給Kafka集群；
• OSN節點從Kafka集群拉取交易消息并對交易消息進行打包將打包之后的交易batch寫入本地數據庫；
• OSN節點按客戶端Deliver請求從本地數據庫讀取區塊返回；

這種設計主要利用了Kafka的兩個特性（如下圖所示），1. 發送到Kafka的消息會按序存儲并且保證消費者能夠按序消費；2. Kafka允許對消息進行分類按照消息的Topic進行分區，分區內部消息依然有序；

圖2. Kafka分區排序

其中特性1幫助Fabric實現了多節點交易的順序一致性，特性2幫助Fabric實現了多通道架構(Kafka的消費者可以選擇訂閱其感興趣的Topic);

Fabric的這種Order的設計個人感覺好處在于極大的發揮了Kafka的高可擴展、高可用以及順序一致性。然而劣勢也比較明顯，首先Kafka以及OSN的節點對Fabric網絡來說是一個中心化存在違背了去中心化的區塊鏈宗旨，其次Kafka以及OSN中保存所有的交易信息，對隱私保護不是很好；最后Kafka的一致性協議不能容忍拜占庭錯誤在安全性上和類PBFT算法相比較弱；最后的最后就是這種架構極大增加了新手入門以及運營維護的成本。

2. 關鍵接口分析

OSN為一個獨立的組件也是通過gRPC的方式對外提供服務，其主要有兩個服務接口, 其中Broadcast接口用于接收Client的排序請求，Deliver是在排序之后給Client發送的流式Blocks.

service AtomicBroadcast { 
    rpc Broadcast(stream common.Envelope) returns (stream BroadcastResponse) {}
    rpc Deliver(stream common.Envelope) returns (stream DeliverResponse) {}
}

如下圖所示是實現這兩個接口的相關類圖，其中Server是OSN的啟動入口，其實現了Order提供的兩個服務Broadcast和Deliver。Broadcast和Deliver又是通過broadcast.go和deliver.go中的Handle方法具體實現。

圖3. 關鍵接口相關類圖

Broadcast的具體實現如下，broadcast.go的Handle方法中開啟一個循環進行如下2~4的操作：

1. 抽取遠程地址信息，addr := util.ExtractRemoteAddress(srv.Context())
2. 接收消息，msg, err := srv.Recv()
3. 獲取BroadcastSupport,
   chdr, isConfig, processor, err := bh.sm.BroadcastChannelSupport(msg)
4. 按照當前配置檢查該msg是否合法
   configSeq, err := processor.ProcessNormalMsg(msg)
5. 對交易進行排序，Kafka的實現是將交易盡心序列化并發送到Kafka集群

marshaledEnv, err := utils.Marshal(env)
if err != nil {
  logger.Errorf("[channel: %s] cannot enqueue, unable to marshal envelope = %s", chain.support.ChainID(), err)
                return false
}
            // We're good to go
payload := utils.MarshalOrPanic(newRegularMessage(marshaledEnv))
message := newProducerMessage(chain.channel, payload)
if _, _, err := chain.producer.SendMessage(message); err != nil {...}

Deliver的實現同樣也是在Handle方法中開啟一個服務，如下讀取來自客戶端的Deliver請求并執行deliverBlocks操作。

for {
        logger.Debugf("Attempting to read seek info message from %s", addr)
        envelope, err := srv.Recv()
        if err == io.EOF {
            logger.Debugf("Received EOF from %s, hangup", addr)
            return nil
        }
        if err != nil {
            logger.Warningf("Error reading from %s: %s", addr, err)
            return err
        }
        if err := ds.deliverBlocks(srv, envelope); err != nil {
            return err
        }
        logger.Debugf("Waiting for new SeekInfo from %s", addr)
    }

deliverBlocks內部實現邏輯如下：

1. 解析客戶端地址并反序列化消息內容并提取頭部信息:

addr := util.ExtractRemoteAddress(srv.Context())
payload, err := utils.UnmarshalPayload(envelope.Payload)
chdr, err := utils.UnmarshalChannelHeader(payload.Header.ChannelHeader)

2. 獲取對應channel的服務組件

chain, ok := ds.sm.GetChain(chdr.ChannelId)

3. 讀取所需的block的索引信息

    seekInfo := &ab.SeekInfo{}
    if err = proto.Unmarshal(payload.Data, seekInfo); err != nil {
        logger.Warningf("[channel: %s] Received a signed deliver request from %s with malformed seekInfo payload: %s", chdr.ChannelId, addr, err)
        return sendStatusReply(srv, cb.Status_BAD_REQUEST)
    }

    if seekInfo.Start == nil || seekInfo.Stop == nil {
        logger.Warningf("[channel: %s] Received seekInfo message from %s with missing start or stop %v, %v", chdr.ChannelId, addr, seekInfo.Start, seekInfo.Stop)
        return sendStatusReply(srv, cb.Status_BAD_REQUEST)
    }

    logger.Debugf("[channel: %s] Received seekInfo (%p) %v from %s", chdr.ChannelId, seekInfo, seekInfo, addr)

    cursor, number := chain.Reader().Iterator(seekInfo.Start)

4. 循環讀取DB中的block并返回給客戶端。

至此Broadcast和Deliver的接口大致流程分析完畢。