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。

一個交易的生命周期包括下面幾個步驟：

client先向peer送出一個題案進行備案；

peer執行智能合約，調用資料執行操作，peer将操作結果發送給orderer；

orderer将收到的所有的題案排序，打包成區塊，并發送給Peer;

Peer打開每個區塊，并進行驗證，若驗證通過，則寫入本地賬本，更新世界狀态。向client發送event告知交易被送出到賬本中。

用戶端送出交易資訊 –> orderers：将交易排序并打包成塊 –> 各個賬本寫入全局有序的區塊

全局唯一、容錯(cft、bft)

網絡分區（分區出去的節點的限制）

強一緻性

bft(fabric v1.4 的orderer是cft,并不代表fabric是cft)

2.部署基于kafka的排序節點

我們将部署三個Oraderer節點，

基于前幾節的helloworld案例按以下步驟重新修改配置檔案，重新部署區塊鍊網絡。

crypto-config.yaml完整配置檔案如下：

執行後可見crypto-config/orderOrganizations/example.com/orderers目錄下出現了三個組織的證書：

将OrdererType設定為kafka 并配置打包規則和kafka位址

完整的configtx.yaml配置檔案如下：