在生產環境中，一個最小的Fabric聯盟鏈網絡由4個結點組成，如下圖：
爲了避免單點故障，進行結構冗餘，每個節點的角色安排如下：
· 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中，本由一個節點處理的過程，在邏輯上被分解爲不同的角色，每個角色承擔不同的功能；節點（Peer）分解爲背書節點（Endorser peer）和提交節點（Committer peer），爲了達到處理的順序性，提煉出排序（Orderer）角色，kafka是聯盟鏈中負責共享機制，zookeeper是個分佈式應用協調器，負責點到點數據傳輸，CA負責證書發放。 Fabric是應用於聯盟鏈的場景，在處理每一筆交易時，每個環節上需要對交易信息進行權限校驗。
Fabric交易流程圖如下所示：
交易過程詳細流程：
1) 應用程序客戶端通過SDK調用證書服務（CA）服務，進行註冊和登記，並獲取×××書；
2) 應用程序客戶端通過SDK向區塊鏈網絡發起一個交易提案（Proposal），交易提案把帶有本次交易要調用的合約標識、合約方法和參數信息以及客戶端簽名等信息發送給背書（Endorser）節點。
3) 背書（Endorser）節點收到交易提案（Proposal）後，驗證簽名並確定提交者是否有權執行操作，同時根據背書策略模擬執行智能合約，並將結果及其各自的CA證書籤名發還給應用程序客戶端。
4) 應用程序客戶端收到背書（Endorser）節點返回的信息後，判斷提案結果是否一致，以及是否參照指定的背書策略執行，如果沒有足夠的背書，則中止處理；否則，應用程序客戶端把數據打包到一起組成一個交易並簽名，發送給Orderers。
5) Orderers對接收到的交易進行共識排序，然後按照區塊生成策略，將一批交易打包到一起，生成新的區塊，發送給提交（Committer）節點；
6) 提交（Committer）節點收到區塊後，會對區塊中的每筆交易進行校驗，檢查交易依賴的輸入輸出是否符合當前區塊鏈的狀態，完成後將區塊追加到本地的區塊鏈，並修改世界狀態。
還有一個關於Fabric聯盟鏈交易理解的說明：
這個示例中包含客戶A和B，在進行蘿蔔買賣。他們各自有一個網絡節點，通過節點他們發送交易並和賬本進行交互。
首先，假設必要的條件：
該流程假設通道已建立並正常運行。用戶已註冊並使用組織認證授權（CA）登記，同時獲得必要的加密材料來進行網絡驗證。
鏈碼（包含一組代表蘿蔔市場初始狀態的鍵值對）被安裝在節點上並在通道上進行實例化。鏈碼包含定義交易指令集合的邏輯和達成一致的蘿蔔價格。設置一項針對鏈碼的背書策略，表明節點A和B都必須對任何交易進行背書。
1. 客戶A發起交易
客戶A發出蘿蔔購買請求。請求目標節點A和B，分別代表客戶A和B。背書策略表明兩個節點必須爲任何交易進行背書，因而請求被髮送到節點A和B。
接下來構建交易提案。一個以可用SDK（node, java, python）爲支撐的應用利用有效的API來生成交易提案。這項提案作爲調用鏈碼功能的請求來完成數據到賬本的讀取和/或寫入（即爲資產寫入新的鍵值對）。SDK有兩個作用：把交易提案包裝成合適架構格式的庫（基於gRPC的協議緩衝）；使用用戶的加密證書來創建交易提案的唯一簽名。
2. 背書節點驗證簽名&執行交易
背書節點使用MSP驗證簽名並確定請求者是否被合理授權進行提案的操作（使用通道ACL）。背書節點以交易提案憑證爲輸入，基於當前狀態的數據庫執行來生成交易結果，輸出包括反饋值、讀取集合和寫入集合。截止現在賬本還未進行更新。這些值的集合，背書節點的簽名以及是/否的背書聲明一同作爲“提案反饋”被傳輸回到SDK，SDK對應用消耗的載荷進行解析。
3. 審查提案反饋
應用對背書節點簽名進行驗證，比較提案反饋（鏈接到包含載荷代理的術語條款）來決定是否一致，指定的背書策略是否被執行（即節點A和B都進行了背書）。這種架構可以保證即使一個應用選擇不進行反饋審查或者轉發了沒有背書的交易，背書策略依然會被節點執行並在驗證提交階段維持。
4. 客戶組合交易背書
應用對交易提案進行廣播，以“交易信息”對訂購服務實現反饋。交易包含讀/寫集合，背書節點簽名和通道ID。訂購服務不讀取交易細節，只是從網絡中所有通道接收交易，根據每個通道按時間順序調用，創建每個通道的交易區塊。
5. 交易驗證和提交
交易區塊被髮布到通道中的所有節點。區塊中的交易被驗證來確保背書策略被執行並且賬本的讀取集合變量沒有發生變化，因爲讀取集合是執行交易生成的。區塊中的交易被標記爲有效或無效。
6. 賬本更新
每個節點都把區塊追加到通道的鏈中，對每項有效交易，寫入集合被提交到當前狀態的數據庫。發出事務通知客戶端應用，交易（調用）被永久追加到鏈中以及交易是有效或者無效的。