溫馨提示×
您好，登錄后才能下訂單哦！
點(diǎn)擊 登錄注冊(cè) 即表示同意《億速云用戶服務(wù)條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹了Hyperledger Fabric節(jié)點(diǎn)Gossip有什么用，具有一定借鑒價(jià)值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。
我們大多數(shù)都是從Hyperledger Fabric自帶的演示網(wǎng)絡(luò)例如First Network開始學(xué)習(xí)并嘗試Fabric區(qū)塊鏈的。First Network提供了一個(gè)腳本byfn.sh向我們展示了啟動(dòng)一個(gè)Fabric網(wǎng)絡(luò)的典型流程：
生成密碼學(xué)資料和通道配置數(shù)據(jù)
啟動(dòng)網(wǎng)絡(luò)組件，例如排序節(jié)點(diǎn)/orderers、對(duì)等節(jié)點(diǎn)/peers...
將對(duì)等節(jié)點(diǎn)加入通道
更新錨節(jié)點(diǎn)
經(jīng)過(guò)以上操作，F(xiàn)abric網(wǎng)絡(luò)就準(zhǔn)備好了，接下來(lái)通常就是部署包含業(yè)務(wù)邏輯的鏈碼。
在上述流程中有些藏在后臺(tái)的過(guò)程很有意思。在這個(gè)教程中我們主要考察gossip的作用，了解它是如何幫助實(shí)現(xiàn)一個(gè)可伸縮的解決方案的。Hyperledger Fabric采用gossip作為點(diǎn)對(duì)點(diǎn)通信機(jī)制。為了優(yōu)化整個(gè)信息流轉(zhuǎn)過(guò)程，F(xiàn)abric實(shí)現(xiàn)了gossip數(shù)據(jù)擴(kuò)散協(xié)議以達(dá)成可伸縮的網(wǎng)絡(luò)部署和運(yùn)營(yíng)。
Hyperledger Fabric官方文檔中的gossip提供了一個(gè)總體上的描述。在這里我們將抽取相關(guān)的信息并通過(guò)演示來(lái)看看gossip在實(shí)際運(yùn)作中的表現(xiàn)。
Gossip引導(dǎo)節(jié)點(diǎn)配置需要在每個(gè)對(duì)等節(jié)點(diǎn)/peer上進(jìn)行，該配置包含了同一機(jī)構(gòu)中的一個(gè)或一組對(duì)等節(jié)點(diǎn)。當(dāng)一個(gè)peer啟動(dòng)運(yùn)行后，它就會(huì)聯(lián)絡(luò)列表中的其他peer節(jié)點(diǎn)進(jìn)行消息的gossip傳播。
在經(jīng)典的First Network配置中，在每個(gè)機(jī)構(gòu)中有兩個(gè)peer節(jié)點(diǎn)，因此一個(gè)合理的設(shè)置就是將另一個(gè)peer節(jié)點(diǎn)作為gossip的引導(dǎo)節(jié)點(diǎn)，這也是我們?cè)谂渲梦募╞ase/docker-compose-base.yaml）中觀察到的。下面只顯示了Org1的peer節(jié)點(diǎn)的信息，不過(guò)我們可以在Org2的peer節(jié)點(diǎn)配置中觀察到類似的信息：
當(dāng)peer節(jié)點(diǎn)啟動(dòng)后，它會(huì)先查找用于gossip通信的引導(dǎo)節(jié)點(diǎn)。后續(xù)我們也會(huì)看一下如果沒(méi)有定義引導(dǎo)節(jié)點(diǎn)會(huì)發(fā)生什么情況。
一個(gè)機(jī)構(gòu)中的主導(dǎo)節(jié)點(diǎn)/leader負(fù)責(zé)從排序服務(wù)接收區(qū)塊并分發(fā)給同一機(jī)構(gòu)中的其他peer節(jié)點(diǎn)。請(qǐng)記住在一個(gè)fabric網(wǎng)絡(luò)中，所有的peer節(jié)點(diǎn)都需要從排序服務(wù)接收新區(qū)塊。leader節(jié)點(diǎn)的引入優(yōu)化了新區(qū)塊同步到所有peer節(jié)點(diǎn)的流程，因?yàn)榕判蚍?wù)只需要向每個(gè)機(jī)構(gòu)的leader節(jié)點(diǎn)發(fā)送新區(qū)塊就可以了，接下來(lái)由leader節(jié)點(diǎn)負(fù)責(zé)同步到其他peer節(jié)點(diǎn)。
每個(gè)機(jī)構(gòu)都有自己的leader節(jié)點(diǎn)。在演示中我們將看到這一點(diǎn)。每個(gè)通道也都有自己的leader節(jié)點(diǎn)。在peer節(jié)點(diǎn)加入一個(gè)通道之前，它是沒(méi)有l(wèi)eader這個(gè)概念的，只有當(dāng)它加入通道之后，才涉及l(fā)eader節(jié)點(diǎn)的問(wèn)題。
在一個(gè)機(jī)構(gòu)中，leader節(jié)點(diǎn)可以靜態(tài)配置或者動(dòng)態(tài)選舉。在First Network中的默認(rèn)設(shè)置是通過(guò)選舉決定，該配置在base/peer-base.yaml中：
在一個(gè)網(wǎng)絡(luò)中需要錨節(jié)點(diǎn)/anchor peer來(lái)獲取其他機(jī)構(gòu)的通道成員信息。如果沒(méi)有錨節(jié)點(diǎn)的化，那么對(duì)通道成員的了解將局限在當(dāng)前機(jī)構(gòu)內(nèi)。例如，當(dāng)沒(méi)有錨節(jié)點(diǎn)時(shí)，在Org1中的peer節(jié)點(diǎn)只了解Org1內(nèi)部的其他peer節(jié)點(diǎn)是通道成員，但是沒(méi)法了解Org2機(jī)構(gòu)內(nèi)的peer節(jié)點(diǎn)也是通道成員。在一個(gè)通道中至少需要一個(gè)錨節(jié)點(diǎn)以打破這種信息的割裂。
錨節(jié)點(diǎn)的配置需要對(duì)通道進(jìn)行更新操作。首先使用configtxgen創(chuàng)建一個(gè)更新交易，簽名該交易并發(fā)送給排序服務(wù)，排序服務(wù)就會(huì)生成一個(gè)新的配置區(qū)塊，其中包含了這個(gè)用于更新錨節(jié)點(diǎn)配置的交易。當(dāng)這個(gè)區(qū)塊到達(dá)通道中所有的peer節(jié)點(diǎn)并被各節(jié)點(diǎn)提交后，所有的peer節(jié)點(diǎn)也就都了解哪個(gè)是錨節(jié)點(diǎn)了，并進(jìn)而通過(guò)彼此的gossip傳播實(shí)現(xiàn)了對(duì)整個(gè)通道成員的信息了解，即包括機(jī)構(gòu)內(nèi)成員，也包括機(jī)構(gòu)外成員。
在后面部分我們將看到配置錨節(jié)點(diǎn)前后的不同運(yùn)行情況。
我們使用的是First Ntwork，其中包含兩個(gè)機(jī)構(gòu)Org1和Org2，每個(gè)機(jī)構(gòu)包含兩個(gè)peer節(jié)點(diǎn)（peer0和peer1），定義了通道m(xù)ychannel并將所有4個(gè)peer節(jié)點(diǎn)加入該通道，兩個(gè)機(jī)構(gòu)中的peer0均被配置為錨節(jié)點(diǎn)。
當(dāng)執(zhí)行byfn.sh時(shí)，該腳本執(zhí)行以下任務(wù)：
生成密碼學(xué)資料和通道配置數(shù)據(jù)（Step 1）
用docker-composer啟動(dòng)所有網(wǎng)絡(luò)組件（容器）（Step 2-5）
創(chuàng)建mychannel通道的genesis區(qū)塊（block#0）（Step 6）
將全部4個(gè)peer節(jié)點(diǎn)加入mychannel（Step 7-10）
更新兩個(gè)機(jī)構(gòu)的anchor peer配置信息（Step 11-12）
網(wǎng)絡(luò)已經(jīng)就緒，每個(gè)peer節(jié)點(diǎn)都了解通道中的其他節(jié)點(diǎn)。下面是執(zhí)行腳本后的結(jié)果（使用-n選項(xiàng)是告訴byfn腳本不要部署鏈碼）：
在下面的演示中我們基本遵循上述流程。為了更好地觀察實(shí)驗(yàn)結(jié)果，我們將逐個(gè)分解peer節(jié)點(diǎn)的docker-compose配置，之后也會(huì)修改配置文件或者重新安排先后順序并觀察不同的結(jié)果。
從first-network/直接拷貝一個(gè)新目錄：
cd fabric-samples cp -r first-network kc-first-network
我們將在這個(gè)目錄上進(jìn)行后續(xù)操作：kc-first-network/
同時(shí)，原始的CLI容器依賴于所有啟動(dòng)的網(wǎng)絡(luò)組件。由于我們將逐個(gè)啟動(dòng)網(wǎng)絡(luò)組件，因此先注釋掉依賴關(guān)系。
我們利用byfn.sh來(lái)生成Fabric網(wǎng)絡(luò)所需的密碼學(xué)資料和通道配置數(shù)據(jù)。
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
讓我們重點(diǎn)關(guān)注gossip相關(guān)的活動(dòng)。從日志中我們可以了解gossip的初始化過(guò)程以及gossip實(shí)例的啟動(dòng)過(guò)程。
然而，由于配置了gossip的引導(dǎo)節(jié)點(diǎn)，peer0.org1.example.com 會(huì)聯(lián)絡(luò)peer1.org1.example.com， 但是peer1目前還沒(méi)有運(yùn)行。
docker-compose -f docker-compose-cli.yaml up -d peer1.org1.example.com
我們沒(méi)有看到和peer0類似的無(wú)法訪問(wèn)gossip引導(dǎo)節(jié)點(diǎn)的問(wèn)題。實(shí)際上peer1.org1.example.com 也配置了peer0.org1.example.com作為其gossip引導(dǎo)節(jié)點(diǎn)，并且在啟動(dòng)時(shí)會(huì)嘗試聯(lián)絡(luò)peer0.org1.example.com。由于peer0已經(jīng)啟動(dòng)了，因此從日志中可以看到peer1成功聯(lián)絡(luò)到peer0（grpc.method=Ping, grpc.code=OK）。
幾乎在peer1.org1.example.com啟動(dòng)的同時(shí)，peer0.org1.example.com也會(huì)聯(lián)絡(luò)peer1.org1.example.com?？梢钥吹綍r(shí)間戳是吻合的。
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)
這表示兩個(gè)peer節(jié)點(diǎn)在gossip層已經(jīng)連接上了。注意目前還沒(méi)有通道相關(guān) 的角色例如leader節(jié)點(diǎn)或anchor節(jié)點(diǎn)，只有加入通道后才會(huì)涉及這些概念。
為了遵循byfn.sh腳本的演示流程，我們也啟動(dòng)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
由于兩個(gè)節(jié)點(diǎn)幾乎同時(shí)啟動(dòng)，因此我們沒(méi)有看到之前在step3出現(xiàn)的peer0連接gossip引導(dǎo)節(jié)點(diǎn)的問(wèn)題。
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
結(jié)果genesis區(qū)塊文件mychannel.block保存在CLI容器內(nèi)，該文件用于將peer節(jié)點(diǎn)加入通道m(xù)ychannel。
注意CLI容器的默認(rèn)設(shè)置是以O(shè)rg1的Admin身份連接peer0.org1.example.com。
docker exec cli peer channel join -b mychannel.block
從日志中可以觀察到以下內(nèi)容：
使用genesis區(qū)塊創(chuàng)建通道m(xù)ychannel的賬本
提交block#0
mychannel加入gossip網(wǎng)絡(luò)
還沒(méi)有找到兩個(gè)機(jī)構(gòu)的錨節(jié)點(diǎn)配置信息
成為主導(dǎo)節(jié)點(diǎn)，被選舉為主導(dǎo)節(jié)點(diǎn)
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的日志類似的內(nèi)容，除了主導(dǎo)節(jié)點(diǎn)的選舉部分。
因此，從通道角度看，peer0.org1.example.com是Org1的主導(dǎo)節(jié)點(diǎn)，負(fù)責(zé)從排序服務(wù)接收新區(qū)塊并發(fā)送給Org1中的其他peer節(jié)點(diǎn)。
當(dāng)一個(gè)機(jī)構(gòu)內(nèi)peer節(jié)點(diǎn)的主導(dǎo)關(guān)系確定后，我們立即可以從兩個(gè)節(jié)點(diǎn)的日志中看到它們已經(jīng)了解了通道中的成員信息。
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 
現(xiàn)在我們知道gossip已經(jīng)在單一機(jī)構(gòu)內(nèi)工作正，因?yàn)閜eer節(jié)點(diǎn)彼此都 了解對(duì)方的存在了。不過(guò)這還沒(méi)結(jié)束，因?yàn)閜eer節(jié)點(diǎn)還需要了解其他 機(jī)構(gòu)中的peer節(jié)點(diǎn)，這需要配置錨節(jié)點(diǎn)/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
我們首先看到生成了一個(gè)新的區(qū)塊block#1并且被Org1和Org2的所有peer節(jié)點(diǎn)接收并提交。讓我們研究一下。
首先，我們看一下新的區(qū)塊是如何到達(dá)各peer節(jié)點(diǎn)的。我們知道新區(qū)塊是orderer生成的。從tcpdump的trace中我們只看到orderer.example.com在與peer0.org1.example.com和peer0.org2.example.com通信，而沒(méi)有與兩個(gè)機(jī)構(gòu)中的peer1節(jié)點(diǎn)通信。這是因?yàn)閮蓚€(gè)機(jī)構(gòu)中的peer0是主導(dǎo)節(jié)點(diǎn)，orderer只需要把新區(qū)塊發(fā)給主導(dǎo)節(jié)點(diǎn)。
注意這里只顯示了兩個(gè)包，實(shí)際上有一系列的包從orderer發(fā)送給兩個(gè)機(jī)構(gòu)的peer0節(jié)點(diǎn)。不給過(guò)我們沒(méi)有看到發(fā)給peer1的包。
另外，通過(guò)捕捉每個(gè)peer節(jié)點(diǎn)上的接收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)
我們看到兩個(gè)機(jī)構(gòu)中的peer1接收到block#1都要比peer0晚一點(diǎn)。雖然這不是充分的中舉，至少它符合我們所說(shuō)的由主導(dǎo)節(jié)點(diǎn)負(fù)責(zé)轉(zhuǎn)發(fā)新區(qū)塊的理論。這就是伸縮性實(shí)現(xiàn)的機(jī)制，通過(guò)引入主導(dǎo)節(jié)點(diǎn)并將新區(qū)塊的廣播拆分為兩層。
接下來(lái)我們將考察每個(gè)peer節(jié)點(diǎn)將區(qū)塊提交給賬本之后會(huì)發(fā)生什么情況。一旦了解到錨節(jié)點(diǎn)的存在，這些peer節(jié)點(diǎn)都會(huì)執(zhí)行g(shù)ossip操作。經(jīng)過(guò)幾輪gossip擴(kuò)散，我們可以看到通道的成員信息：
peer0.org1.example.com
peer1.org1.example.com
peer0.org2.example.com 
peer1.org2.example.com
現(xiàn)在每個(gè)peer節(jié)點(diǎn)都已經(jīng)掌握了完整的成員映射表。作為額外的福利，我們也看到Org2的peer節(jié)點(diǎn)是如何在后續(xù)的gossip過(guò)程中了解到peer1.org1.example.com這個(gè)節(jié)點(diǎn)的。
現(xiàn)在通道中的每個(gè)peer節(jié)點(diǎn)都已經(jīng)知曉彼此的存在，無(wú)論在同一機(jī)構(gòu)還是不同機(jī)構(gòu)，網(wǎng)絡(luò)已經(jīng)就緒了。
我們看到在一個(gè)通道中只需要一個(gè)錨節(jié)點(diǎn)就可以讓網(wǎng)絡(luò)正常工作。不過(guò)還是推薦每個(gè)機(jī)構(gòu)都設(shè)置一個(gè)錨節(jié)點(diǎn)。
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
我們現(xiàn)在可以看到通道成員視圖的變化。
Gossip的引導(dǎo)節(jié)點(diǎn)配置在 base/docker-compose-base.yaml中。注釋掉每個(gè)peer節(jié)點(diǎn)的CORE_PEER_GOSSIP_BOOTSTRAP 變量。從日志中的主要發(fā)現(xiàn)如下：
在step 3和4之后，我們可以看到Org1的兩個(gè)peer節(jié)點(diǎn)在gossip層面不再通信。在Step 5之后，Org2的兩個(gè)節(jié)點(diǎn)也存在類似的情況。
當(dāng)所有peer節(jié)點(diǎn)都加入mychannel通道后，我們觀察到所有的peer節(jié)點(diǎn)都被選舉為主導(dǎo)節(jié)點(diǎn)。
peer0.org1.example.com
peer1.org1.example.com
peer0.org2.example.com
peer1.org2.example.com 
這是由于在機(jī)構(gòu)內(nèi)部缺乏gossip溝通。不過(guò)這有什么問(wèn)題嗎？讓我們看看在更新錨節(jié)點(diǎn)（Step 11）之后會(huì)怎么樣。
peer0.org1.example.com
peer1.org1.example.com 
peer0.org2.example.com
peer1.org2.example.com
經(jīng)過(guò)gossip過(guò)程，通道中所有的peer節(jié)點(diǎn)都掌握了正確的通道成員信息。同時(shí)我們還觀察到有些peer節(jié)點(diǎn)已經(jīng)不再做主導(dǎo)節(jié)點(diǎn)了。
peer0.org1.example.com
peer0.org2.example.com
我們的觀察表明，在沒(méi)有配置peer節(jié)點(diǎn)的gossip引導(dǎo)節(jié)點(diǎn)時(shí)，一個(gè)機(jī)構(gòu)內(nèi)的主導(dǎo)節(jié)點(diǎn)選舉是失控的，因?yàn)槊總€(gè)peer都會(huì)選自己做主導(dǎo)節(jié)點(diǎn)。無(wú)論如何這不是期望的情況，因?yàn)閛rderer需要和每個(gè)主導(dǎo)節(jié)點(diǎn)通信。當(dāng)更新錨節(jié)點(diǎn)配置后，所有的peer節(jié)點(diǎn)最終都掌握了通道成員信息，同時(shí)有節(jié)點(diǎn)也不再是主導(dǎo)節(jié)點(diǎn)，這是我們所期望的。因此最終的結(jié)果是可行的，即使我們?cè)陂_始時(shí)沒(méi)有設(shè)置每個(gè)peer節(jié)點(diǎn)的gossip引導(dǎo)節(jié)點(diǎn)。
感謝你能夠認(rèn)真閱讀完這篇文章，希望小編分享的“Hyperledger Fabric節(jié)點(diǎn)Gossip有什么用”這篇文章對(duì)大家有幫助，同時(shí)也希望大家多多支持億速云，關(guān)注億速云行業(yè)資訊頻道，更多相關(guān)知識(shí)等著你來(lái)學(xué)習(xí)!
免責(zé)聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉(zhuǎn)載和分享為主，文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱：is@yisu.com進(jìn)行舉報(bào)，并提供相關(guān)證據(jù)，一經(jīng)查實(shí)，將立刻刪除涉嫌侵權(quán)內(nèi)容。
億速云公眾號(hào)
手機(jī)網(wǎng)站二維碼
