Hyperledger Fabric入门实战(九）—— Fabric网络的搭建过程小结

1. Fabric梳理

1.1 fabric网络的搭建过程

1. 生成节点证书

   # 1. 编写组织信息的配置文件, 该文件中声明每个组织有多少个节点, 多少用户
   #     在这个配置文件中声明了每个节点访问的地址(域名)
   #     一般命名为crypto-config.yaml
   $ cryptogen generate --config=xxx.yaml
   

2. 生成创始块文件和通道文件

   • 编写配置文件 - configtx.yaml

     • 配置组织信息
       • name
       • ID
       • msp
       • anchor peer
     • 排序节点设置
       • 排序算法( 共识机制)
       • orderer节点服务器的地址
       • 区块如何生成
     • 对组织关系的概述
       • 当前组织中所有的信息 -> 生成创始块文件
       • 通道信息 -> 生成通道文件 或者 生成锚节点更新文件

   • 通过命令生成文件

     $ configtxgen -profile [从configtx.yaml->profiles->下属字段名] -outputxxxx
     

   • 创始块文件: 给排序节点使用了

     ORDERER_GENERAL_GENESISMETHOD=file
     ORDERER_GENERAL_GENESISFILE=/var/hyperledger/orderer/orderer.genesis.block
     

   • 通道文件:

     被一个可以操作peer节点的客户端使用该文件创建了通道, 得到一个 通道名.block

3. 编写 orderer节点对应的配置文件

   • 编写配置文件

     # docker-compose.yaml
     

   • 启动docker容器

     $ docker-compose up -d
     

   • 检测

     $ docker-compose ps
     

4. 编写peer节点对应的配置文件

   # docker-compose.yaml
    - 两个服务器
    	- peer
    	- cli
   

   启动容器

   $ docker-compose up -d
   

   检测

   $ docker-compose ps
   

   进入到客户端容器中

   $ docker exec -it cli bash
   

   • 创建通道
   • 当前节点加入到通道
   • 安装链码
   • 初始化 -> 一次就行

1.2 看图说话

• 客户端
  • 连接peer需要用户身份的账号信息, 可以连接到同组的peer节点上
  • 客户端发起一笔交易
    • 会发送到参与背书的各个节点上
    • 参加背书的节点进行模拟交易
    • 背书节点将处理结果发送给客户端
    • 如果提案的结果都没有问题, 客户端将交易提交给orderer节点
    • orderer节点将交易打包
    • leader节点将打包数据同步到当前组织
    • 当前组织的提交节点将打包数据写入到区块中
• Fabric-ca-sever
  • 可以通过它动态创建用户
  • 网络中可以没有这个角色
• 组织
  • peer节点 -> 存储账本
  • 用户
• 排序节点
  • 对交易进行排序
    • 解决双花问题
  • 对交易打包
    • configtx.yaml
• peer节点
  • 背书节点
    • 进行交易的模拟, 将节点返回给客户端
    • 客户端选择的, 客户端指定谁去进行模拟交易谁就是背书节点
  • 提交节点
    • 将orderer节点打包的数据, 加入到区块链中
    • 只要是peer节点, 就具有提交数据的能力
  • 主节点
    • 和orderer排序节点直接通信的节点
      • 从orderer节点处获取到打包数据
      • 将数据同步到当前组织的各个节点中
    • 只能有一个
      • 可以自己指定
      • 也可以通过fabric框架选择 -> 推荐
  • 锚节点
    • 代表当前组织和其他组织通信的节点
    • 只能有一个

2. Fabric中的共识机制

交易必须按照发生的顺序写入分类帐，尽管它们可能位于网络中不同的参与者组之间。为了实现这一点，必须建立交易的顺序，并且必须建立一种拒绝错误（或恶意）插入分类帐的坏交易的方法。

在分布式分类帐技术中，共识渐渐已成为单一功能中特定算法的代名词。然而，共识不仅仅是简单地同意交易顺序，而是通过在整个交易流程中的基本作用，从提案和认可到订购，验证和承诺，在Hyperledger Fabric中强调了这种差异化。简而言之，共识被定义为对包含块的一组交易的正确性的全面验证。

Hyperledger Fabric共识机制，目前包括SOLO，Kafka，以及未来可能要使用的PBFT（实践拜占庭容错）、SBFT（简化拜占庭容错）

2.1 Solo

SOLO机制是一个非常容易部署的非生产环境的共识排序节点。它由一个为所有客户服务的单一节点组成，所以不需要“共识”，因为只有一个中央权威机构。相应地没有高可用性或可扩展性。这使得独立开发和测试很理想，但不适合生产环境部署。orderer-solo模式作为单节点通信模式，所有从peer收到的消息都在本节点进行排序与生成数据块。

客户端通过GRPC发起通信，与Orderer连接成功之后，便可以向Orderer发送消息。Orderer通过Recv接口接收Peer发送过来的消息，Orderer将接收到的消息生成数据块，并将数据块存入ledger，peer通过deliver接口从orderer中的ledger获取数据块。

2.2 Kafka

Katka是一个分布式消息系统，由LinkedIn使用scala编写，用作LinkedIn的活动流（Activitystream)和运营数据处理管道（Pipeline）的基础。具有高水平扩展和高吞吐量。

在Fabric网络中，数据是由Peer节点提交到Orderer排序服务，而Orderer相对于Kafka来说相当于上游模块，且Orderer还兼具提供了对数据进行排序及生成符合配置规范及要求的区块。而使用上游模块的数据计算、统计、分析，这个时候就可以使用类似于Kafka这样的分布式消息系统来协助业务流程。

有人说Kafka是一种共识模式，也就是说平等信任，所有的HyperLedger Fabric网络加盟方都是可信方，因为消息总是均匀地分布在各处。但具体生产使用的时候是依赖于背书来做到确权，相对而言，Kafka应该只能是一种启动Fabric网络的模式或类型。

Zookeeper一种在分布式系统中被广泛用来作为分布式状态管理、分布式协调管理、分布式配置管理和分布式锁服务的集群。Kafka增加和减少服务器都会在Zookeeper节点上触发相应的事件，Kafka系统会捕获这些事件，进行新一轮的负载均衡，客户端也会捕获这些事件来进行新一轮的处理。

Orderer排序服务是Fablic网络事务流中的最重要的环节，也是所有请求的点，它并不会立刻对请求给予回馈，一是因为生成区块的条件所限，二是因为依托下游集群的消息处理需要等待结果。