Fabric

 　　Fabric在將交易發送到網絡中以前，須要先向背書節點收集足夠多的背書支持，同時採用專門的排序節點來負責整個網絡中十分核心的排序環境。目前，網絡中存在4種不一樣種類的服務節點，彼此寫做完成整個區塊鏈系統的功能。

　　　　背書節點(Endorser)：負責對交易提案(proposal)進行檢查和背書，計算交易執行結果

　　　　確認節點(Committer)：負責在接受交易結果前再次檢查合法性，接受合法交易對帳本的修改，並寫入區塊鏈結構

　　　　排序節點(Order)：對全部發往網絡中的交易進行排序，將排序後的交易按照配置中的約定整理爲區塊，以後提交給確認節點進行處理

　　　　證書節點(CA)：負責對網絡中全部的證書進行管理，提供標準的PKI服務

　　網絡中支持多通道的特性。使用一條獨立的系統通道(System channel)負責管理網絡中的各類配置信息，並完成對其餘應用通道(application channel，供用戶發送交易使用)的建立。

　　啓動一個Fabric網絡，需遵循以下主要步驟：

　　　　1.預備網絡內各項配置，包括網絡中成員的組織結構和對應的身份證書(cryptogen)；生成系統通道的初識配置區塊文件，新建應用通道的配置，更新交易文件以及可能須要的錨節點配置更新交易文件(configtxgen)

　　　　2.使用系統通道的初識配置區塊文件啓動排序節點，排序節點啓動後自動按照制定配置建立系統通道

　　　　3.不一樣的組織按照預置角色分別啓動Peer節點。這個時候網絡中不存在應用通道，Peer節點也並無加入網絡中　　

　　　　4.使用新建應用通道的配置更新交易文件，向系統通道發送交易，建立新的應用通道

　　　　5.讓對應的Peer節點加入所建立的應用通道中，此時Peer節點加入網絡，能夠準備接收交易了

　　　　6.用戶經過客戶端向網絡中安裝註冊鏈碼，鏈碼容器啓動成功後用戶便可對鏈碼進行調用，將交易發送到網絡中

 

　　啓動Fabric網絡主要步驟包括計劃拓撲，準備相關配置文件，啓動Ordered節點，啓動Peer節點和操做網絡等。

　　啓動的Fabric網絡中包括一個Ordered節點和四個Peer節點，以及一個管理節點生成相關啓動文件，在網絡啓動後做爲操做客戶端執行命令。四個Peer節點分屬於同一個管理域下的兩個組織Org1和Org2。這兩個組織都加入同一個應用通道中。每一個組織中的第一個節點做爲錨節點與其餘組織進行通訊，全部節點經過域名均可以互相訪問。

