[Fabric/源码分析]Order服务原理浅析(v1.0)

96
bitking
2017.08.30 16:04* 字数 1018

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)
  1. 获取对应channel的服务组件
chain, ok := ds.sm.GetChain(chdr.ChannelId)
  1. 读取所需的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)
  1. 循环读取DB中的block并返回给客户端。

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

Fabric技术研究
Web note ad 1