服務(wù)發(fā)現(xiàn)
為什么我們需要服務(wù)發(fā)現(xiàn)？
為了在peer節(jié)點(diǎn)上執(zhí)行鏈碼坎弯，向orderer節(jié)點(diǎn)提交交易，并且更新交易的狀態(tài)译暂，應(yīng)用程序通過SDK鏈接公開的API抠忘。
但是，SDK需要大量信息才能允許應(yīng)用程序鏈接到相關(guān)的網(wǎng)絡(luò)節(jié)點(diǎn)外永。除了通道orderer節(jié)點(diǎn)和peer節(jié)點(diǎn)的CA以及TLS證書崎脉，以及orderer節(jié)點(diǎn)和peer節(jié)點(diǎn)的IP地址和端口號以外，還必須知道相關(guān)的背書策略以及哪些peer節(jié)點(diǎn)安裝了鏈碼(這樣應(yīng)用程序才能知道哪些peer節(jié)點(diǎn)可以發(fā)送鏈碼提案)伯顶。
在v1.2版本之前囚灼，這些信息是靜態(tài)編碼的。但是祭衩，此實(shí)現(xiàn)不會對網(wǎng)絡(luò)更改產(chǎn)生動態(tài)響應(yīng)(例如灶体，已安裝相應(yīng)鏈碼的新增peer節(jié)點(diǎn)，或臨時離線的peer節(jié)點(diǎn))掐暮。靜態(tài)配置也不允許應(yīng)用程序?qū)Ρ硶呗员旧淼母淖龀鲰憫?yīng)(可能在新組織加入通道時發(fā)生)蝎抽。
此外，客戶端應(yīng)用程序無法知道哪些peer節(jié)點(diǎn)更新了賬本數(shù)據(jù)路克，哪些沒有更新樟结。因此，應(yīng)用程序可能會向那些沒有向網(wǎng)絡(luò)中其他peer節(jié)點(diǎn)同步賬本數(shù)據(jù)的peer節(jié)點(diǎn)發(fā)送交易提案衷戈，從而導(dǎo)致交易在提交時失效并因此浪費(fèi)資源狭吼。
發(fā)現(xiàn)服務(wù)通過讓peer節(jié)點(diǎn)動態(tài)計算所需信息并以可消費(fèi)方式將其呈現(xiàn)給SDK來改進(jìn)此過程。
發(fā)現(xiàn)服務(wù)是如何在fabric中運(yùn)作
被應(yīng)用程序開發(fā)人員/管理員信任的一組peer節(jié)點(diǎn)殖妇，提供對發(fā)現(xiàn)查詢的真實(shí)響應(yīng)，從而引導(dǎo)應(yīng)用程序破花∏ぃ客戶端應(yīng)用程序使用同一組織中的好的候選peer節(jié)點(diǎn)。
應(yīng)用程序向發(fā)現(xiàn)服務(wù)發(fā)出配置查詢座每，并獲取與網(wǎng)絡(luò)的其余節(jié)點(diǎn)通信所需的所有靜態(tài)信息前鹅。通過向peer節(jié)點(diǎn)的發(fā)現(xiàn)服務(wù)發(fā)送后續(xù)查詢，可以在任何時候刷新該信息峭梳。
在peer節(jié)點(diǎn)上運(yùn)行的服務(wù)(并不是運(yùn)行在應(yīng)用程序上)舰绘，并且使用由gossip通訊層維護(hù)的網(wǎng)絡(luò)元數(shù)據(jù)信息來找出哪些peer節(jié)點(diǎn)在線蹂喻。它還從peer節(jié)點(diǎn)的狀態(tài)數(shù)據(jù)庫中提取信息，例如任意相關(guān)的背書策略捂寿。
通過發(fā)現(xiàn)服務(wù)口四，應(yīng)用程序不再需要指定他們需要背書的peer節(jié)點(diǎn)。SDK可以簡單地向發(fā)現(xiàn)服務(wù)發(fā)送查詢秦陋，詢問給定通道和鏈碼ID需要哪些peer節(jié)點(diǎn)蔓彩。然后，發(fā)現(xiàn)服務(wù)將計算由兩個對象組成的描述符：
- Layouts: peer節(jié)點(diǎn)組列表和從每組中選擇相應(yīng)數(shù)量的peer節(jié)點(diǎn)個數(shù)
- Group to peer mapping: ?Layouts中peer節(jié)點(diǎn)組與通道節(jié)點(diǎn)的映射關(guān)系驳概。在實(shí)踐中赤嚼，每個組很可能是代表單個組織中的peer節(jié)點(diǎn)，但由于服務(wù)API是通用的而且對組織一無所知顺又，因此這只是一個“組”更卒。
以下是策略(AND(Org1,Org2))的示例，其中每個組織中有兩個peer節(jié)點(diǎn)稚照。
Layouts: [
QuantitiesByGroup: {
“Org1”: 1,
“Org2”: 1,
}
],
EndorsersByGroups: {
“Org1”: [peer0.org1, peer1.org1],
“Org2”: [peer0.org2, peer1.org2]
}
換句話說蹂空，背書策略需要來自O(shè)rg1的peer節(jié)點(diǎn)以及Org2的peer節(jié)點(diǎn)的簽名。并且它提供了那些組織中可以背書的可用peer節(jié)點(diǎn)的名稱(Org1和 Org2中的peer0和peer1節(jié)點(diǎn))锐锣。
然后SDK從列表中選擇隨機(jī)layout腌闯。在上面的示例中，背書策略是Org1以及Org2雕憔。如果它是一個OR策略姿骏，SDK將隨機(jī)選擇Org1或Org2，因此來自任一Org的peer節(jié)點(diǎn)的簽名將滿足該策略斤彼。
SDK選擇layout后分瘦，它會根據(jù)客戶端指定的條件從layout中的peer節(jié)點(diǎn)進(jìn)行選擇(SDK可以這樣做，是因?yàn)樗梢栽L問像賬本高度這樣的元數(shù)據(jù))琉苇。例如嘲玫，它可能更喜歡擁有更高賬本高度的peer節(jié)點(diǎn)，或者排斥那些應(yīng)用程序發(fā)現(xiàn)已經(jīng)離線的peer節(jié)點(diǎn)并扇，根據(jù)layout中定義的每組中peer節(jié)點(diǎn)的數(shù)量去团。如果基于標(biāo)準(zhǔn)沒有一個peer可供選擇，則SDK將從最符合標(biāo)準(zhǔn)的peer節(jié)點(diǎn)中隨機(jī)選擇穷蛹。
發(fā)現(xiàn)服務(wù)的功能
發(fā)現(xiàn)服務(wù)可以響應(yīng)一下的請求：
- Configuration query(配置查詢)：返回所有組織的MSPConfig以及通道的orderer端點(diǎn)土陪。
- Peer membership query(peer節(jié)點(diǎn)關(guān)系查詢)：返回已經(jīng)加入通道的peer節(jié)點(diǎn)
- Endorsement query(背書策略查詢)：返回通道中給定鏈碼的背書策略描述符
- Local peer membership query(本地peer節(jié)點(diǎn)關(guān)系查詢)：返回響應(yīng)查詢的peer節(jié)點(diǎn)的本地成員關(guān)系信息。 默認(rèn)情況下肴熏，客戶端需要是有管理員權(quán)限的peer節(jié)點(diǎn)才能響應(yīng)此查詢鬼雀。
特殊要求
當(dāng)peer節(jié)點(diǎn)啟用了TLS認(rèn)證，那么客戶端鏈接peer節(jié)點(diǎn)的時候必須提供相應(yīng)的TLS證書蛙吏。如果peer 節(jié)點(diǎn)沒有配置驗(yàn)證客戶端的證書(core.yaml中的配置項clientAuthRequired設(shè)置為false)源哩，此TLS證書可以自簽名鞋吉。
