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網絡事務流中的最重要的環節，也是所有請求的點，它並不會立刻對請求給予回饋，一是因爲生成區塊的條件所限，二是因爲依託下游集羣的消息處理需要等待結果。