溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
今天就跟大家聊聊有關如何理解HyperLeger Fabric架構，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。
Fabric邏輯架構根據不同角度進行劃分，上層基于應用程序角度進行設計，包括SDK、API、事件，通過SDK、API、事件來對底層區塊鏈進行操作：包括身份管理、賬本管理、交易管理、智能合約的部署和調用；下層基于底層區塊鏈進行設計，對外提供成員管理服務、共識服務、鏈碼服務、安全和密碼服務。
Fabric為應用開發提供了標準的gRPC接口，在API的基礎上封裝了不同語言的SDK，包括Go、NODE.JS、Java、Python等，開發人員可以利用SDK開發基于區塊鏈的應用；同時，區塊鏈的強一致性要求各個節點之間達成共識需要較長的執行時間，應用程序也是采用異步通信的模式進行開發的，事件模塊可以在觸發區塊事件或者鏈碼事件的時候執行預先定義的回調函數。
Fabric通過將各個部分分離成不同的模塊，做到可插拔性、靈活擴展性。
（1）身份管理
聯盟鏈考慮到商業應用對安全、隱私、監管、審計、性能的需求，提高準入門檻，成員必須被許可才能加入網絡。Fabric是目前為止在設計上最貼近聯盟鏈思想的區塊鏈。聯盟鏈考慮到商業應用對安全、隱私、監管、審計、性能的需求，提高準入門檻，成員必須被許可才能加入網絡。Fabric成員管理服務為整個區塊鏈網絡提供身份管理、隱私、保密和可審計的服務。成員管理服務通過公鑰基礎設施PKI和去中心化共識機制使得非許可的區塊鏈變成許可制的區塊鏈。
Fabric區塊鏈中，采用數字證書機制負責對網絡中的成員身份進行管理，CA節點實現了PKI服務。
PKI（Public Key Infrastructure）是綜合多種密碼學手段來實現安全可靠傳遞消息和身份確認的一個框架和規范。通常，PKI包括三部分：CA（Certification Authority）負責證書的頒發和作廢，接收來自RA的請求； RA（Registration Authority）負責對用戶身份進行驗證，校驗數據合法性，負責登記，審核通過則發給CA；證書數據庫用于存放證書，一般采用LDAP目錄服務，標準格式采用X.500系列。
CA是PKI體系最核心的組件，主要完成對公鑰的管理。密鑰有兩種類型：用于簽名和用于加解密，對應稱為簽名密鑰對和加密密鑰對。 用戶基于PKI體系要申請一個證書，一般可以由CA來生成證書和私鑰，也可以自己生成公鑰和私鑰，然后由CA來對公鑰進行簽發。
（2）賬本管理
授權的用戶是可以查詢賬本數據的，可以通過多種方式查詢，包括：
A、根據區塊號查詢區塊
B、根據區塊哈希查詢區塊
C、根據交易號查詢區塊
D、根據交易號查詢交易
E、根據通道名稱查詢區塊鏈信息
（3）交易管理
賬本數據只能通過交易執行才能更新，應用程序通過交易管理提交提案(Proposal)，在獲取到足夠數量交易背書(Endorsement)后，再給排序服務節點提交交易，排序服務將批量交易打包生成區塊。SDK提供接口，利用用戶證書本地生成交易號，背書節點和記賬節點都會校驗是否存在重復交易。
（4）智能合約
Fabric的智能合約（Smart Contract）稱為鏈碼（ChainCode），是一段代碼，用于處理網絡成員所同意的業務邏輯。Fabric的鏈碼和底層賬本是分開的，升級鏈碼時并不需要遷移賬本數據到新鏈碼當中，真正實現了邏輯與數據的分離。
Fabric通過智能合約實現了可編程的賬本，通過鏈碼執行提交的交易，實現基于區塊鏈的智能合約業務邏輯。只有智能合約才能更新賬本數據，其它模塊不能直接修改狀態數據。
鏈碼可采用Go、Java、Node.js語言編寫。鏈碼被編譯成一個獨立的應用程序，Fabric用Docker容器來運行鏈碼，容器里的base鏡像都是經過簽名驗證的安全鏡像，包括OS層和開發鏈碼的語言、runtime和SDK層。一旦鏈碼容器被啟動，就會通過gRPC與啟動鏈碼的Peer節點連接。
（1）成員服務管理
MSP（Member Service Provider）成員服務模塊對成員管理進行了抽象，提供包括會員注冊，身份保護、內容保密、交易審計等功能，可以使用可插拔的Fabric-CA模塊或第三方的CA來代替。
（2）共識服務
共識服務負責節點間共識管理、賬本的分布式計算、賬本的存儲及節點間的P2P協議功能的實現，是區塊鏈的核心組成部分，為區塊鏈的主體功能提供了底層技術支撐
（3）鏈碼服務
鏈碼服務為智能合約實現提供了一系列接口，并為鏈碼的安裝、運行、部署提供了環境。智能合約的實現依賴于安全的執行環境，確保安全的執行過程和用戶數據的隔離。Fabric采用Docker管理普通的鏈碼，提供安全的沙箱環境和鏡像文件倉庫，可支持多種語言的鏈碼。
（4）安全和密碼服務
安全問題是企業級區塊鏈關心的問題，Hyperledger Fabric專門定義了一個BCCSP（BlockChain Cryptographic Service Provider）模塊，實現密鑰生成、哈希運算、簽名驗簽、加密解密等基礎功能。
Hyperledger Fabric采用模塊化架構設計，利用通用的功能模塊和接口。模塊化的方法帶來了可擴展性、靈活性等優勢，會減少模塊修改、升級帶來的影響，能很好的利用微服務實現區塊鏈應用系統的開發和部署。
（1）模塊插件化
Fabric很多功能模塊（如CA模塊、共識算法、狀態數據庫存儲、ESCC、VSCC、BCCSP等）都是可插拔的。Fabric提供的通用接口和默認實現可以滿足大多數的業務需求，同時功能模塊也可以根據需求進行擴展，集成到Fabric區塊鏈網絡系統中。
（2）充分利用容器技術
Fabric中不僅節點使用容器作為運行環境，鏈碼也默認運行在安全的容器中。應用程序或者外部系統不能直接操作鏈碼，必須通過背書節點提供的接口轉發給鏈碼來執行。容器給鏈碼運行提供安全沙箱環境，把鏈碼的環境和背書節點的環境隔離開，鏈碼存在安全問題也不會影響到背書節點。
（3）可擴展性
Hyperledger Fabric1.x版本對節點的角色進行了不同的拆分，有主節點(Leader)、背書節點(Endorser)、記賬節點(Committer)、排序服務節點(Orderer)等，不同角色的節點有不同的功能。節點可以加入不同的通道中，鏈碼可以運行在不同的背書節點上，可以更好的提升并行執行的效率和吞吐量。
（4）安全性
Hyperledger Fabric提供授權訪問的區塊鏈網絡，節點共同維護成員信息，只有MSP(Member Service Provide)模塊驗證、授權的終端用戶才能使用區塊鏈網絡的功能。多鏈和多通道的設計容易實現數據隔離，也提供了應用程序和鏈碼之間的安全通道，實現了隱私保護。
Fabric網絡是通過組織來劃分的，每個組織內都包含承擔不同功能的Peer 節點，每個Peer節點又可以擔任多種角色。所有的組織共用一個統一的Orderer排序服務集群。基于Hyperledger Fabric區塊鏈網絡的設計時需要考慮組織之間的業務關系以及內部每個模塊之間的聯系，統一進行規劃。
Fabric網絡包含客戶端節點、CA節點、Peer節點、Orderer節點。
每個組織通常擁有自己的客戶端、Peer節點和CA節點，并且可以根據需要創建一個或多個不同的類型節點。Orderer節點不屬于某個組織的實體，屬于組織共同維護的節點。
客戶端或應用程序代表由終端用戶操作的實體，必須連接到某一個Peer節點或者排序服務節點上與區塊鏈網絡進行通信。客戶端向背書節點（Endorser Peer）提交交易提案(Proposal)，當收集到足夠背書后，向排序服務節點廣播交易，進行排序，生成區塊。
客戶端的主要作用是與Fabric區塊鏈交互，實現對區塊鏈的操作。區塊鏈操作分為管理類和鏈碼類的兩種，管理類操作包括啟停節點和配置網絡等；鏈碼類操作主要是鏈碼的生命周期管理，如安裝、實例化以及調用鏈碼。最常用的客戶端是命令行客戶端（CLI），此外是使用Fabric SDK開發的應用客戶端。
CA節點主要給Fabric網絡中的成員提供基于數字證書的身份信息，可以生成或取消成員的×××書（certificate）。CA節點是Fabric網絡的證書頒發節點(Certificate Authority)，由服務器(fabric-ca-server)和客戶端(fabric-ca-client)組成。
CA節點接收客戶端的注冊申請，返回注冊密碼用于登錄，以便獲取×××書。在區塊鏈網絡上所有的操作都會驗證用戶的身份。
CA節點是可選的，也可以用其它成熟的第三方CA頒發證書。
Fabric區塊鏈網絡中的每個組織可以擁有一到多個Peer節點。每個Peer節點可以擔任多種角色：Endorser Peer（背書節點）、Leader Peer（主節點）、Committer Peer（記賬節點）、Anchor Peer（錨節點）。
每個Peer節點必定是一個記賬節點，除記賬節點外，也可以擔任其它一到多種角色，即某個Peer節點可以同時是記賬節點和背書節點，也可以同時是記賬節點、背書節點、主節點，錨節點。
（1）Endorser Peer（背書節點）
部分Peer節點會執行交易并對結果進行簽名背書，充當背書節點的角色 。
背書(Endorsement)是指特定Peer節點執行交易并向生成交易提案( proposal )的客戶端應用程序返回YES/NO響應的過程。
背書節點是動態的角色，是與具體鏈碼綁定的。每個鏈碼在實例化的時候都會設置背書策略(Endorsement policy)，指定哪些節點對交易背書才有效。
也只有在應用程序向節點發起交易背書請求時才成為背書節點，其它時候是普通的記賬節點，只負責驗證交易并記賬。
（2）Leader Peer（主節點）
主節點負責和Orderer排序服務節點通信，從排序服務節點處獲取最新的區塊并在組織內部同步。可以強制設置，也可以選舉產生。
（3）Committer Peer（記賬節點）
負責驗證從排序服務節點接收的區塊里的交易，然后將區塊提交（寫入/追加）到其通道賬本的副本。記賬節點還將每個塊中的每個交易標記為有效或無效。
（4）Anchor Peer（錨節點）
在一個通道上可以被所有其它Peer節點發現的Peer節點，通道上的每個成員都有一個Anchor Peer(或多個Anchor Peer來防止單點故障)，允許屬于不同成員的Peer節點發現通道上的所有現有Peer節點。
排序服務節點接收包含背書簽名的交易，對未打包的交易進行排序生成區塊，廣播給Peer節點。
排序服務提供的是原子廣播，保證同一個鏈上的節點為接收到相同的消息，并且有相同的邏輯順序。
排序服務獨立于Peer進程存在并且以先來先服務的方式對Fabric網絡上的所有通道進行排序交易。排序服務旨在支持超出現有的SOLO和Kafka的可插拔實現。排序服務是整個網絡的公共綁定，包含綁定到每個成員的加密身份材料。
排序服務節點按照一定規則確定交易順序后，發給各個記賬節點，把交易持久化到區塊鏈的賬本中。排序服務節點支持互相隔離的多個通道，使得交易只發送給相關的記賬節點（Peer節點）。
商業應用的一個重要的需求是私密×××易，為此Fabric設計了通道（Channel）來提供成員之間的隱私保護。通道是部分網絡成員之間擁有獨立的通信渠道，在通道中發送的交易只有屬于通道的成員才可見，因此通道可以看作是Fabric的網絡中部分成員的私有通信子網。
通道由排序服務管理。在創建通道的時候，需要定義通道的成員和組織、錨節點（anchor peer）和排序服務節點，一條與通道對應的區塊鏈會同時生成，用于記錄賬本的交易，通道的初始配置信息記錄在區塊鏈的創世區塊中，可以通過增加一個新的配置區塊來更改通道的配置信息。
每個組織可以有多個節點加入同一個通道，組織內的節點中可以指定一個錨節點或多個錨節點（增強系統可靠性，避免單點故障）。組織的錨節點代表本組織與其它組織的節點交互，從而發現通道中的所有節點。另外，同一組織的節點會選舉或指定主導節點（leading peer），主導節點負責接收從排序服務發來的區塊，然后轉發給本組織的其它節點。主導節點可以通過特定的算法選出，可以保證在節點數量不斷變動的情況下仍能維持整個網絡的穩定性。
在Fabric網絡中，可能同時存在多條彼此隔離的通道，每條通道包含一條私有的區塊鏈和一個私有賬本，通道中可以實例化一個或多個鏈碼，以操作區塊鏈上的數據。
Fabric 1.x版本支持多鏈和多通道。Fabric的一條區塊鏈是包含Peer節點、賬本、排序服務的邏輯結構，將參與者與數據（包含鏈碼）進行隔離，滿足不同業務場景下的不同的人訪問不同數據的基本要求。
通道是共識服務提供的一種通訊機制，基于發布-訂閱關系，將Peer節點和排序節點根據某個Topic連接在一起，形成一個具有保密性的通訊鏈路（虛擬），實現業務隔離的要求。
排序服務提供了供Peer節點訂閱的主題（如發布-訂閱消息隊列），每個主題是一個通道。Peer節點可以訂閱多個通道，并且只能訪問自己所訂閱通道上的交易，因此一個Peer節點可以通過接入多個通道參與到多條鏈中。
目前通道分為系統通道（System Channel）和應用通道（Application Channel）。排序服務通過系統通道來管理應用通道，用戶的交易信息通過應用通道傳遞。
通道由排序服務節點負責管理，同時排序服務節點還負責對通道中的交易進行排序。在通道中一般包含有若干成員（組織），若兩個網絡實體的×××書能夠追溯到同一個根CA，則認為這兩個實體屬于同一組織。此外，通道中的每個組織都會有一個或以上的錨節點，錨節點負責與其它組織交換共享賬本的數據。
創建通道的時候定義了成員，只有通過成員MSP驗證的實體，才能夠加入到通道并訪問通道的數據。
排序服務支持多通道，提供了通向客戶端和Peer節點的共享通信通道，提供了包含交易的消息廣播服務（broadcast和deliver）。客戶端可以通過通道向連接到通道的所有節點廣播（broadcast）消息，向連接到通道的所有節點投遞(deliver)消息。多通道使得Peer節點可以基于應用訪問控制策略來訂閱任意數量的通道，應用程序根據業務邏輯決定將交易發送到1個或多個通道。
共識服務與（P1、PN）、（P1、P2、PN）、（P2、PN）組成三個相互獨立的通道，加入到不同通道的Peer節點能夠維護各個通道對應的賬本和狀態。不同通道對應現實世界中不同業務場景下的參與方，如銀行、保險公司、物流企業、生產企業等實體結構。
通道的配置信息都被打包到一個區塊中，并存放在通道的共享賬本中，成為通道的配置區塊，配置區塊除了配置信息外不包含其它交易信息。通道可以使用配置區塊來更新配置，因此在賬本中每新添加一個配置區塊，通道就按照最新配置區塊的定義來修改配置。通道賬本的首個區塊一定是配置區塊，也稱為創世區塊（Genesis Block）。
通道的CLI客戶端可以使用命令對通道進行管理。
peer channel create: 用于創建通道，主要參數有-c, -f, -o分別用于指定通道ID, configtx的路徑和orderer的地址。
peer channel fetch：抓取通道中的特定區塊，通過-c和-f參數來指定通道ID和orderer地址。
peer channel join：加入通道，通過-b參數指定初始區塊。
peer channel list：列出peer加入的通道。
peer channel update ：簽名并且發送configtx以升級通道配置，需要通過-c, -f, -o參數分別指定通道ID, configtx的路徑以及排序節點的地址。
在通道創建后，通道相關的配置以區塊的形式存在于通道的賬本中。如果需要修改通道的配置，可通過生成新的配置區塊去更新。修改通道配置的步驟如下：
A、通過SDK或CLI獲得最新的配置區塊。
B、編輯配置區塊。
C、計算配置更新量。
D、為配置區塊添加配置更新量。
E、SDK或CLI簽名并發送配置區塊。
若新的配置區塊通過驗證，則通道配置以最新配置區塊為準。
Fabric區塊鏈的交易分兩種，部署交易和調用交易。
部署交易把鏈碼部署到Peer節點上并準備好被調用，當一個部署交易成功執行時，鏈碼就被部署到各個背書節點上。
調用交易是客戶端應用程序通過Fabric提供的API調用先前已部署好的某個鏈碼的某個函數執行交易，并相應地讀取和寫入KV數據庫，返回是否成功或者失敗。
Fabric v1.0的交易流程如下：
區塊鏈的賬本由Peer節點維護，并不是由排序服務集群維護，所以，只有Peer節點（背書節點和確認節點）包含完整的區塊鏈信息，而排序服務集群只負責對交易進行排序，只保留處理過程中的一部分區塊鏈信息。Hyperledger Fabric網絡中的節點是一個邏輯的概念，并不一定是一個臺物理設備，但對于生產環境，為了系統架構的解耦，提高擴展性以及通過主機隔離提高安全性，Peer節點不能和排序服務節點部署在一臺機器上，而背書節點和確認節點可以部署在同一臺機器上。背書節點校驗客戶端的簽名，然后執行智能合約代碼模擬交易。交易處理完成后，對交易信息簽名，返回給客戶端。客戶端收到簽名后的交易信息后，發給排序服務節點排序。排序服務節點將交易信息排序打包成區塊后，廣播發給確認節點，寫入區塊鏈中。
客戶端應用程序利用SDK（Node.js，Java，Python）構造交易提案（Proposal）。交易提案是一個調用智能合約功能函數的請求，用來確認哪些數據可以讀取或寫入賬本。
客戶端把交易提案發送給一個或多個背書節點，交易提案中包含本次交易要調用的合約標識、合約方法和參數信息以及客戶端簽名等。
SDK將交易提案打包為可識別的格式（如gRPC上的protobuf），并使用用戶的加密憑證為該交易提案生成唯一的簽名。
背書節點（endorser）收到交易提案后，驗證簽名并確定提交者是否有權執行操作。背書節點將交易提案的參數作為輸入，在當前狀態KV數據庫上執行交易，生成包含執行返回值、讀操作集和寫操作集的交易結果（此時不會更新賬本），交易結果集、背書節點的簽名和背書結果（YES/NO）作為提案的結果返回給客戶端SDK，SDK解析信息判斷是否應用于后續的交易。
客戶端應用程序（SDK）驗證背書節點簽名，并比較各節點返回的提案結果，判斷提案結果是否一致以及是否參照指定的背書策略執行。
客戶端收到各個背書節點的應答后，打包到一起組成一個交易并簽名，發送給排序服務節點。
排序服務節點對接收到的交易進行共識排序，然后按照區塊生成策略，將一批交易打包到一起，生成新的區塊，調用deliver API投遞消息，發送給確認節點。
確認節點收到區塊后，會對區塊中的每筆交易進行校驗，檢查交易依賴的輸入輸出是否符合當前區塊鏈的狀態，完成后將區塊追加到本地的區塊鏈，并修改K-V狀態數據庫。
Fabric使用建立在HTTP/2上的P2P協議來管理分布式賬本，采取可插拔的方式來根據具體需求來設置共識協議，比如PBFT，Raft，PoW和PoS等。
Fabric網絡的數據以分布式賬本的形式存儲。賬本由一系列有順序和防篡改的記錄組成，記錄包含著數據的全部狀態改變。賬本中的數據項以鍵值對的形式存放，賬本中所有的鍵值對構成了賬本的狀態，稱為世界狀態（World State）。
每個通道中有唯一的賬本，通道的賬本由通道中所有成員共同維護，每個記賬節點上都保存所屬通道的賬本的一個副本，因而是分布式賬本。對賬本的訪問需要通過鏈碼實現對賬本鍵值對的增加、刪除、更新和查詢等操作。
賬本由區塊鏈和狀態數據庫兩部分組成。
區塊鏈是一組不可更改的有序的區塊（數據塊），記錄著全部交易的日志。每個區塊中包含若干個交易的數據，不同區塊所包含的交易數量可以不同。區塊之間用哈希鏈（Hashed-link）關聯：每個區塊頭包含本區塊所有交易的哈希值，以及上一個區塊頭的哈希值。鏈式結構可以確保每個區塊的數據不可更改，以及每個區塊之間的順序關系不可更改。因此，區塊鏈的區塊只可以添加在鏈的尾部。
狀態數據庫記錄了賬本中所有鍵值對的當前值，相當于對當前賬本的交易日志做了索引。鏈碼執行交易的時候需要讀取賬本的當前狀態，從狀態數據庫可以迅速獲取鍵值的最新狀態。
如果沒有狀態數據庫，要獲得某個鍵值時，需要遍歷整個區塊鏈中和該鍵值相關的交易，效率非常低，因此，讀取狀態數據庫可以認為是快速定位和訪問某個鍵值的方法。另外，當狀態數據庫出現故障的時候，可以通過遍歷賬本重新生成。
當一個區塊附加到區塊鏈尾部的時候，如果區塊中的有效交易修改了鍵值對，則會在狀態數據庫中作相應的更新，確保區塊鏈和狀態數據庫始終保持一致。
區塊鏈的數據塊以文件形式保存在各個節點中。狀態數據庫可以是各種鍵值數據庫，Fabric缺省使用LevelDB ，同時支持CouchDB選項。CouchDB除了支持鍵值數據外，也支持JSON格式的文檔模型，能夠做復雜的查詢。
Fabric聯盟鏈的開發人員主要分為三類：底層開發者負責系統部署與維護；組織管理者負責證書、MSP權限管理、共識機制等；業務開發者負責編寫鏈碼、創建維護通道、執行交易等。
Fabric區塊鏈開發流程主要包括智能合約編寫，通過SDK調用智能合約，訂閱各類事件。
開發者創建客戶端應用和鏈碼，鏈碼被部署到區塊鏈網絡的背書節點上。通過鏈碼來操作賬本，當客戶端調用一個交易時，實際上是在調用鏈碼中的一個實現業務邏輯的函數方法，并對賬本進行get, put, delete操作。客戶端應用提供用戶交互界面，并提交交易到區塊鏈網絡上。
看完上述內容，你們對如何理解HyperLeger Fabric架構有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
