菜鸟系列Fabric源码学习 — orderer服务启动

Fabric 1.4 orderer 服务启动流程

1.提要

orderer提供broadcast和deliver两个服务接口。orderer节点与各个peer节点经过grpc链接，orderer将全部peer节点经过broadcast发来的交易（Envelope格式，好比peer部署后的数据）按照配置的大小依次封装到一个个block中并写入orderer本身的帐本中，而后供各个peer节点的gossip服务经过deliver来消费这个帐本中的数据进行自身结点帐本的同步。

2.初始化过程

先看看main函数。

// Main is the entry point of orderer process
func Main() {
    fullCmd := kingpin.MustParse(app.Parse(os.Args[1:]))

    // "version" command
    if fullCmd == version.FullCommand() {
        fmt.Println(metadata.GetVersionInfo())
        return
    }

    conf, err := localconfig.Load()
    if err != nil {
        logger.Error("failed to parse config: ", err)
        os.Exit(1)
    }
    initializeLogging()
    initializeLocalMsp(conf)

    prettyPrintStruct(conf)
    Start(fullCmd, conf)
}

从中可知 orderer服务命令行是经过kingpin来实现的，基本上只是简单使用了下，也只实现了3个命令:

start*
    Start the orderer node
  version
    Show version information
  benchmark
    Run orderer in benchmark mode

而且从上述main函数可知，仅version有对应操做，而orderer 默认为orderer start。

启动流程为：

1. 加载配置（orderer.yaml/Defaults/环境变量）
   
2. 初始化log（log级别和log格式）
3. 初始化本地msp
4. 启动服务Start()

接下来主要关注第4步。前面基本上是配置初始化第过程。
查看一下start函数：

1. 从配置文件启动块路径获取配置块及验证是否可做为配置块（系统通道第一个块）
2. 集群相关初始化配置
3. 判断是不是raft共识及使用的是最新配置块，若是是，则进行下列流程：
   1. 获取全部应用链及其创世区块块（discoverChannels）
   2. 根据orderer是否在应用链配置块的raft节点中分类（channelsToPull topull/nottopull）
   3. 建立全部的应用通道帐本
   4. 获取topull应用通道的帐本(从orderer处获取)
   5. 获取系统通道帐本

if clusterType && conf.General.GenesisMethod == "file" {
        r.replicateIfNeeded(bootstrapBlock)
    }
    
func (r *Replicator) ReplicateChains() []string {
    var replicatedChains []string
    channels := r.discoverChannels()
    pullHints := r.channelsToPull(channels)
    totalChannelCount := len(pullHints.channelsToPull) + len(pullHints.channelsNotToPull)

    for _, channels := range [][]ChannelGenesisBlock{pullHints.channelsToPull, pullHints.channelsNotToPull} {
        for _, channel := range channels {
            ...
            r.appendBlock(gb, ledger, channel.ChannelName)
        }
    }

    for _, channel := range pullHints.channelsToPull {
        err := r.PullChannel(channel.ChannelName)
        ...
    }

    // Last, pull the system chain.
    if err := r.PullChannel(r.SystemChannel); err != nil && err != ErrSkipped {
        r.Logger.Panicf("Failed pulling system channel: %v", err)
    }
    return replicatedChains
}

