- Hyperledger Fabric技术内幕:架构设计与实现原理
- 李鑫
- 1719字
- 2024-11-01 23:50:55
2.1 功能概述
Orderer排序节点在Hyperledger Fabric系统架构中处于核心角色地位,管理着系统通道与所有应用通道,负责通道创建、通道配置更新等操作,并处理客户端提交的交易消息请求,对交易进行排序并按规则打包成新区块,提交账本并维护通道账本数据,为全网节点提供Broadcast交易广播服务、Orderer共识排序服务、Deliver区块分发服务等。通常,Hyperledger Fabric启动时需要先启动Orderer排序节点,创建系统通道提供正常服务后,再启动其他角色的Peer节点进入正常工作状态。因此,Orderer排序节点相当于Hyperledger Fabric系统的“中枢神经系统”,其服务模块关系与架构示意图如图2-1所示。
图2-1 Orderer排序节点的服务模块关系与架构示意图
Orderer节点启动后基于创世区块初始化系统通道,创建Orderer排序服务器(实现了AtomicBroadcastServer服务器接口),封装了Broadcast服务处理句柄、Deliver服务处理句柄与多通道注册管理器对象(Registrar类型),并提供Broadcast()交易广播服务接口与Deliver()区块分发服务接口。
其中,Orderer排序服务器基于Broadcast()接口接收交易广播服务请求,调用Broadcast服务处理句柄的Handle()方法进行处理,建立消息处理循环,接收与处理客户端提交的普通交易消息、配置交易消息等请求消息(Envelope类型,通道头部类型是ENDORSER_TRANSACTION、CONFIG_UPDATE等),经过滤后发送至通道绑定的共识组件链对象(Solo类型、Kafka类型等)进行排序。接着,再将排序后的交易添加到本地待处理的缓存交易消息列表,并按照交易出块规则构造新区块,提交到Orderer节点指定通道账本的区块数据文件中,同时负责创建新的应用通道、更新通道配置等通道管理工作。目前,Orderer排序服务器负责接收与处理两类交易消息,具体如下。
□ 配置交易消息(ConfigMsg):通道头部类型是CONFIG_UPDATE的通道配置交易消息,含有最新的通道配置信息,经过通道消息处理器过滤后,转换为通道头部类型为ORDERER_TRANSACTION或CONFIG的配置交易消息(Envelope类型),分别用于创建新的应用通道或更新通道配置,同时,将通道配置交易消息单独打包成新区块,并提交到系统通道账本与应用通道账本。
□ 普通交易消息(NormalMsg):通道头部类型是ENDORSER_TRANSACTION等的标准交易消息(经过Endorser背书的交易消息或其他非配置交易消息),含有改变世界状态的模拟执行结果读写集,经过Endorser节点签名背书后打包发送到Orderer节点请求处理,经过通道消息处理器过滤后,将合法交易提交到共识组件链对象进行排序,再按照交易出块规则(出块时间周期、打包最大交易数量、区块字节数限制等)生成新区块,并提交到通道账本。
同时,Orderer排序服务器提供Deliver()区块分发服务接口,将接收的服务请求交由Deliver服务处理句柄的Handle()方法处理,建立消息处理循环,负责接收与处理客户端提交的区块请求消息(Envelope类型,通道头部类型是DELIVER_SEEK_INFO、CONFIG_UPDATE等),封装了指定区块请求范围的区块搜索信息(SeekInfo类型)。接着,Deliver服务处理句柄循环从本地账本获取区块数据,依次发送给请求节点(如Leader主节点)。如果账本中还未生成指定区块,则Deliver服务处理句柄默认一直阻塞等待,直到该区块创建完成并提交账本后再回复给请求节点。
另外,Orderer排序服务器还提供了多通道注册管理器Registrar对象,负责管理系统通道与所有应用通道,封装了所有通道的链支持对象字典、共识组件字典、区块账本工厂对象等组件,维护所有通道上的通道配置、区块账本对象、共识组件等核心资源,创建通道上的共识组件链对象提供Orderer共识排序服务,负责对交易消息排序,切割打包构造新区块并提交账本,同时负责创建新的应用通道与更新通道配置,其相当于Orderer节点上的“资源管理器”。
实际上,Orderer排序服务器上的通道共识组件链对象利用Golang通道(Solo共识组件)或Kafka集群(Kafka共识组件)作为共识排序后端,对经过通道消息处理器过滤的合法交易消息进行排序,对交易顺序等达成一致性观点。同时,在新通道创建时或启动恢复现有通道时,启动通道绑定的链支持对象以及共识组件链对象,构建交易消息处理循环,接收共识组件已经完成排序的交易消息,并添加到本地待处理的缓存交易消息列表中,包括配置交易消息、普通交易消息等,采用相互独立的消息处理流程分别处理(实际上是在同一个处理方法代码中的不同case处理分支中)。
注意,目前Orderer节点账本只包括区块数据文件与区块索引数据库,负责保存区块数据即公有数据(包含公共数据与隐私数据哈希值),不存在状态数据库、历史数据库、隐私数据库等。不同于Peer节点,Orderer节点在提交区块到本地账本前不需要验证交易背书策略与执行MVCC检查,也不保存任何隐私数据(明文),只负责存储所有通道账本上的区块数据。