死磕hyperledger fabric源码|Order节点概述

死磕hyperledger fabric源码|Order节点概述

文章及代码:https://github.com/blockchainGuide/

分支:v1.1.0

bcc633a6c26528720cf16ed170f6a141

前言及源码目录

Orderer排序节点这块内容主要包括了节点启动流程、Broadcast广播交易服务、Orderer共识排序服务以及Deliver区块分发服务。其相关源码目录文件如下:

/orderer

|-common

​ |-blockcutter:交易切割打包模块 ✨✨✨✨✨✨

​ |-bootstrap:引导启动模块,生成创世块 ✨✨✨✨✨✨

​ |-broadcast:交易广播服务模块 ✨✨✨✨✨✨

​ |-localconfig:本地配置模块

​ |-metadata:获取元数据模块

​ |-msgprocessor:消息处理器模块

​ |-multichannel:多管道注册管理器模块

​ |-performance:性能测量模块

​ |-server:Order排序服务器模块 ✨✨✨✨✨✨

|-consensus

​ |-kafka:kafka共识组件模块 ✨✨✨✨✨✨

​ |-solo:solo共识组件模块

​ |-consensus.go:定义共识组件相关接口

|-main.go:orderer主程序

/common

|-deliver:定义Deliver服务器及处理器接口 ✨✨✨✨✨✨

/core

|-deliverservice

​ |-blocksprovider:区块提供者模块 ✨✨✨✨✨✨

​ |-client.go:提供broadcastClient客户端 ✨✨✨✨✨✨

​ |-deliveryClient:Deliver服务客户端 ✨✨✨✨✨✨

​ |-requester.go:请求区块数据 ✨✨✨✨✨✨

/protos

|-orderer:protobuf消息定义模块

主要功能

Orderer排序节点在Hyperledger Fabric系统架构中处于核心角色地位,管理着系统通道与所有应用通道,负责通道创建、通道配置更新等操作,并处理客户端提交的交易消息请求,对交易进行排序并按规则打包成新区块,提交账本并维护通道账本数据,为全网节点提供Broadcast交易广播服务、Orderer共识排序服务、Deliver区块分发服务等。通常,Hyperledger Fabric启动时需要先启动Orderer排序节点,创建系统通道提供正常服务后,再启动其他角色的Peer节点进入正常工作状态。其服务模块关系与架构示如图:

image-20210126163847049

Orderer节点启动后基于创世区块初始化系统通道,创建Orderer排序服务器,封装了Broadcast服务处理句柄、Deliver服务处理句柄与多通道注册管理器对象,并提供Broadcast()交易广播服务接口与 Deliver()区块分发服务接口。

其中,Orderer排序服务器基于Broadcast()接口接收交易广播服务请求,调用Broadcast服务处理句柄的Handle()方法进行处理,建立消息处理循环,接收与处理客户端提交的普通交易消息、配置交易消息等请求消息,经过滤后发送至通道绑定的共识组件链对象(Solo类型、Kafka类型等)进行排序。接着,再将排序后的交易添加到本地待处理的缓存交易消息列表,并按照交易出块规则构造新区块,提交到Orderer节点指定通道账本的区块数据文件中,同时负责创建新的应用通道、更新通道配置等通道管理工作。目前,Orderer排序服务器负责接收与处理两类交易消息,具体如下。

  • 配置交易消息(ConfigMsg):通道头部类型是CONFIG_UPDATE的通道配置交易消息,含有最新的通道配置信息,经过通道消息处理器过滤后,转换为通道头部类型为 ORDERER_TRANSACTIONCONFIG的配置交易消息(Envelope类型),分别用于创建新的应用通道或更新通道配置,同时,将通道配置交易消息单独打包成新区块,并提交到系统通道账本与应用通道账本。

  • 普通交易消息(NormalMsg):通道头部类型是ENDORSER_TRANSACTION等的标准交易消息(经过Endorser背书的交易消息或其他非配置交易消息),含有改变世界状态的模拟执行结果读写集,经过Endorser节点签名背书后打包发送到Orderer节点请求处

    理,经过通道消息处理器过滤后,将合法交易提交到共识组件链对象进行排序,再按照交易出块规则(出块时间周期、打包最大交易数量、区块字节数限制等)生成新区块,并提交到通道账本。

同时,Orderer排序服务器提供Deliver()区块分发服务接口,将接收的服务请求交由Deliver服务处理句柄的Handle()方法处理,建立消息处理循环,负责接收与处理客户端提交的区块请求消息,封装了指定区块请求范围的区块搜索信息(SeekInfo类型)。接着,Deliver服务处理句柄循环从本地账本获取区块数据,依次发送给请求节点(如Leader主节点)。如果账本中还未生成指定区块,则Deliver服务处理句柄默认一直阻塞等待,直到该区块创建完成并提交账本后再回复给请求节点。

另外,Orderer排序服务器还提供了多通道注册管理器Registrar对象,负责管理系统通道与所有应用通道,封装了所有通道的链支持对象字典、共识组件字典、区块账本工厂对象等组件,维护所有通道上的通道配置、区块账本对象、共识组件等核心资源,创建通道上的共识组件链对象提供Orderer共识排序服务,负责对交易消息排序,切割打包构造新区块并提交账本,同时负责创建新的应用通道与更新通道配置,其相当于Orderer节点上的“资源管理器”。

实际上,Orderer排序服务器上的通道共识组件链对象利用Golang通道(Solo共识组件)或Kafka集群(Kafka共识组件)作为共识排序后端,对经过通道消息处理器过滤的合法交易消息进行排序,对交易顺序等达成一致性观点。同时,在新通道创建时或启动恢复现有通道时,启动通道绑定的链支持对象以及共识组件链对象,构建交易消息处理循环,接收共识组件已经完成排序的交易消息,并添加到本地待处理的缓存交易消息列表中,包括配置交易消息、普通交易消息等,采用相互独立的消息处理流程分别处理 。

注意,目前Orderer节点账本只包括区块数据文件与区块索引数据库,负责保存区块数据即公有数据(包含公共数据与隐私数据哈希值),不存在状态数据库、历史数据库、隐私数据库等。不同于Peer节点,Orderer节点在提交区块到本地账本前不需要验证交易背书策略与执行MVCC检查,也不保存任何隐私数据(明文),只负责存储所有通道账本上的区块数据。

参考

https://github.com/blockchainGuide/

推荐阅读更多精彩内容