fabric網絡架構原理（fabric組網技術）
本篇文章給大家談談fabric網絡架構原理，以及fabric組網技術對應的知識點，希望對各位有所幫助，不要忘了收藏本站喔。
本文目錄一覽：
區塊鏈之聯盟鏈（三） 認識Fabric
Fabric 是超級賬本聯盟推出的核心區塊鏈框架，它適合在復雜的企業內和企業間搭建聯盟鏈。根據超級賬本聯盟的目標， Fabric 被建設為一個模塊化的、支持可插拔組件的基礎聯盟鏈框架。；
與以太坊系的Quorum不同，Fabric從一開始就只考慮企業間的應用。其獨有的channel概念，將企業根據業務目的不同以不同的子網連接起來， 每一個子網對應一個channel，而每個channel有自己獨立的區塊鏈。而Quorum很顯然是只有一個公網（所有企業節點都加入進去），企業與企業間的私有業務是通過Private Manager 完成的。
理解channel的最簡單方法就是，將它類比為一個消息服務提供的Topic，實際上Fabic最早就是基于Kafka?的分布式消息服務來實現。
? ? ? ?在Fabric網絡中，一個企業可以有一個或多個節點加入整個聯盟鏈；一個企業可以加入1個或者多個Channel（子網）；? 一個節點可以加入1個或者多個channel。每個channel構成一個子網，所以Fabric 是 一種由子網組成的網絡。
那么Fabric是怎么實現智能合約的執行和完成業務上鏈（將事務結果記錄在區塊鏈里）的呢？
與其它框架不同， Fabric 將整個過程分成了三個階段：
業務背書階段 ： 客戶的請求發送的背書節點，通過智能合約完成業務的計算（但不更新狀態），并完成背書；將背書結果返回個客戶端。
業務的排序階段 ： 客戶端將背書結果通過Channel被發送到排序節點（orderer），在排序節點完成事務的排序，并打包到block里，最后下發給所有連接到channel的節點。
業務驗證并寫入賬本階段 : 通過Gossip 網絡，所有Channel的節點都會接收到新的block，節點會驗證block中的每一個事務，確定是否有效：有效地將會跟新world state，無效的將會標志為“無效”，不會更新World state，但整個block會被完整的加入到帳本中（包括無效的事務）。
根據以上的描述，Fabric 節點實際可以分為? ，普通節點和Order節點：
?Peer, 普通節點, 完成背書（包括只能合約的執行）和驗證.
orderer,? 排序節點，完成排序。
加入orderer節點的Fabric網絡可以被描述如下：
每一個Channel，都定義了所有屬于channel的節點，但是并不需要所有節點都連接到Orderer 節點（節點間可以通過gossip 協議通訊來傳播私有數據或事務）.
? ? ? ?在區塊鏈中，共識是區塊鏈的基礎。與公有鏈不同，聯盟鏈的共識要求所有加入賬本的事務是確定的、最終的，也就是不可以有分叉，區塊與區塊間的順序是一定的，只存在唯一條鏈。在Fabric 中，這個客觀需求正是由排序實現的，所有的事務將被提交給orderer節點獲得確定的順序，并最終打包成block進入帳本。 Fabric 從1.4.1開始支持基于Raft實現排序服務,? 可以認為基于Raft實現共識。
基于RAFT的排序服務相對于早期的Kafka 具有更好的分布性，配置更加簡單，是聯盟鏈里常用的一個常用的達成共識的算法，Quorum就 默認使用RAFT作為共識層。簡單的說，RAFT是一個leader和follower的模式， 所有加入RAFT網絡的節點，任意時候都有一個leader,? 只有這個leader有權決定事務的順序，并打包成Block，其它節點只能作為follower提交事務和同步block。
基于FAFT網絡，每個企業可以有一個或多個節點參與到Orderer中去。在Frabric中企業間的網絡連接可以變化成如下形式：
? ? ? ?區塊鏈的使用用戶在以太網中被稱作EOA（External of Account）, EOA的載體是錢包。我們沿用這個概念，來看看Fabric是如何實現用戶和發起事務的。Fabric中EOA是一個CA中心發布的certificate（x.509），一個Certificate代表一個Identity（這與以太坊還是有很大區別的， 以太坊中一個EOA其實是一個hash地址），EOA能夠參與的channel以及被授權的操作是有channel的MSP（ Membership Service ?Provider）決定的（如下圖）。
注：certificate 是一種密碼學上驗證身份的通用做法； certificate包含了個人的信息，公鑰以及發布這個certificate的CA的簽名。驗證方只需要擁有這個CA的證書（包含CA的公鑰），就可以驗證這個簽名是否正確，certificate的內容是否有篡改。簡單的說，通過CA和Certificate，我們可以獲得一個可驗證的的身份和信任鏈。
? ? ? 如上圖，fabric中通要使用Wallet作為EOA的載體，一個Wallet中可以包含多個Identity（x.509 certificate）。 Identity 通過 CA提供的信任鏈來驗證正確性。
? 驗證了身份之后， Fabric 通過MSP在區塊鏈網絡中解決該身份是否代表組織的成員和在組織內具有什么角色。例如，channel首先會驗證當前用戶Identity是否是有效地身份，然后通過MSP查看其所處的企業和具有的角色，最終確定該用戶是否有權執行操作。
可以說，Fabric的訪問控制是通過MSP來完成的。在每一個需要訪問控制的地方都需要定義一個MSP。? 例如，每個channel都定義一個MSP，這個MSP規定了在channel范圍內資源的訪問權限。 MSP 是Fabric里一個晦澀難懂的概念，也是其賦予企業間安全訪問的基礎。
前文提到， Fabric 將業務處理和上網分成了三個部分， 背書，排序，驗證后加入賬本。
其中背書是Fabric執行智能合約的階段。以太坊中，智能合約是在EVM中執行的，有多種語言支持。 在Fabric，智能合約被稱為chaincode： 一個chaincode 可以理解為是智能合約的容器，可以包含一個或多個智能合約， 不用于EVM, chaincode是在 JVM 或NodeJS中執行。
客戶應用程序通過智能合約來訪問賬本，每一個可訪問的智能合約都被安裝在客戶端可以訪問的節點上，并被定義在channel里。（有只能合約的節點被稱為背書節點，沒有只能合約的節點被稱未提交節點，提交節點只維護賬本）
客戶應用提交一個交易請求， 請求到達背書節點， 背書節點首先會驗證客戶的簽名，確?？蛻舻纳矸萦袡鄨绦斜敬谓灰?，接著執行交易提及的智能合約（chaincode），并生成一個背書響應（或者叫做交易提案，tran-proposal）。這個背書響應中通常包含World state 的讀集合，寫集合， 以及節點對本次交易的簽名。這里與以太坊系聯盟鏈最主要的不同是： 背書階段只模擬交易，并不真正更新交易結果。 而真正更新交易在第三階段完成。背書節點最后將生成的背書響應fanhui給客戶端， 智能合約部分的執行就結束了。
通常一個交易的執行需要多方的簽名，所以客戶端需要將一個交易發送給多個背書節點，這些背書節點的選擇需要滿足背書策略的要求。
下圖是一個包含有客戶、背書節點，提交節點的網絡示意圖。
根據Fabric官方的參考文檔，客戶交易的正果過程可使用下圖描述。
如上圖，從1到3，為背書階段，4為排序階段，4.1,4,2, 5為驗證提交階段。 參考 Frabic的節點 概念，可以了解更多在交易細節的概念。??
總的來看， Fabric 更專注于企業間，通過上文，可以讓大家對Fabric的基本構成與概念有一個總的了解。? Fabric本身并不神秘，都是使用的現有的企業間的技術。要更好的了解，建議參考閱讀分布式消息系統和企業的安全基礎設施（CA相關）的支持。與以太坊系聯盟鏈實現比較，? Fabric 的子網更概念對于復雜企業間應用適應更強，但是其復雜的安全考量，使得運營成本很高，另外，Fabric 使用Certificate做為用戶身份，有很大的局限性，在新的2.0里，Fabric對于此處將有所改變。
下一篇，我們將來看看Sawtooth?, 由Inter 提供的區塊鏈框架。
區塊鏈之聯盟鏈(一) 認識以太坊
區塊鏈之聯盟鏈(二) 認識Quotum
區塊鏈之聯盟鏈(三) 認識Fabric
區塊鏈之聯盟鏈(四) 認識Sawtooth
fabric解析
core.yaml （peer節點的配置）
configtx.yaml（通道配置，用于生成創世區塊，通道配置塊等文件）
orderer.yaml（排序節點的配置）
【當Peer節點作為服務端啟動時，會按照優先級從高到低的順序依次嘗試從命令行參數、環境變量或配置文件中讀取配置信息。這里，我們主要通過配置文件的方式來對Peer進行配置?！?/p>
文件讀取路徑為$FABRIC_CFG_PATH/core.yaml；
如果沒找到，則嘗試查找當前目錄下的./core.yaml文件；
如果還沒有找到，則嘗試查找默認的/etc/hyperledger/fabric/core.yaml文件。
在結構上，core.yaml文件中一般包括logging、peer、vm、chaincode、ledger五大部分，其中，與MSP配置相關的主要是peer部分
配置------·mspConfigPath：
MSP目錄所在的路徑，可以為絕對路徑，或相對配置目錄的路徑，一般建議為/etc/hyperledger/fabric/msp；本例中，寫的是相對路徑msp
配置-------localMspId：
Peer所關聯的MSP的ID，一般為組織單位名稱，需要與聯盟配置中的名稱一致；
orderer節點對應的配置文件是orderer.yaml。
Orderer節點可以組成集群來在Fabric網絡中提供排序服務。類似地，支持從命令行參數、環境變量或配置文件中讀取配置信息。
當從環境變量中讀入配置時，需要以ORDERER_前綴開頭，例如配置文件中的general.ListenAddress項，對應到環境變量ORDERER_GENERAL_LISTENADDRESS。
在結構上，orderer.yaml文件中一般包括General、FileLedger、RAMLedger、Kafka四大部分，其中，涉及MSP配置的部分在General。
其中，LocalMSPDir,LocalMSPID為配置本地msp的主要部分:
配置------LocalMSPDir：
MSP目錄所在的路徑，可以為絕對路徑或相對路徑，一般建議為$FABRIC_CFG_PATH/msp；
配置------localMspId：
Orderer所關聯的MSP的ID，需要與聯盟配置中的組織的MSP名稱一致；
Fabric是否代表網絡架構的未來？
因此，高流量的數據中心需要一個強大，靈活的自動化網絡，來支持虛擬化，云計算以及多樣化的多點網絡生態系統。除此之外，存儲和局域網同樣也需要具有可預測性，高性能的網絡架構。這些條件，都促使網絡服務提供商制定新的Fabric以太網架構來符合新的網絡需求。 定義Fabric網絡 雖然有許多相關的定義,但一個數據中心交換結構最終應該提供: 高速，低延時的互連 無阻塞，無超載的互連 第2層類型的連接 為快速故障恢復配備的多個活動路徑 網狀連接，而不是樹型的拓撲結構 簡單的管理，配置和支持 隨著虛擬化技術的進步,每臺物理服務器的虛擬機數量由8臺提升至16臺,32臺甚至更多,這就使得低延遲的服務器間通信和更高的雙向帶寬需要變得更加迫切。這就需要網絡化架構向扁平化方向發展，最終的目標是在任意兩點之間盡量減少網絡架構的數目，從虛擬機到虛擬機，服務器到服務器，或者是發起人到目標。傳統的多層級網絡架構需要向基于Fabric型的網絡轉變，來達到數據傳輸的效率和延遲上的需要并符合下一代云計算的要求。 第二個要求，還是關于成本方面。40GbE的價格和100GbE的價格相比，顯然前者更讓云計算服務提供商滿意。如果服務器的網絡成為10GbE，以太網訪問層的路由也會變成10GbE。這意味著互聯結構或者Fabric將和訪問層一起以最低的成本升級到40GbE。因此，一個高密度無阻塞的40GbE網絡會提供一個良好的基于標準的高速，低延遲互聯結構。 融合網絡層 Fabric網絡結構的關鍵之一就是消除網絡層級的概念，傳統的網絡家后有三個層級-接入，匯聚以及核心。然而，隨著虛擬化的廣泛應用，虛擬交換機層又增加了兩一個開關層。而隨著刀片服務器的廣泛應用，刀片式交換機也加入了第五層終端到終端的網絡架構。 在建筑結構的架構關鍵概念之一是消除網絡層的概念。傳統的三個網絡層-接入，匯聚，和核心是司空見慣。然而，隨著虛擬化的廣泛采用，虛擬交換機層又增加了另一個開關層。刀片服務器獲得牽引力，刀片式交換機都加入了第五層到終端到終端的網絡架構。 Fabric網絡架構可以利用陣列技術來扁平化網絡，可以將傳統的三層結構壓縮為二層，并最終轉變為一層。 這項技術就是針對其3-2-1數據中心網絡架構中的1。數據中心網絡能夠利用fabric技術實現扁平化，從而像一臺邏輯設備一樣工作，并通過實現任意點之間的連接來消除復雜性和延遲，同時降低購置、運營和管理成本。簡單、靈活的Fabric架構由三個模塊組成F/Node、F/Interconnect和F/Director。這些組件相互協作，能夠實現任意端口之間的連接，以支持數據中心范圍內的一跳式流量傳輸，以及L2和L3功能。一跳式架構意味著，任何資源(如虛擬機或數據庫)之間不過是一跳的距離。因此，應用性能將得到極大地提高，而且不再依賴其在數據中心的位置。 fabric實現了高性能和易管理性;它除了提供一臺交換機的運行簡單性和性能外，還提供一個完整網絡所具有的規模(超過6000個端口)和永續性。當低效的傳統數據中心網絡在采用Fabric技術后，企業就能順利地在數據中心建設更大的存儲和計算資源池，以充分發揮虛擬化的效力。 對開放性標準的支持 最后，簡化管理的需求將再一次通過一個開放性的標準來得到滿足。OpenFlow對這一突破性的網絡架構表示了很大的希望。OpenFlow的推動者開放式網絡基金會(ONF)則表示將會大力推動這一網絡架構的發展。OpenFlow提供了一個集中的方式，在建設互連網絡架構的時候通過分布式管理和控制中心來減少其管理的復雜性 這些技術的結合，即以高密度，無阻塞標準為基礎的40GbE的互通網絡。旨在提升數據中心的經濟性和用戶體驗。利用這一全新的數據中心網絡架構，您可以創建單層網絡，在規模、性能和簡單性方面實現重大飛躍，同時還能降低成本，獲得更大的敏捷性和效率，并充分發揮數據中心的效力。對云計算的影響
網絡扁平化是什么意思？
網絡扁平化是指將傳統的接入、匯聚、核心三層網絡架構進行了簡化，因此人們形象地將其冠以“扁平”的稱號。
扁平網絡一般被認作是一種網絡架構（fabric），其優勢在于能夠允許更多的路徑通過網絡，以滿足數據中心的新要求，包括對虛擬化網絡和虛擬機遷移的支持。
扁平網絡旨在盡量縮短延遲，提高可用帶寬，同時提供虛擬化環境下所需的眾多網絡路徑。由于其將傳統的接入、匯聚、核心三層網絡架構進行了簡化，因此人們形象地將其冠以“扁平”的稱號。
擴展資料：
網絡扁平化產生的原因：
以太網贏得了局域網之爭，但是它仍存在一些重大局限。一個突出的問題就是轉發機制。當以太網交換機在轉發表中沒有成對的MAC地址和接口時，或者它收到廣播的以太網幀時，交換機就會復制幀，將副本轉發到所有接口。
由于以太網沒有生存時間（TTL）報頭字段來防止幀無限制地轉發，如果網絡中有物理回路，這些幀就會被不斷復制，在整個網絡中重復播送，直到網絡崩潰為止。
知名網絡工程師、英特爾實驗室院士Radia Perlman發明了生成樹算法來解決這個問題，該算法已成為生成樹協議（STP）的一部分。時至今日，依然有很多應用中的企業網從來沒有更改過生成樹的默認設置，卻又能確保網絡正常運行，同時提供一定的冗余功能。
參考資料來源：百度百科-扁平網絡
淺析 Fabric Peer 節點
Hyperledger Fabric，也稱之為超級賬本，是由 IBM 發起，后成為 Linux 基金會 Hyperledger 中的區塊鏈項目之一。
Fabric 是一個提供分布式賬本解決方案的平臺，底層的賬本數據存儲使用了區塊鏈。區塊鏈平臺通?？梢苑譃楣墟?、聯盟鏈和私有鏈。公有鏈典型的代表是比特幣這些公開的區塊鏈網絡，誰都可以加入到這個網絡中。聯盟鏈則有準入機制，無法隨意加入到網絡中，聯盟鏈的典型例子就是 Fabric。
Fabric 不需要發幣來激勵參與方，也不需要挖礦來防止有人作惡，所以 Fabric 有著更好的性能。在Fabric 網絡中，也有著諸多不同類型的節點來組成網絡。其中 Peer 節點承載著賬本和智能合約，是整個區塊鏈網絡的基礎。在這篇文章中，會詳細分析 Peer 的結構及其運行方式。
在本文中，假設讀者已經了解區塊鏈、智能合約等概念。
本文基于 Fabric1.4 LTS。
區塊鏈網絡是一個分布式的網絡，Fabric 也是如此，由于 Fabric 是聯盟鏈，需要準入機制，所以在網絡結構上會復雜很多，下面是一個簡化的 Fabric 網絡：
各個元素的含義如下：
對于 Fabric 網絡，外部的用戶需要通過客戶端應用，也就是圖中的 A1、A2 或者 A3 來訪問網絡，客戶端應用需要通過 CA 證書表明自己的身份，這樣才能訪問到 Fabric 網絡中有權限訪問的部分。
在上面的網絡中，共有四個組織，R1、R2、R3 和 R4。其中 R4 是整個 Fabric 網絡的創建者，網絡是根據 NC4 配置的。
在 Fabric 網絡中，不同的組織可以組成聯盟，不同的聯盟之間數據通過 Channel 來隔離。Channel 中的數據只有該聯盟中的組織才能訪問，每一個新的 Channel 都可以認為是一條新的鏈。與其他的區塊鏈網絡中通常只有一條鏈不一樣，Fabric 可以通過 Channel 在網絡中快速的搭建出一個新的區塊鏈。
上面 R1 和 R2 組成了一個聯盟，在 C1 上交易。R2 同時又和 R3 組成了另外一個聯盟，在 C2 上交易。R1 和 R2 在 C1 上交易時，對 R3 是不可見的，R2 和 R3 在 C2 上交易時，對 R1 是不可見的。Channel 機制提供了很好的隱私保護能力。
Orderer 節點是整個 Fabric 網絡共有的，用來為所有的交易排序、打包。比如上面網絡中 O4 節點。本文不會對 Orderer 節點進行詳細說明，可以把這個功能理解為比特幣網絡中的挖礦過程。
Peer 節點表示網絡中的節點，通常一個 Peer 就表示一個組織，Peer 是整個區塊鏈網絡的基礎，是智能合約和賬本的載體，Peer 也是本文討論的重點。
一個 Peer 節點可以承載多套賬本和智能合約，比如 P2 節點，既維護了 C1 的賬本和智能合約，也維護了 C2 的賬本和智能合約。
為了可以更深入了解 Peer 節點的作用，先了解一下 Fabric 整體的交易流程。整體的交易流程圖如下：
Peer 節點按照功能來分可以分為 背書節點 和 記賬節點 。
客戶端會提交交易請求到背書節點，背書節點開始模擬執行交易，在模擬執行之后，背書節點并不會去更新賬本數據，而是把這個交易進行加密和簽名，然后返回給客戶端。
客戶端收到這個響應之后就會把響應提交到 Orderer 節點，Orderer 節點會對這些交易進行排序，并打包成區塊，然后分發到記賬節點，記賬節點就會對交易進行驗證，驗證結束之后，就會把交易記錄到賬本里面。
一筆交易是否能成功是根據背書策略來指定的，每一個智能合約都會指定一個背書策略。
Peer 節點代表著聯盟鏈中的各個組織，區塊鏈網絡也是由 Peer 節點來組成的，而且也是賬本和智能合約的載體。
通過對上面交易過程的了解可以知道，Peer 節點是主要的參與方。如果用戶想要訪問賬本資源，都必須要和 peer 節點進行交互。在一個 Peer 節點中，可以同時維護多個賬本，這些賬本屬于不同的 Channel 。每個 Peer 節點都會維護一套冗余賬本，這樣就避免了單點故障。
Peer 節點根據在交易中的不同角色，可以分成背書節點（Endorser）和記賬節點（Committer），背書節點會對交易進行模擬執行，記賬節點才會真正將數據存儲到賬本中。
賬本可以分成兩個部分，一部分是區塊鏈，另一部分是 Current State，也被稱之為 World State。
區塊鏈上只能追加，不能對過去的數據進行修改，鏈上也包含兩部分信息，一部分是通道的配置信息，另一部分是不可修改，序列化的記錄。每一個區塊記錄前一個區塊的信息，然后連成鏈，如下圖所示：
第一個區塊被稱之為 genesis block，其中不存儲交易信息。每個區塊可以被分為 區塊頭 、 區塊數據 和 區塊元數據 。區塊頭中存儲著當前區塊的區塊號、當前區塊的 hash 值和上一個區塊的 hash 值，這樣才能把所有的區塊連接起來。區塊數據中包含了交易數據。區塊元數據中則包括了區塊寫入的時間、寫入人及簽名。
其中每一筆交易的結構如下，在 Header 中，包含了 ChainCode 的名稱、版本信息。Signature 就是交易發起用戶的簽名。Proposal 中主要是一些參數。Response 中是智能合約執行的結果。Endorsements 中是背書結果返回的結果。
WorldState中維護了賬本的當前狀態，數據以 Key-Value 的形式存儲，可以快速查詢和修改，每一次對 WorldState 的修改都會被記錄到區塊鏈中。WorldState 中的數據需要依賴外部的存儲，通常使用 LevelDB 或者 CouchDB。
區塊鏈和 WorldState 組成了一個完整的賬本，World State 保證的業務數據的靈活變化，而區塊鏈則保證了所有的修改是可追溯和不可篡改的。
在交易完成之后，數據已經寫入賬本，就需要將這些數據同步到其他的 Peer，Fabric 中使用的是 Gossip 協議。Gossip 也是 Channel 隔離的，只會在 Channel 中的 Peer 中廣播和同步賬本數據。
智能合約需要安裝到 Peer 節點上，智能合約是訪問賬本的唯一方式。智能合約可以通過 Go、Java 等變成語言進行編寫。
智能合約編寫完成之后，需要打包到 ChainCode 中，每個 ChainCode 中可以包含多個智能合約。ChainCode 需要安裝，ChainCode 需要安裝到 Peer 節點上。安裝好了之后，ChainCode 需要在 Channel 上實例化，實例化的時候需要指定背書策略。
智能合約在實例化之后就可以用來與賬本進行交互了，流程圖如下：
用戶編寫并部署實例化智能合約之后，就可以通過客戶端應用程序來向智能合約提交請求，智能合約會對 WorldState 中數據進行 get、put 或者 delete。其中 get 操作直接從 WorldState 中讀取交易對象當前的狀態信息，不會去區塊鏈上寫入信息，但 put 和 delete 操作除了修改 WorldState，還會去區塊鏈中寫入一條交易信息，且交易信息不能修改。
區塊鏈上的信息可以通過智能合約訪問，也可以在客戶端應用通過 API 直接訪問。
Event 是客戶端應用和 Fabric 網絡交互的一種方式，客戶端應用可以訂閱 Event，當 Event 發生時，客戶端應用就會接受到消息。
事件源可以兩類，一類是智能合約發出的 Event，另一類是賬本變更觸發的 Event。用戶可以從 Event 中獲取到交易的信息，比如區塊高度等信息。
在這篇文章中，首先介紹了 Fabric 整體的網絡架構，通過對 Fabric 交易流程的分析，討論了 peer 節點在交易中的作用，然后詳細分析了 peer 節點所維護的賬本和智能合約，并分析了 peer 節點維護賬本以及 peer 節點執行智能合約的流程。
文 / Rayjun
[1]
[2]
[3]
fabric網絡架構原理的介紹就聊到這里吧，感謝你花時間閱讀本站內容，更多關于fabric組網技術、fabric網絡架構原理的信息別忘了在本站進行查找喔。
