在生產(chǎn)環(huán)境中，一個最小的Fabric聯(lián)盟鏈網(wǎng)絡(luò)由4個結(jié)點(diǎn)組成，如下圖：
為了避免單點(diǎn)故障，進(jìn)行結(jié)構(gòu)冗余，每個節(jié)點(diǎn)的角色安排如下：
· 192.168.1.120 peer1, orderer1, zookeeper0, kafka0, ca1，
· 192.168.1.121 peer2, orderer2, zookeeper1, kafka1 ca2
· 192.168.1.122 peer3, zookeeper2, kafka2 ,ca3
· 192.168.1.122 peer4, kafka3 ca4, fabric瀏覽器
在Fabric中，本由一個節(jié)點(diǎn)處理的過程，在邏輯上被分解為不同的角色，每個角色承擔(dān)不同的功能；節(jié)點(diǎn)（Peer）分解為背書節(jié)點(diǎn)（Endorser peer）和提交節(jié)點(diǎn)（Committer peer），為了達(dá)到處理的順序性，提煉出排序（Orderer）角色，kafka是聯(lián)盟鏈中負(fù)責(zé)共享機(jī)制，zookeeper是個分布式應(yīng)用協(xié)調(diào)器，負(fù)責(zé)點(diǎn)到點(diǎn)數(shù)據(jù)傳輸，CA負(fù)責(zé)證書發(fā)放。 Fabric是應(yīng)用于聯(lián)盟鏈的場景，在處理每一筆交易時，每個環(huán)節(jié)上需要對交易信息進(jìn)行權(quán)限校驗(yàn)。
Fabric交易流程圖如下所示：
交易過程詳細(xì)流程：
1) 應(yīng)用程序客戶端通過SDK調(diào)用證書服務(wù)（CA）服務(wù)，進(jìn)行注冊和登記，并獲取×××?xí)?br/> 2) 應(yīng)用程序客戶端通過SDK向區(qū)塊鏈網(wǎng)絡(luò)發(fā)起一個交易提案（Proposal），交易提案把帶有本次交易要調(diào)用的合約標(biāo)識、合約方法和參數(shù)信息以及客戶端簽名等信息發(fā)送給背書（Endorser）節(jié)點(diǎn)。
3) 背書（Endorser）節(jié)點(diǎn)收到交易提案（Proposal）后，驗(yàn)證簽名并確定提交者是否有權(quán)執(zhí)行操作，同時根據(jù)背書策略模擬執(zhí)行智能合約，并將結(jié)果及其各自的CA證書簽名發(fā)還給應(yīng)用程序客戶端。
4) 應(yīng)用程序客戶端收到背書（Endorser）節(jié)點(diǎn)返回的信息后，判斷提案結(jié)果是否一致，以及是否參照指定的背書策略執(zhí)行，如果沒有足夠的背書，則中止處理；否則，應(yīng)用程序客戶端把數(shù)據(jù)打包到一起組成一個交易并簽名，發(fā)送給Orderers。
5) Orderers對接收到的交易進(jìn)行共識排序，然后按照區(qū)塊生成策略，將一批交易打包到一起，生成新的區(qū)塊，發(fā)送給提交（Committer）節(jié)點(diǎn)；
6) 提交（Committer）節(jié)點(diǎn)收到區(qū)塊后，會對區(qū)塊中的每筆交易進(jìn)行校驗(yàn)，檢查交易依賴的輸入輸出是否符合當(dāng)前區(qū)塊鏈的狀態(tài)，完成后將區(qū)塊追加到本地的區(qū)塊鏈，并修改世界狀態(tài)。
還有一個關(guān)于Fabric聯(lián)盟鏈交易理解的說明：
這個示例中包含客戶A和B，在進(jìn)行蘿卜買賣。他們各自有一個網(wǎng)絡(luò)節(jié)點(diǎn)，通過節(jié)點(diǎn)他們發(fā)送交易并和賬本進(jìn)行交互。
首先，假設(shè)必要的條件：
該流程假設(shè)通道已建立并正常運(yùn)行。用戶已注冊并使用組織認(rèn)證授權(quán)（CA）登記，同時獲得必要的加密材料來進(jìn)行網(wǎng)絡(luò)驗(yàn)證。
鏈碼（包含一組代表蘿卜市場初始狀態(tài)的鍵值對）被安裝在節(jié)點(diǎn)上并在通道上進(jìn)行實(shí)例化。鏈碼包含定義交易指令集合的邏輯和達(dá)成一致的蘿卜價格。設(shè)置一項(xiàng)針對鏈碼的背書策略，表明節(jié)點(diǎn)A和B都必須對任何交易進(jìn)行背書。
1. 客戶A發(fā)起交易
客戶A發(fā)出蘿卜購買請求。請求目標(biāo)節(jié)點(diǎn)A和B，分別代表客戶A和B。背書策略表明兩個節(jié)點(diǎn)必須為任何交易進(jìn)行背書，因而請求被發(fā)送到節(jié)點(diǎn)A和B。
接下來構(gòu)建交易提案。一個以可用SDK（node, java, python）為支撐的應(yīng)用利用有效的API來生成交易提案。這項(xiàng)提案作為調(diào)用鏈碼功能的請求來完成數(shù)據(jù)到賬本的讀取和/或?qū)懭耄礊橘Y產(chǎn)寫入新的鍵值對）。SDK有兩個作用：把交易提案包裝成合適架構(gòu)格式的庫（基于gRPC的協(xié)議緩沖）；使用用戶的加密證書來創(chuàng)建交易提案的唯一簽名。
2. 背書節(jié)點(diǎn)驗(yàn)證簽名&執(zhí)行交易
背書節(jié)點(diǎn)使用MSP驗(yàn)證簽名并確定請求者是否被合理授權(quán)進(jìn)行提案的操作（使用通道ACL）。背書節(jié)點(diǎn)以交易提案憑證為輸入，基于當(dāng)前狀態(tài)的數(shù)據(jù)庫執(zhí)行來生成交易結(jié)果，輸出包括反饋值、讀取集合和寫入集合。截止現(xiàn)在賬本還未進(jìn)行更新。這些值的集合，背書節(jié)點(diǎn)的簽名以及是/否的背書聲明一同作為“提案反饋”被傳輸回到SDK，SDK對應(yīng)用消耗的載荷進(jìn)行解析。
3. 審查提案反饋
應(yīng)用對背書節(jié)點(diǎn)簽名進(jìn)行驗(yàn)證，比較提案反饋（鏈接到包含載荷代理的術(shù)語條款）來決定是否一致，指定的背書策略是否被執(zhí)行（即節(jié)點(diǎn)A和B都進(jìn)行了背書）。這種架構(gòu)可以保證即使一個應(yīng)用選擇不進(jìn)行反饋審查或者轉(zhuǎn)發(fā)了沒有背書的交易，背書策略依然會被節(jié)點(diǎn)執(zhí)行并在驗(yàn)證提交階段維持。
4. 客戶組合交易背書
應(yīng)用對交易提案進(jìn)行廣播，以“交易信息”對訂購服務(wù)實(shí)現(xiàn)反饋。交易包含讀/寫集合，背書節(jié)點(diǎn)簽名和通道ID。訂購服務(wù)不讀取交易細(xì)節(jié)，只是從網(wǎng)絡(luò)中所有通道接收交易，根據(jù)每個通道按時間順序調(diào)用，創(chuàng)建每個通道的交易區(qū)塊。
5. 交易驗(yàn)證和提交
交易區(qū)塊被發(fā)布到通道中的所有節(jié)點(diǎn)。區(qū)塊中的交易被驗(yàn)證來確保背書策略被執(zhí)行并且賬本的讀取集合變量沒有發(fā)生變化，因?yàn)樽x取集合是執(zhí)行交易生成的。區(qū)塊中的交易被標(biāo)記為有效或無效。
6. 賬本更新
每個節(jié)點(diǎn)都把區(qū)塊追加到通道的鏈中，對每項(xiàng)有效交易，寫入集合被提交到當(dāng)前狀態(tài)的數(shù)據(jù)庫。發(fā)出事務(wù)通知客戶端應(yīng)用，交易（調(diào)用）被永久追加到鏈中以及交易是有效或者無效的。
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點(diǎn)與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。
重慶分公司
重慶分公司
