Fabric1.4 八、建立kafka共识的多orderer集群

1.排序节点介绍

本节内容基于前几节介绍的hellowrold区块链环境基础，实现基于kafka模式的排序节点部署和测试。

Fabric 的共识模型是Execute-Order-Validate，即先执行再排序最后验证的过程。
在创建区块链创世块以及通道的时候我们会用到一个configtx.yaml文件，该配置文件中的Orderer配置信息中有一个OrdererType参数，
该参数可配置为"solo" and “kafka”，之前例子我们使用的配置皆是solo，即单节点共识。

使用kafka集群作为orderer共识的技术方式可以为排序服务提供足够的容错空间，当客户端向peer节点提交Transaction的时候，
peer节点会得到一个读写集结果，该结果会发送给orderer节点进行共识和排序，此时如果orderer节点突然down掉，
将导致请求服务失效、数据丢失等问题。

因此，在生产环境部署Fabric，往往需要采用具有容错能力的orderer，即kafka模式，使用kafka模式搭建orderer节点集群需要会依赖于kafka和zookeeper。

1.1.排序执行过程

一个交易的生命周期包括下面几个步骤：

• client先向peer提交一个题案进行备案；
• peer执行智能合约，调用数据执行操作，peer将操作结果发送给orderer；
• orderer将收到的所有的题案排序，打包成区块，并发送给Peer;
• Peer打开每个区块，并进行验证，若验证通过，则写入本地账本，更新世界状态。向client发送event告知交易被提交到账本中。

1.2.Atomic Broadcast(Total Order):

客户端提交交易信息 –> orderers：将交易排序并打包成块 –> 各个账本写入全局有序的区块

1.2.1 全局排序要求：

• 全局唯一、容错(cft、bft)
• 网络分区（分区出去的节点的限制）
• 强一致性
• bft(fabric v1.4 的orderer是cft,并不代表fabric是cft)

1.2.2 Block Cutting（打包规则）：

BatchSize:批次大小

MaxMessageCount：最大消息数量
AbsoluteMaxBytes ：限制单个交易大小，超过该限制，会被拒绝掉
PreferredMaxBytes ：综合可能超过PreferredMaxBytes,假设PreferredMaxBytes=200b,前9个交易大小为100b,第10个交易大小为200b,这时会把第10个交易一块打包，这样就会大于PreferredMaxBytes。

BatchTimeout

Timeout 按照时间规则打包

2.部署基于kafka的排序节点

我们将部署三个Oraderer节点，
基于前几节的helloworld案例按以下步骤重新修改配置文件，重新部署区块链网络。

步骤1. 修改crypto-config.yaml，添加OrdererOrgs 的Specs

    Specs:
      - Hostname: orderer
      - Hostname: orderer2
      - Hostname: orderer3 

crypto-config.yaml完整配置文件如下：

# Copyright IBM Corp. All Rights Reserved.
#
# SPDX-License-Identifier: Apache-2.0
#

# ---------------------------------------------------------------------------
# "OrdererOrgs" - Definition of organizations managing orderer nodes
# ---------------------------------------------------------------------------
OrdererOrgs:
  # ---------------------------------------------------------------------------
  # Orderer
  # ---------------------------------------------------------------------------
  - Name: Orderer
    Domain: example.com
    EnableNodeOUs: true
    # ---------------------------------------------------------------------------
    # "Specs" - See PeerOrgs below for complete description
    # ---------------------------------------------------------------------------
    Specs:
      - Hostname: orderer
      - Hostname: orderer2
      - Hostname: orderer3 

