Fabric整體架構

　　Fabric為應用提供了gRPC API，以及封裝API的SDK供應用調用。應用可以通過SDK訪問Fabric網絡中的多種資源，包括賬本、交易、鏈碼、事件、權限管理等。應用開發者只需要跟這些資源打交道即可，無需關心如何實現。其中，賬本是最核心的結構，記錄應用信息，應用則通過發起交易來向賬本中記錄數據。交易執行的邏輯通過鏈碼來承載。整個網絡運行中發生的事件可以被應用訪問，以觸發外部流程甚至其他系統。權限管理則負責整個過程中的訪問控制。賬本和交易進一步地依賴核心的區塊鏈結構、數據庫、共識機制等技術；鏈碼則依賴容器、狀態機等技術；權限管理利用了已有的PKI體系、數字證書、加解密算法等諸多安全技術。底層由多個節點組成P2P網絡，通過gRPC通道進行交互，利用Gossip協議進行同步。

　　層次化結構提高了架構的可擴展和可插拔性，方便開發者以模塊為單位進行開發。

　　超級賬本Fabric根據交易過程中不同環節的功能，在邏輯上將節點角色解耦為Endorser和Committer，讓不同類型節點可以關注處理不同類型的工作負載。典型的交易處理過程如下圖所示。

　　示例交易處理過程

　　在整個交易過程中，各個組件的功能主要為：

　　客戶端（App）：客戶端應用使用SDK來跟Fabric網絡打交道。首先，客戶端從CA獲取合法的身份證書來加入到網絡內的應用通道。發起正式交易前，需要先構造交易提案（Proposal）提交給Endorser進行背書（通過EndorserClient提供的ProcessProposal（ctx context.Context， signedProp *pb.SignedProposal）（*pb.ProposalResponse，error）接口）；客戶端收集到足夠（背書策略決定）的背書支持后可以利用背書構造一個合法的交易請求，發給Orderer進行排序（通過BroadcastClient提供的Send（env *cb.Envelope）error接口）處理?？蛻舳诉€可以通過事件機制來監聽網絡中消息，來獲知交易是否被成功接收。命令行客戶端的主要實現代碼在peer/chaincode目錄下。

　　Endorser節點：主要提供ProcessProposal（ctx context.Context，signedProp *pb.SignedProposal）（*pb.ProposalResponse，error）方法（代碼在core/endorser/endorser.go文件）供客戶端調用，完成對交易提案的背書（目前主要是簽名）處理。收到來自客戶端的交易提案后，首先進行合法性和ACL權限檢查，檢查通過則模擬運行交易，對交易導致的狀態變化（以讀寫集形式記錄，包括所讀狀態的鍵和版本，所寫狀態的鍵值）進行背書并返回結果給客戶端。注意網絡中可以只有部分節點擔任Endorser角色。主要代碼在core/endorser目錄下;

　　Committer節點：負責維護區塊鏈和賬本結構（包括狀態DB、歷史DB、索引DB等）。該節點會定期地從Orderer獲取排序后的批量交易區塊結構，對這些交易進行落盤前的最終檢查（包括交易消息結構、簽名完整性、是否重復、讀寫集合版本是否匹配等）。檢查通過后執行合法的交易，將結果寫入賬本，同時構造新的區塊，更新區塊中BlockMetadata［2］（TRANSACTIONS_FILTER）記錄交易是否合法等信息。同一個物理節點可以僅作為Committer角色運行，也可以同時擔任Endorser和Committer這兩種角色。主要實現代碼在core/committer目錄下;

　　Orderer：僅負責排序。為網絡中所有合法交易進行全局排序，并將一批排序后的交易組合生成區塊結構。Orderer一般不需要跟賬本和交易內容直接打交道。主要實現代碼在orderer目錄下。對外主要提供Broadcast（srv ab.AtomicBroadcast_BroadcastServer）error和Deliver（srv ab.AtomicBroadcast_DeliverServer）error兩個RPC方法（代碼在orderer/server.go文件）;

　　CA：負責網絡中所有證書的管理（分發、撤銷等），實現標準的PKI架構。主要代碼在單獨的fabric-ca項目中。CA在簽發證書后，自身不參與到網絡中的交易過程。

相關電子資料下載