溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹了Hyperledger Fabric節點Gossip有什么用，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。
我們大多數都是從Hyperledger Fabric自帶的演示網絡例如First Network開始學習并嘗試Fabric區塊鏈的。First Network提供了一個腳本byfn.sh向我們展示了啟動一個Fabric網絡的典型流程：
生成密碼學資料和通道配置數據
啟動網絡組件，例如排序節點/orderers、對等節點/peers...
將對等節點加入通道
更新錨節點
經過以上操作，Fabric網絡就準備好了，接下來通常就是部署包含業務邏輯的鏈碼。
在上述流程中有些藏在后臺的過程很有意思。在這個教程中我們主要考察gossip的作用，了解它是如何幫助實現一個可伸縮的解決方案的。Hyperledger Fabric采用gossip作為點對點通信機制。為了優化整個信息流轉過程，Fabric實現了gossip數據擴散協議以達成可伸縮的網絡部署和運營。
Hyperledger Fabric官方文檔中的gossip提供了一個總體上的描述。在這里我們將抽取相關的信息并通過演示來看看gossip在實際運作中的表現。
Gossip引導節點配置需要在每個對等節點/peer上進行，該配置包含了同一機構中的一個或一組對等節點。當一個peer啟動運行后，它就會聯絡列表中的其他peer節點進行消息的gossip傳播。
在經典的First Network配置中，在每個機構中有兩個peer節點，因此一個合理的設置就是將另一個peer節點作為gossip的引導節點，這也是我們在配置文件（base/docker-compose-base.yaml）中觀察到的。下面只顯示了Org1的peer節點的信息，不過我們可以在Org2的peer節點配置中觀察到類似的信息：
當peer節點啟動后，它會先查找用于gossip通信的引導節點。后續我們也會看一下如果沒有定義引導節點會發生什么情況。
一個機構中的主導節點/leader負責從排序服務接收區塊并分發給同一機構中的其他peer節點。請記住在一個fabric網絡中，所有的peer節點都需要從排序服務接收新區塊。leader節點的引入優化了新區塊同步到所有peer節點的流程，因為排序服務只需要向每個機構的leader節點發送新區塊就可以了，接下來由leader節點負責同步到其他peer節點。
每個機構都有自己的leader節點。在演示中我們將看到這一點。每個通道也都有自己的leader節點。在peer節點加入一個通道之前，它是沒有leader這個概念的，只有當它加入通道之后，才涉及leader節點的問題。
在一個機構中，leader節點可以靜態配置或者動態選舉。在First Network中的默認設置是通過選舉決定，該配置在base/peer-base.yaml中：
在一個網絡中需要錨節點/anchor peer來獲取其他機構的通道成員信息。如果沒有錨節點的化，那么對通道成員的了解將局限在當前機構內。例如，當沒有錨節點時，在Org1中的peer節點只了解Org1內部的其他peer節點是通道成員，但是沒法了解Org2機構內的peer節點也是通道成員。在一個通道中至少需要一個錨節點以打破這種信息的割裂。
錨節點的配置需要對通道進行更新操作。首先使用configtxgen創建一個更新交易，簽名該交易并發送給排序服務，排序服務就會生成一個新的配置區塊，其中包含了這個用于更新錨節點配置的交易。當這個區塊到達通道中所有的peer節點并被各節點提交后，所有的peer節點也就都了解哪個是錨節點了，并進而通過彼此的gossip傳播實現了對整個通道成員的信息了解，即包括機構內成員，也包括機構外成員。
在后面部分我們將看到配置錨節點前后的不同運行情況。
我們使用的是First Ntwork，其中包含兩個機構Org1和Org2，每個機構包含兩個peer節點（peer0和peer1），定義了通道mychannel并將所有4個peer節點加入該通道，兩個機構中的peer0均被配置為錨節點。
當執行byfn.sh時，該腳本執行以下任務：
生成密碼學資料和通道配置數據（Step 1）
用docker-composer啟動所有網絡組件（容器）（Step 2-5）
創建mychannel通道的genesis區塊（block#0）（Step 6）
將全部4個peer節點加入mychannel（Step 7-10）
更新兩個機構的anchor peer配置信息（Step 11-12）
網絡已經就緒，每個peer節點都了解通道中的其他節點。下面是執行腳本后的結果（使用-n選項是告訴byfn腳本不要部署鏈碼）：
在下面的演示中我們基本遵循上述流程。為了更好地觀察實驗結果，我們將逐個分解peer節點的docker-compose配置，之后也會修改配置文件或者重新安排先后順序并觀察不同的結果。
從first-network/直接拷貝一個新目錄：
cd fabric-samples cp -r first-network kc-first-network
我們將在這個目錄上進行后續操作：kc-first-network/
同時，原始的CLI容器依賴于所有啟動的網絡組件。由于我們將逐個啟動網絡組件，因此先注釋掉依賴關系。
我們利用byfn.sh來生成Fabric網絡所需的密碼學資料和通道配置數據。
cd kc-first-network ./byfn.sh generate
docker-compose -f docker-compose-cli.yaml up -d orderer.example.com cli
docker-compose -f docker-compose-cli.yaml up -d peer0.org1.example.com
打開終端查看peer0.org1.example.com的日志：
docker logs -f peer0.org1.example.com
讓我們重點關注gossip相關的活動。從日志中我們可以了解gossip的初始化過程以及gossip實例的啟動過程。
然而，由于配置了gossip的引導節點，peer0.org1.example.com 會聯絡peer1.org1.example.com， 但是peer1目前還沒有運行。
docker-compose -f docker-compose-cli.yaml up -d peer1.org1.example.com
我們沒有看到和peer0類似的無法訪問gossip引導節點的問題。實際上peer1.org1.example.com 也配置了peer0.org1.example.com作為其gossip引導節點，并且在啟動時會嘗試聯絡peer0.org1.example.com。由于peer0已經啟動了，因此從日志中可以看到peer1成功聯絡到peer0（grpc.method=Ping, grpc.code=OK）。
幾乎在peer1.org1.example.com啟動的同時，peer0.org1.example.com也會聯絡peer1.org1.example.com。可以看到時間戳是吻合的。
gossip instance of peer1.org1.example.com started in 06:39:05.878 (above)
peer0.org1.example.com reached peer1.org1.example.com in 06:39:05.892 (below)
這表示兩個peer節點在gossip層已經連接上了。注意目前還沒有通道相關 的角色例如leader節點或anchor節點，只有加入通道后才會涉及這些概念。
為了遵循byfn.sh腳本的演示流程，我們也啟動peer0.org2.example.com 和 peer1.org2.example.com 。 可以觀察到類似的行為：
docker-compose -f docker-compose-cli.yaml up -d peer0.org2.example.com peer1.org2.example.com
由于兩個節點幾乎同時啟動，因此我們沒有看到之前在step3出現的peer0連接gossip引導節點的問題。
docker exec cli peer channel create -o orderer.example.com:7050 --tls \ --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem \ -c mychannel -f ./channel-artifacts/channel.tx
結果genesis區塊文件mychannel.block保存在CLI容器內，該文件用于將peer節點加入通道mychannel。
注意CLI容器的默認設置是以Org1的Admin身份連接peer0.org1.example.com。
docker exec cli peer channel join -b mychannel.block
從日志中可以觀察到以下內容：
使用genesis區塊創建通道mychannel的賬本
提交block#0
mychannel加入gossip網絡
還沒有找到兩個機構的錨節點配置信息
成為主導節點，被選舉為主導節點
docker exec \ -e CORE_PEER_ADDRESS=peer1.org1.example.com:8051 \ -e CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/tls/ca.crt \ cli peer channel join -b mychannel.block
可以觀察到和peer0.org1.example.com的日志類似的內容，除了主導節點的選舉部分。
因此，從通道角度看，peer0.org1.example.com是Org1的主導節點，負責從排序服務接收新區塊并發送給Org1中的其他peer節點。
當一個機構內peer節點的主導關系確定后，我們立即可以從兩個節點的日志中看到它們已經了解了通道中的成員信息。
peer0.org1.example.com: now know peer1.org1.example.com as channel member 
peer1.org1.example.com: now know peer0.org1.example.com as channel member
docker exec \ -e CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp \ -e CORE_PEER_ADDRESS=peer0.org2.example.com:9051 \ -e CORE_PEER_LOCALMSPID="Org2MSP" \ -e CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt \ cli peer channel join -b mychannel.block docker exec \ -e CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp \ -e CORE_PEER_ADDRESS=peer1.org2.example.com:10051 \ -e CORE_PEER_LOCALMSPID="Org2MSP" \ -e CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer1.org2.example.com/tls/ca.crt \ cli peer channel join -b mychannel.block
和之前Org1的情況類似，我們可以看到：
peer0.org2.example.com: as a leader, and also know peer1.org2.example.com as channel member
peer1.org2.example.com: see someone as leader, and also know peer0.org2.example.com as channel member 
現在我們知道gossip已經在單一機構內工作正，因為peer節點彼此都 了解對方的存在了。不過這還沒結束，因為peer節點還需要了解其他 機構中的peer節點，這需要配置錨節點/anchor peer。 
docker exec cli peer channel update -o orderer.example.com:7050 --tls \ --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem \ -c mychannel -f ./channel-artifacts/Org1MSPanchors.tx
我們首先看到生成了一個新的區塊block#1并且被Org1和Org2的所有peer節點接收并提交。讓我們研究一下。
首先，我們看一下新的區塊是如何到達各peer節點的。我們知道新區塊是orderer生成的。從tcpdump的trace中我們只看到orderer.example.com在與peer0.org1.example.com和peer0.org2.example.com通信，而沒有與兩個機構中的peer1節點通信。這是因為兩個機構中的peer0是主導節點，orderer只需要把新區塊發給主導節點。
注意這里只顯示了兩個包，實際上有一系列的包從orderer發送給兩個機構的peer0節點。不給過我們沒有看到發給peer1的包。
另外，通過捕捉每個peer節點上的接收block#1的日志，我們可以斷定：
peer0.org1.example.com (timestamp: 07:01:34.583)
peer1.org1.example.com (timestamp: 07:01:34.588)
peer0.org2.example.com (timestamp: 07:01:34.631)
peer1.org2.example.com (timestamp: 07:01:34.637)
我們看到兩個機構中的peer1接收到block#1都要比peer0晚一點。雖然這不是充分的中舉，至少它符合我們所說的由主導節點負責轉發新區塊的理論。這就是伸縮性實現的機制，通過引入主導節點并將新區塊的廣播拆分為兩層。
接下來我們將考察每個peer節點將區塊提交給賬本之后會發生什么情況。一旦了解到錨節點的存在，這些peer節點都會執行gossip操作。經過幾輪gossip擴散，我們可以看到通道的成員信息：
peer0.org1.example.com
peer1.org1.example.com
peer0.org2.example.com 
peer1.org2.example.com
現在每個peer節點都已經掌握了完整的成員映射表。作為額外的福利，我們也看到Org2的peer節點是如何在后續的gossip過程中了解到peer1.org1.example.com這個節點的。
現在通道中的每個peer節點都已經知曉彼此的存在，無論在同一機構還是不同機構，網絡已經就緒了。
我們看到在一個通道中只需要一個錨節點就可以讓網絡正常工作。不過還是推薦每個機構都設置一個錨節點。
docker exec \ -e CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp \ -e CORE_PEER_ADDRESS=peer0.org2.example.com:9051 \ -e CORE_PEER_LOCALMSPID="Org2MSP" \ -e CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt \ cli peer channel update -o orderer.example.com:7050 --tls \ --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem \ -c mychannel -f ./channel-artifacts/Org2MSPanchors.tx
我們現在可以看到通道成員視圖的變化。
Gossip的引導節點配置在 base/docker-compose-base.yaml中。注釋掉每個peer節點的CORE_PEER_GOSSIP_BOOTSTRAP 變量。從日志中的主要發現如下：
在step 3和4之后，我們可以看到Org1的兩個peer節點在gossip層面不再通信。在Step 5之后，Org2的兩個節點也存在類似的情況。
當所有peer節點都加入mychannel通道后，我們觀察到所有的peer節點都被選舉為主導節點。
peer0.org1.example.com
peer1.org1.example.com
peer0.org2.example.com
peer1.org2.example.com 
這是由于在機構內部缺乏gossip溝通。不過這有什么問題嗎？讓我們看看在更新錨節點（Step 11）之后會怎么樣。
peer0.org1.example.com
peer1.org1.example.com 
peer0.org2.example.com
peer1.org2.example.com
經過gossip過程，通道中所有的peer節點都掌握了正確的通道成員信息。同時我們還觀察到有些peer節點已經不再做主導節點了。
peer0.org1.example.com
peer0.org2.example.com
我們的觀察表明，在沒有配置peer節點的gossip引導節點時，一個機構內的主導節點選舉是失控的，因為每個peer都會選自己做主導節點。無論如何這不是期望的情況，因為orderer需要和每個主導節點通信。當更新錨節點配置后，所有的peer節點最終都掌握了通道成員信息，同時有節點也不再是主導節點，這是我們所期望的。因此最終的結果是可行的，即使我們在開始時沒有設置每個peer節點的gossip引導節點。
感謝你能夠認真閱讀完這篇文章，希望小編分享的“Hyperledger Fabric節點Gossip有什么用”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
