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

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

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

分支：v1.1.0

前言及源码目录

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节点进入正常工作状态。其服务模块关系与架构示如图：

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

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

配置交易消息（ConfigMsg）：通道头部类型是CONFIG_UPDATE的通道配置交易消息，含有最新的通道配置信息，经过通道消息处理器过滤后，转换为通道头部类型为 ORDERER_TRANSACTION或CONFIG的配置交易消息（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/