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的操作：
- 抽取远程地址信息，
addr := util.ExtractRemoteAddress(srv.Context()) - 接收消息，
msg, err := srv.Recv() - 获取BroadcastSupport,
chdr, isConfig, processor, err := bh.sm.BroadcastChannelSupport(msg) - 按照当前配置检查该msg是否合法
configSeq, err := processor.ProcessNormalMsg(msg) - 对交易进行排序，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内部实现逻辑如下：
- 解析客户端地址并反序列化消息内容并提取头部信息:
addr := util.ExtractRemoteAddress(srv.Context())
payload, err := utils.UnmarshalPayload(envelope.Payload)
chdr, err := utils.UnmarshalChannelHeader(payload.Header.ChannelHeader)
- 获取对应channel的服务组件
chain, ok := ds.sm.GetChain(chdr.ChannelId)
- 读取所需的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)
- 循环读取DB中的block并返回给客户端。
至此Broadcast和Deliver的接口大致流程分析完毕。
网友评论