# ---------------------------------------------------------------------------
# "PeerOrgs" - Definition of organizations managing peer nodes
# ---------------------------------------------------------------------------
PeerOrgs:
  # ---------------------------------------------------------------------------
  # Org1
  # ---------------------------------------------------------------------------
  - Name: Org1
    Domain: org1.example.com
    EnableNodeOUs: true
    Specs:
      - Hostname: peer0
      - Hostname: peer1
      - Hostname: peer2
      - Hostname: peer3
      - Hostname: peer4
    # ---------------------------------------------------------------------------
    # "Specs"
    # ---------------------------------------------------------------------------
    # Uncomment this section to enable the explicit definition of hosts in your
    # configuration.  Most users will want to use Template, below
    #
    # Specs is an array of Spec entries.  Each Spec entry consists of two fields:
    #   - Hostname:   (Required) The desired hostname, sans the domain.
    #   - CommonName: (Optional) Specifies the template or explicit override for
    #                 the CN.  By default, this is the template:
    #
    #                              "{
   {.Hostname}}.{
   {.Domain}}"
    #
    #                 which obtains its values from the Spec.Hostname and
    #                 Org.Domain, respectively.
    # ---------------------------------------------------------------------------
    # Specs:
    #   - Hostname: foo # implicitly "foo.org1.example.com"
    #     CommonName: foo27.org5.example.com # overrides Hostname-based FQDN set above
    #   - Hostname: bar
    #   - Hostname: baz
    # ---------------------------------------------------------------------------
    # "Template"
    # ---------------------------------------------------------------------------
    # Allows for the definition of 1 or more hosts that are created sequentially
    # from a template. By default, this looks like "peer%d" from 0 to Count-1.
    # You may override the number of nodes (Count), the starting index (Start)
    # or the template used to construct the name (Hostname).
    #
    # Note: Template and Specs are not mutually exclusive.  You may define both
    # sections and the aggregate nodes will be created for you.  Take care with
    # name collisions
    # ---------------------------------------------------------------------------
    Template:
      Count: 3
      # Start: 5
      # Hostname: {
   {.Prefix}}{
   {.Index}} # default
    # ---------------------------------------------------------------------------
    # "Users"
    # ---------------------------------------------------------------------------
    # Count: The number of user accounts _in addition_ to Admin
    # ---------------------------------------------------------------------------
    Users:
      Count: 1
  # ---------------------------------------------------------------------------
  # Org2: See "Org1" for full specification
  # ---------------------------------------------------------------------------
  - Name: Org2
    Domain: org2.example.com
    EnableNodeOUs: true
    Specs:
      - Hostname: peer0
      - Hostname: peer1
      - Hostname: peer2
      - Hostname: peer3
      - Hostname: peer4
    Template:
      Count: 3
    Users:
      Count: 1

步骤2. 执行生成证书文件

cryptogen generate --config=./crypto-config.yaml

执行后可见crypto-config/orderOrganizations/example.com/orderers目录下出现了三个组织的证书：

orderer.example.com
orderer2.example.com
orderer3.example.com

步骤3. 修改configtx.yaml配置文件

将OrdererType设置为kafka 并配置打包规则和kafka地址

Orderer: &OrdererDefaults

    # Orderer Type: The orderer implementation to start
    # Available types are "solo" and "kafka"
    OrdererType: kafka

    Addresses:
        - orderer.example.com:7050
        - orderer2.example.com:7050
        - orderer3.example.com:7050
    # Batch Timeout: The amount of time to wait before creating a batch
    BatchTimeout: 2s

    # Batch Size: Controls the number of messages batched into a block
    BatchSize:

        # Max Message Count: The maximum number of messages to permit in a batch
        MaxMessageCount: 10

        # Absolute Max Bytes: The absolute maximum number of bytes allowed for
        # the serialized messages in a batch.
        AbsoluteMaxBytes: 99 MB

        # Preferred Max Bytes: The preferred maximum number of bytes allowed for
        # the serialized messages in a batch. A message larger than the preferred
        # max bytes will result in a batch larger than preferred max bytes.
        PreferredMaxBytes: 512 KB

    Kafka:
        # Brokers: A list of Kafka brokers to which the orderer connects
        # NOTE: Use IP:port notation
        Brokers:
            - kafka1:9092
            - kafka2:9092
            - kafka3:9092
    # Organizations is the list of orgs which are defined as participants on
    # the orderer side of the network
    Organizations:

完整的configtx.yaml配置文件如下：

# Copyright IBM Corp. All Rights Reserved.
#
# SPDX-License-Identifier: Apache-2.0
#

---
################################################################################
#
#   Section: Organizations
#
#   - This section defines the different organizational identities which will
#   be referenced later in the configuration.
#
################################################################################
Organizations:

    # SampleOrg defines an MSP using the sampleconfig.  It should never be used
    # in production but may be used as a template for other definitions
    - &OrdererOrg
        # DefaultOrg defines the organization which is used in the sampleconfig
        # of the fabric.git development environment
        Name: OrdererOrg

        # ID to load the MSP definition as
        ID: OrdererMSP

        # MSPDir is the filesystem path which contains the MSP conf