　　Fabric網絡在啓動以前，須要提早生成一些用於啓動的配置文件，主要包括MSP相關文件(msp/*)，TLS相關文件(tls/*)，系統通道初識區塊，新建應用通道交易文件，錨節點配置更新文件等。

配置	存放節點	依賴配置	主要功能
MSP相關文件msp/*	Peer，Orderer，客戶端	crypto-config.yaml	包括證書文件，簽名私鑰等，用於管理實體在網絡中的身份信息
TLS相關文件tls/*	Peer，Orderer，客戶端	crypto-config.yaml	若網絡中啓用了TLS，則節點須要準備TLS證書
系統通道初識區塊文件 orderer.genesis.block	Orderer	configtx.yaml	用於啓動Ordering服務，配置網絡中策略
新建應用通道交易文件businesschannel.tx	客戶端	configtx.yaml	用於新建應用通道，指定通道成員，訪問策略等
錨節點配置更新文件 Org1MSPanchors.tx和OrgMSPanchros.tx	客戶端	configtx.yaml	用於配置通道中各組織的錨節點信息

 

 

 

 

 

 

 

　　Fabric網絡提供的是聯盟鏈服務，聯盟由多個組織構成，組織中的成員提供了節點服務來維護網絡，而且經過身份來進行權限管理。所以首先需對各個組織和成員的關係進行規劃，分別生成對應的身份證書文件，並部署到其對應的節點上。Fabric提供了cryptogen工具實現自動化生成，這一過程首先依賴crypto-config.yaml配置文件。crypto-config.yaml中定義了一個OrdererOrgs類型的組織Orderer，以及兩個PeerOrgs類型的組織Org1和Org2。使用該配置文件經過命令$cryptogen generate --config=./crypto-config.yaml --output ./crypto-config生成指定的拓撲結構的組織和身份文件，存放到crypto-config目錄下。

　　Orderer節點在啓動時，能夠指定使用提早生成的初識區塊文件做爲系統通道的初識配置。初識區塊中包括了Ordering服務的相關配置信息以及聯盟信息。初識區塊可使用configtxgen工具進行生成。生成過程須要依賴/etc/hyperledger/fabric/configtx.yaml文件。configtx.yaml配置文件定義了整個網絡中的相關配置和拓撲結構信息。該配置文件主要分爲兩個模板TwoOrgsOrdererGenesis和TwoOrgsChannel，前者能夠用來生成Ordering服務的初識區塊文件。經過使用$ configtxgen -profile TwoOrgsOrdererGenesis -outputBlock ./orderer.gensis.block來生成Ordering服務系統通道的初識區塊文件。

　　新建應用通道時，須要事先準備好配置交易文件，其中包括屬於該通道的組織結構信息。這些信息會寫入該應用通道的初識區塊中。經過$ configtxgen -profile TwoOrgsChannel -outputCreateChannelTx ./businesschannel.tx -channelID ${CHANNEL_NAME}生成新建通道的配置交易文件。

　　錨節點配置更新文件能夠用來對組織的錨節點進行配置。

　　

　　啓動Orderer節點

　　　　首先檢查啓動節點的全部配置是否就緒：

　　　　　　在/hyperledger/fabric路徑下放置有編寫好的orderer.yaml

　　　　　　在/hyperledger/fabric路徑下放置生成的msp文件目錄，tls文件目錄

　　　　　　在/hyperledger/fabric路徑下放置初識區塊文件orderer.genesis.block

　　　　啓動一個Peer節點

　　　　　　在/hyperledger/fabric路徑下放置有對應編寫好的core.yaml

　　　　　　在/hyperledger/fabric路徑下放置生成的對應msp文件，tls文件

 

　　網絡啓動後，默認並不存在任何應用通道，須要手動建立應用通道，並讓合做的Peer節點加入通道中。

　　在客戶端使用Org1的管理員身份來建立新的應用通道，須要指定msp的ID信息，msp文件所在路徑，Orderering服務的tl證書位置，以及網絡中Ordering服務地址，應用通道名稱和交易文件。建立通道成功後，會自動在本地生成該應用通道同名的初識區塊bussinesschannel.block文件。只有擁有該文件才能夠加入建立的應用通道中。

　　應用通道使用管理員身份依次讓組織Org1和Org2中的全部節點都加入新的應用通道，須要指定所操做的Peer的地址，以及通道的初識區塊。

　　錨節點負責表明組織與其餘組織中的節點進行Gossip通訊。客戶端使用管理員的身份來更新錨節點配置，須要指定msp的ID信息，msp文件所在路徑，Ordering服務地址，所操做的應用通道，錨節點配置更新文件，以及Orderering服務tls證書位置

　　Peer加入應用通道後，能夠執行鏈碼相關操做，進行測試。鏈碼在調用以前，必須通過安裝和實例化兩個步驟，部署到Peer節點上。

　　監聽事件

　　　　用戶能夠經過block-listener工具來監聽網絡中的事件。該工具支持的命令行選項包括

　　　　　　-events-address "0.0.0.0:7053" ：監聽事件的來源地址，通常爲Peer節點的7053接口

　　　　　　-events-from-chaincode string：僅監聽與指定鏈碼相關的事件

　　　　　　-events-mspdir string：本地所使用的MSP路徑，默認在sampleconfig下

　　　　　　-events-mspid string：所使用的MSP的ID

　　鏈上代碼(chaincode)。簡稱鏈碼。通常指用戶編寫的應用代碼。鏈碼被部署在Fabric網絡節點上，運行在Docker中，並經過gRPC協議與相應的Peer節點進行交互，以操做分佈式帳本中的數據。用戶能夠經過命令行方式操做鏈碼，支持的鏈碼子命令包括install，instantiate，invoke，query，upgrade，packag，signpackage等。

 

 

　　安裝鏈碼

　　　　install命令將鏈碼的源碼和環境等內容封裝爲一個鏈碼安裝打包文件(Chaincode Install Package, CIP)，並傳輸到背書節點。背書節點解析後通常會保存在$CORE_PEER_FILESYSTEMPATH/chaincodes目錄下。安裝鏈碼只須要與Peer打交道

　　　　打包文件以name.version命名，主要包括：

　　　　　　ChaincodeDeploymentSpec：鏈碼的源碼和一些相關環境

　　　　　　鏈碼實例化策略，默認是任意通道上的MSP管理員身份

　　　　　　擁有這個鏈碼的實體的證書和簽名

　　　　　　安裝時，本地MSP管理員的簽名

　　　　ChaincodeDeploymentSpec(CDS)結構包括了最核心的ChaincodeSpec(CS)數據結構，同時也被其餘鏈碼命令使用。

　　主要步驟包括：

　　　　1.首先是構造簽名提案消息(SignedProposal)

　　　　　　調用InitCmdFactory(isEndorserRequired, isOrdererRequired bool)(*ChaincodeCmdFactory,error)方法，初始化EndoserClient，Signer等結構。

　　　　　　根據命令行參數進行解析，判斷是根據傳入的打包文件直接讀取ChaincodeDeploymentSpec(CDS)結構，仍是根據傳入參數從本地鏈碼文件來從新構造

　　　　　　以本地從新構造狀況爲例，首先根據命令行中傳入的路徑，名稱等信息，構造生成ChaincodeSpec(CS)結構

　　　　　　利用ChaincodeSpec結構，結合鏈碼包數據生成一個ChaincodeDeploymentSpec結構，調用本地的install(msg proto.Message, cf *ChaincodeCmdFactory,error)方法

　　　　　　install方法基於傳入的ChaincodeDeploymentSpec結構，構形成一個對生命週期管理系統鏈碼(LSCC)調用的ChaincodeSpec結構，其中Type爲ChaincodeSpec_GOLANG，ChaincodeId.Name爲「lscc」，Input爲「install」+ChaincodeDeploymentSpec。進一步地，構造一個LSCC地ChaincodeInvokcationSpec(CIS)結構，對ChaincodeSpec結構進行封裝

　　　　　　基於LSCC地ChaincodeInvocationSpec結構，添加頭部結構，生成一個提案(Proposal)結構，其中，通道頭部中類型爲ENDORSER_TRANSACTION，TxID爲對隨機數+簽名實體，進行Hash　　

　　　　　　對Proposal進行簽名，轉化爲一個簽名後的提案消息SignedProposal

　　　　2.經過EndorserClient經由gRPC通道發送給Peer的ProcessProposal(ctx context.Context, in *SignedProposal, opts ...grpc.CallOption)(*PropoalResponse, error)接口

　　　　3.Peer模式運行生命週期鏈碼的調用交易進行處理，檢查格式，簽名和權限等，經過則保存到本地文件系統

　　

　　實例化鏈碼

　　　　instantiate命令經過構造生命週期管理系統鏈碼(Lifecycle System Chaincode, LSCC)的交易，將安裝過的鏈碼在指定通道上進行實例化調用，在節點上建立容器啓動，並執行初始化操做。實例化鏈碼須要同時跟Peer和Orderer打交道。

　　　　執行instantiate命令的用戶身份必須知足實例化的策略，而且在所指定的通道上擁有寫權限。在instantiate命令中經過-P參數指定鏈碼的背書策略(Endorsement Policy)，不知足背書策略的鏈碼調用將在Commit階段被做廢。

　　主要步驟包括：

　　　　1.首先，相似鏈碼安裝命令，須要建立一個SignedProposal消息。注意instantiate和upgrade支持policy，escc，vscc等參數，LSCC的ChaincodeSpec結構中，Input中包括類型("deploy")，通道ID，ChaincodeDeploymentSpec結構，背書策略，escc和vscc等。

　　　　2.調用EndorserClient，發送gRPC消息，將簽名後的Proposal發給指定的Peer節點(Endorser)，調用ProcessProposal(ctx context.Context, in *SignedProposal, opts ...grpc.CallOption)(*ProposalResponse, error)方法，進行背書處理。節點會模擬運行LSCC的調用交易，啓動鏈碼容器。實例化成功後會返回ProposalResponse消息。

　　　　3.根據Peere返回的ProposalResponse消息，建立一個SignedTX(Envelop結構的交易，帶有簽名)

　　　　4.使用BroadcastClient將交易消息經過gRPC通道發給Orderer，Orderer會進行全網排序，並廣播給Peer進行交易確認

 

　　調用鏈碼

　　　　經過invoke命令能夠調用運行中的鏈碼的方法。「-c」參數指定的函數名和參數會被傳入到鏈碼的Invoke()方法進行處理。調用鏈碼操做須要同時跟Peer和Orderer打交道。invoke命令不支持指定鏈碼版本，只能調用最新版本的鏈碼。invoke是異步操做，invoke成功只能保證交易已經進入Orderer進行排序，但沒法保障最終寫到帳本中，有可能交易未經過Committer驗證而被拒絕。須要經過eventHub或查詢方式來進行確認交易是否最終寫入到帳本上

　　　　主要步驟以下：

　　　　　　1.建立一個SignedProposal消息。根據傳入的各類參數，生成ChaincodeSpec結構。而後根絕ChaincodeSpec，chainID，簽名屍體等，生成ChaincodeInvocationSpec結構。進而封裝生成Proposal結構，並進行簽名。

　　　　　　2.調用EndorserClient，發送gRPC消息，將簽名後的Proposal發給指定的Peer節點，調用ProcessProsal(ctc context.Context, in *SignedProposal, opts ...grpc.CallOption)(*ProposalResponse, error)方法，進行背書處理。節點會模擬運行鏈碼調用交易，成功後會返回ProposalResponse消息

　　　　　　3.根據Peer返回的ProposalResponse消息，建立一個SignedTX(Envelop結構的交易，帶有簽名)

　　　　　　4.使用BroadcastClient將交易消息經過gRPC通道發給Orderer進行全網排序並廣播給Peer進行確認提交

 

　　查詢鏈碼

　　　　查詢鏈碼能夠經過query命令進行。query命令的執行過程與invoke命令相似，實際上一樣是將-c指定的命令參數發送給鏈碼中的Invoke()方法執行。與invoke的區別在與，query操做只能查詢Peer上帳本狀態，不生成交易，也不須要與Orderer打交道。query不須要穿件SignedTx發送到Orderer，並且返回會查詢結果

　　　　主要過程以下：

　　　　　　1.根據傳入的各類參數，最終構造簽名提案，經過endorsercClient發送給指定的Peer

　　　　　　2.成功的話，獲取到ProposalResponse，打印出proposalResp.Response.Payload內容

　　　　

　　升級鏈碼

　　　　當須要修復鏈碼漏洞或進行功能拓展時，能夠對鏈碼進行升級，部署新版本的鏈碼。主要步驟以下：

　　　　　　1.安裝新版本的鏈碼，打包到Peer節點

　　　　　　2.運行upgrade命令升級指定通道上的鏈碼，須要指定相同的鏈碼名稱

　　　 升級過程會將給定的參數傳入新鏈碼的Init()方法中執行。只要Init()方法中對應的邏輯不改寫狀態，則升級先後鏈碼的全部狀態值能夠保持不變。若鏈碼未來要考慮在保留狀態狀況下升級，須要在編寫Init()方法時妥善處理升級時的邏輯。

　　　升級操做實現的主要過程以下：

　　　　　　1.首先建立一個封裝了LSCC調用交易的SignedProposal消息，

　　　　　　2.調用EndorserClient，發送gRPC消息，將簽名後的Proposal發送給指定的Peer節點，調用ProcessProposal(ctx context.Context, in *SignedProposal, opts ...grpc.CallOption)(*ProposalResponse, error)方法進行背書處理，節點會模擬運行LSCC的調用交易，啓動鏈碼容器

　　　　　　3.根據Peer返回的ProposalResponse消息，建立一個SignedTX(Envelop結構的交易，帶有簽名)

　　　　　　4.使用BroadcastClient將交易消息經過gRPC通道發給Orderer，Orderer會進行全網排序，並廣播給Peer進行確認提交

 

　　打包鏈碼和簽名

　　　　經過將鏈碼相關的數據進行封裝，能夠事先對其進行打包和簽名的操做。打包命令支持三個特定參數：

　　　　　　-s，--cc-package：表示建立完整打包形式，而不是僅打包ChaincodeDeploymentSpec結構

　　　　　　-S，--sign：對打包的文件使用本地的MSP(core.yaml中的localMspid指定)進行簽名

　　　　　　-i，--instantiate-policy string：指定實例化策略，可選參數

　　　  打包後的文件能夠直接用於install操做。

　　　　簽名命令則對一個打包文件進行簽名操做(添加當前MSP簽名到簽名列表中)。打包文件結構主要包括如下三部分信息：

　　　　　　ChaincodeDeploymentSpec結構

　　　　　　實例化策略信息

　　　　　　擁有者的簽名列表

　　　　事先的總體流程以下：

　　　　　　1.首先會調用InitCmdFactory(isEndorserRequired, isOrdererRequired bool)(*ChainCmdFactory, error)方法初始化Signer等結構。對於打包命令來講純屬本地操做，不須要Endorser和Orderer的連接

　　　　　　2.調用getChaincodeSpec()方法，解析命令行參數，根據所指定的數據生成ChaincodeSpec結構

　　　　　　3.根據ChaincodeSpec結構，結合鏈碼相關數據構造ChaincodeDeploymentSpec結構，並傳入getChaincodeInstallPakcage方法

　　　　　　4.getChaincodeInstallPackage方法基於傳入的ChaincodeDeploymentSpec結構，添加實例化策略和簽名信息等，生成一個SignedChaincodeDeploymentSpec，並進一步做爲Data生成一個Envlope結構，其中ChannelHeader指定爲CHAINCODE_PACKAGE

　　　　　　5.將Envelope結構序列化，寫到指定的本地文件

 

　　使用多通道

　　　　命令行下peer channel命令支持包括create，fetch，join，list，update等子命令。

　　　　　　create：建立一個新的應用通道

　　　　　　join：將本Peer節點加入到某個應用通道中

　　　　　　list：列出本Peer已經加入的全部的應用通道

　　　　　　fetch：從Ordering服務獲取指定應用通道的配置區塊

　　　　　　update：更新通道的配置信息，如錨節點配置

　　　　默認狀況下，客戶端執行命令會以本地的Peer爲操做對象，若要操做遠端的Peer，須要經過環境配置指定Peer的相關信息，包括地址或MSP配置等。而且執行命令的用戶身份須要以組織管理員身份進行。

 

　　建立通道

　　　　擁有建立通道權限的組織管理員身份才能調用create子命令，在指定的Ordering服務上建立新的應用通道，須要提供Ordering服務地址。經過提早建立的通道配置交易文件來指定配置信息。若不指定通道配置文件，則默認採用SampleConsortium配置和本地的MSP組織來構造配置交易結構。加入成功後，本地會產生該應用通道的初識區塊文件businesschannel.block。Ordering服務端也會輸出相似order|UTC[order/multichain] new Chain -> INFO 004 Created and starting new chain newchannel的成功消息

　　　　主要步驟包括：

　　　　　　1.客戶端調用sendCreateChainTransaction()，檢查指定的配置交易文件，或利用默認配置，構造一個建立應用通道的配置交易結構，封裝爲Envelope，指定channel頭部爲CONFIG_UPDATE

　　　　　　2.客戶端發送配置交易到Ordering服務

　　　　　　3.Orderer收到CONFIG_UPDATE消息後，檢查指定的通道還不存在，則開始新建過成，構造該應用的初識區塊

　　　　　　　　1.Orderer首先檢查通道應用配置中的組織是否都在建立的聯盟配置組織匯中

　　　　　　　　2.以後從系統通道中獲取Orderer相關的配置，並建立應用通道配置，對應mod_policy爲系統通道配置中的聯盟指定信息　　

　　　　　　　　3.根據CONFIG_UPDATE消息的內容更新獲取到的配置信息。全部配置發生變動後版本號都要更新

　　　　　　　　4.最後，建立簽名Proposal消息(頭部類型爲ORDERER_TRANSACTION)，發送到系統通道中，完成應用通道的建立過程

　　　　　　4.客戶端利用gRPC通道從Orderer服務獲取到該應用通道的初識區塊

　　　　　　5.客戶端將收到的區塊寫入到本地的chainID+".block"文件。這個文件後續會被須要加入到通道的節點使用

　　　

　　加入通道

　　　　join子命令會讓指定的Peer節點加入到指定的應用通道。須要提早擁有所加入應用通道的初識區塊文件，而且只有屬於通道的某個組織的管理員身份能夠成功執行該操做。加入通道命令主要經過調用Peer的配置系統鏈碼進行處理

　　　　主要步驟包括：

　　　　　　1.客戶端首先建立一個ChaincodeSpec結構，其input中的Args第一參數是CSCC，JoinChain，第二個操做爲所加入通道的初識區塊

　　　　　　2.利用ChaincodeSpec構造一個ChaincodeInvocationSpec結構

　　　　　　3.利用ChaincodeInvocationSpec，建立Proposal結構並進行簽名，channel頭部類型爲CONFIG

　　　　　　4.客戶端經過gRPC將Proposal簽名後發給Endorser，調用ProcessProposal(ctx context.Context, in *SignedProposal, opts ...grpc.CallOption)(*ProposalResponse, error)方法進行處理，主要經過配置系統鏈碼進行本地鏈的初始化工做

　　　　　　5.初始化完成後，便可收到來自通道內的Gossip消息等

 

　　列入所加入的通道

　　　　list子命令會列出指定的Peer節點已經加入的全部應用通道的列表。加入通道的命令也是主要經過調用Peer的配置系統鏈碼進行處理

　　　　主要步驟包括：

　　　　　　1.客戶端首先建立一個ChaincodeSpec結構，其中input中的Args第一個參數是CSCC.GetChannels

　　　　　　2.利用ChaincodeSpec構造一個ChaincodeInvocationSpec結構

　　　　　　3.利用ChaincodeInvocationSpec建立Proposal結構並進行簽名，channel頭部類型爲ENDORSER_TRANSACTION

　　　　　　4.客戶端經過gRPC將Proposal發送給Endorser，調用ProcessProposal(ctx context.Context, in *SignedProposal, opts ...grpc.CallOption)(*ProposalResponse, error)方法進行處理，主要是經過配置系統鏈碼查詢本地鏈信息並返回

　　　　　　5.命令執行成功後，客戶端會收到來自Peer端的回覆消息，從其中提取出應用通道列表信息並輸出

 

　　獲取某區塊

　　　　fetch子命令會向Ordering服務進行查詢，獲取到指定通道的指定區塊。並將收到的區塊寫入到本地的文件。命令格式爲peer channel fetch <newest|oldest|config|(number)> [outputfile] [flags]

　　　　主要步驟包括：

　　　　　　1.客戶端構造SeekInfo結構，該結構能夠指定要獲取的區塊範圍。這裏start，stop指定爲目標區塊

　　　　　　2.客戶端利用SeekInfo結構，構造Envelope並進行簽名，經過deliverClient經gRPC通道發給Ordering服務

　　　　　　3.從Orderer獲取指定通道的區塊後，寫到本地文件中

 

　　更新通道配置

　　　　update子命令的執行過程與create命令相似，會向Ordering服務發起更新配置交易請求。該命令執行也須要提早建立的通道更新配置交易文件來指定配置信息。

　　　

　　生產環境注意事項

　　　　節點角色差別

　　　　　　Fabric網絡中各個節點能夠擁有不一樣的角色。不一樣角色的衆多節點負責整個網絡功能中不一樣環節的工做負載，呈現了差別化的處理特性

　　　　　　Ordering服務須要處理整個網絡中全部的交易消息。Orderer節點採用Kafka集羣進行排序，本地維護了網絡中全部通道的區塊結構。對於Orderer節點須要增強內存，存儲，網絡IO方面的配置，而且採用集羣的方式提升可靠性

　　　　　　Peer節點處理處理區塊和背書交易以外，還須要對帳本狀態進行更新，對身份進行認證。同時，對於每一個通道來講，加入通道的節點都須要維護一個針對該通道的帳本結構和區塊鏈結構。所以，Peer節點則在計算，內存等方面須要進行強化配置，Endorser還能夠在簽名計算方面進行加權。對於打開文件句柄較多的節點。可能還須要對系統的uliit等參數進行調整。通常來說，鏈碼容器經常跟Peer節點處在同一服務器上，建議爲主服務預留2GB以上的空閒內存，而且通常每一個鏈碼容器分配256MB運行內存和1/10的CPU覈資源。

　　　　日誌級別

　　　　　　日誌級別越低，輸出日誌內容越詳細，出現問題後越方便調試。但輸出過多的日誌會拖慢系統的吞吐性能。對於關鍵路徑上的系統，一般要配置不低於Warning級別的日誌輸出；對於非關鍵路徑上的系統，則能夠採用不低於Info級別的日誌輸出。

　　　　鏈碼升級

　　　　　　Fabric升級時會調用鏈碼中的Init方法。經過合適地設計鏈碼，對其進行升級操做並不須要整個網絡的共識，所以對部分節點上鍊碼版本升級後，違背升級的節點仍然會運行舊版本的鏈碼。從數據一致性上考慮，在對某鏈碼代碼進行升級前，推薦先將全部該鏈碼的容器中止，並從Peer上備份並移除舊鏈碼部署文件，以後先在個別Peer節點上部署新鏈碼，對原有數據進行測試，成功後再其餘節點上進行升級操做。另外，在一開始編寫鏈碼過程當中，須要考慮鏈碼升級操做，經過傳入Init參數指定特定的升級方法來保護原有數據

　　　　組織結構

　　　　　　組織表明了維護網絡的獨立成員身份。通常來講，組成聯盟鏈的各個成員，每一個都擁有表明本身身份的組織。一個組織能夠進一步包括多個資源實體，這些資源實體彼此具備較強的信任度，而且對外都呈現同一組織身份。因爲Gossip協議目前在MSP範圍內進行傳播，所以通常建議將組織與MSP一一對應，即每一個組織擁有本身專屬的MSP。當一個組織擁有多個MSP時，不一樣成員之間的交互可能會帶來障礙；當多個組織同屬於一個MSP時，可能會發生不但願的跨組織數據泄漏。另外，一個組織能夠包括多個成員身份，多個Peer能夠經過使用同一成員身份來提升可用性。

　　　　證書管理

　　　　　　Fabric網絡中給你，CA負責證書的管理。CA佔據網絡中安全和隱私的最核心位置，所以須要增強安全方面的防禦。CA不該該暴漏在公共網絡域中，而且只能由有限個具有權限的用戶訪問。另外，根證書每每要進行離線保護，減小解除和泄漏的可能性。一般使用中間層證書來完成實體證書的簽發。同時，絕對不能直接用根證書做爲組織管理員的身份證書