1. 启动及初始化必要模块
   1. 建立系统链

   // Are we bootstrapping?
   if len(lf.ChainIDs()) == 0 {
       initializeBootstrapChannel(genesisBlock, lf)
   } else {
       logger.Info("Not bootstrapping because of existing chains")
   }

   1. 多通道初始化(initializeMultichannelRegistrar)
      • 初始化registrar实例

      registrar := multichannel.NewRegistrar(lf, signer, metricsProvider, callbacks...)

      // Registrar serves as a point of access and control for the individual channel resources.
      type Registrar struct {
          lock   sync.RWMutex
          //当前全部通道的chain对象
          chains map[string]*ChainSupport
          //不一样共识类型的consenter
          consenters         map[string]consensus.Consenter
          //Factory经过chainID检索或建立新的分类账
          ledgerFactory      blockledger.Factory
          //签名相关
          signer             crypto.LocalSigner
          blockcutterMetrics *blockcutter.Metrics
          //系统链id
          systemChannelID    string
          //系统链chainSupport
          systemChannel      *ChainSupport
          //通道配置模版
          templator          msgprocessor.ChannelConfigTemplator
          callbacks          []channelconfig.BundleActor
      }

      • 初始化共识机制

      consenters["solo"] = solo.New()
      var kafkaMetrics *kafka.Metrics
      consenters["kafka"], kafkaMetrics = kafka.New(conf, metricsProvider, healthChecker, registrar)
      go kafkaMetrics.PollGoMetricsUntilStop(time.Minute, nil)
      if isClusterType(bootstrapBlock) {
          initializeEtcdraftConsenter(consenters, conf, lf, clusterDialer, bootstrapBlock, ri, srvConf, srv, registrar, metricsProvider)
      }

      • 启动orderer现存的链（系统链/应用链，经过读取链的目录查看现存链），为每条链实例化了ChainSupport对象，而后启动

      chain := newChainSupport(
             r,
             ledgerResources,
             r.consenters,
             r.signer,
             r.blockcutterMetrics,
         )

      for _, chainID := range existingChains {
              ...
              chain.start()
              ...
      }

   2. 启动GRPC服务
      server.go中的服务端对象实例server在main.go的main()中由server := NewServer(manager, signer)生成，使用ab.RegisterAtomicBroadcastServer(grpcServer.Server(), server)进行了注册，随后grpcServer.Start()启动起来。
      其主要的两个接口为：

   type AtomicBroadcastServer interface {
       Broadcast(AtomicBroadcast_BroadcastServer) error
       Deliver(AtomicBroadcast_DeliverServer) error
   }

   其接口的实如今：orderer/common/server/server.go

3.相关模块介绍

3.1 ChainSupport

提供支持chain相关操做的资源，既包含帐本自己，也包含了帐本用到的各类工具对象，如分割工具cutter，签名工具signer，最新配置在chain中的位置信息（lastConfig的值表明当前链中最新配置所在的block的编号，lastConfigSeq的值则表明当前链中最新配置消息自身的编号）等

type ChainSupport struct {
    // 帐本相关资源 包括帐本的读写及配置的获取
    *ledgerResources
    // 提供从客户端获取消息分类处理接口
    msgprocessor.Processor
    // 将区块写入磁盘
    *BlockWriter
    // 链 提供对messages对处理方法
    //This design allows for two primary flows
    // 1. Messages are ordered into a stream, the stream is cut into blocks, the blocks are committed (solo, kafka)
    // 2. Messages are cut into blocks, the blocks are ordered, then the blocks are committed (sbft)
    consensus.Chain
    // 广播消息接收器 提供切块方法   
    cutter blockcutter.Receiver
    //签名
    crypto.LocalSigner
    // chains need to know if they are system or standard channel.
    systemChannel bool
}

3.2 blockcutter模块

• 块分割工具，用于分割block，具体为orderer/common/blockcutter/blockcutter.go中定义的receiver。一条一条消息数据在流水线上被传送到cutter处，cutter按照configtx.yaml中的配置，把一条条消息打包成一批消息，同时返回整理好的这批消息对应的committer集合，至此cutter的任务完成。

MaxMessageCount指定了block中最多存储的消息数量
AbsoluteMaxBytes指定了block最大的字节数
PreferredMaxBytes指定了一条消息的最优的最大字节数（blockcutter处理消息的过程当中会努力使每一批消息尽可能保持在这个值上）。

1. 若一个Envelope的数据大小（Payload+签名）大于PreferredMaxBytes时，不管当前缓存如何，当即Cut；
   
2. 若一个Envelope被要求单纯存储在一个block（即该消息对应的committer的Isolated()返回为true），要当即Cut
3. 若一个Envelope的大小加上blockcutter已有的消息的大小之和大于PreferredMaxBytes时，要当即Cut；
4. 若blockcutter当前缓存的消息数量大于MaxMessageCount了，要当即Cut。
5. 由configtx.yaml中BatchTimeout配置项（默认2s）控制，当时间超过此值，chain启动的处理消息的流程中主动触发的Cut。

3.3 chain start（）模块

主要是对消息进行处理，将交易消息传输给block cutter切成块及写入帐本。不一样的共识机制操做不一样。（后续结合consenter模块一块儿详细介绍）

chain := newChainSupport(
                r,
                ledgerResources,
                r.consenters,
                r.signer,
                r.blockcutterMetrics,
            )
r.chains[chainID] = chain
chain.start()

3.4 consenter模块:

solo/kafka/etcdraft三种共识类型，用于序列化生产（即各个peer点传送来的Envelope）出来的消息。

参考：
https://blog.csdn.net/idsuf698987/article/details/78639203