Hyperledger Fabric 消息協議
Fabric中大量採用了gRPC消息在不同組件之間進行通信交互，主要包括如下幾種情況：客戶端訪問Peer節點，客戶端和Peer節點訪問排序節點，鏈碼容器與Peer節點交互，以及多個Peer節點之間的Gossip交互。
消息結構
除了Peer節點之間的Gossip通信外，大多都採用了信封（Envelope）結構來對消息進行封裝.
普通信封結構並不複雜，包括一個載荷（Payload）域存放數據，以及對載荷域中內容進行簽名的簽名（Signature）域。載荷域中又包括頭部（Header）域記錄類型、版本、簽名者信息等元數據，以及數據（Data）域，記錄消息內容。
頭部域是一個通用的結構。包括兩種頭部：通道頭（ChannelHeader）和簽名頭（Signature-Header）。通道頭中記錄瞭如下與通道和交易相關的很多信息。
●Type：int32類型，代表了結構體（如Envelope）的類型。結構體消息根據類型不同，其Payload可以解碼爲不同的結構。類型可以爲MESSAGE、CONFIG、CONFIG_UPDATE、ENDORSER_TRANSACTION、ORDERER_TRANSACTION、DELIVER_SEEK_INFO、CHAINCODE_PACKAGE、PEER_ADMIN_OPERATION等。
●Version：int32類型，版本號記錄了消息協議的版本，一般爲0。
●Timestamp：*google_protobuf.Timestamp類型，消息創建的時間。
●ChannelID：string類型，消息所關聯的通道ID。
●TxID：string類型，交易的ID，由交易發起者創建。
●Epoch：uint64類型，所屬的世代，目前指定爲所屬區塊的高度。
●Extension：[]byte類型，擴展域。
●TlsCertHash：[]byte類型。如果啓用了雙向TLS認證，則此處爲客戶端TLS證書的Hash值。
簽名頭中主要記錄簽名者的身份信息。
客戶端訪問Peer節點
客戶端通過SDK和Endorser Peer進行交互，執行鏈碼相關操作（安裝、實例化、升級鏈碼以及調用），加入、列出應用通道和監聽事件操作等。
除監聽事件外，大部分消息都採用了SignedProposal結構（定義在fabric-protos-go項目的peer/chaincode.pb.go文件），消息中ChannelHeader.Type爲ENDORSER_TRANSACTION或CONFIG，發往的gRPC服務地址爲/protos.Endorser/ProcessProposal。監聽事件則通過DeliverClient接口類型來實現，包括Deliver、DeliverFiltered、DeliverWithPrivateData三種方法。
SignedProposal消息結構中包括Proposal和對其的簽名。Proposal消息結構中同樣包括Header域、Payload域，以及擴展域。其中，Payload域和擴展域如何解碼都取決於Channel-Header中的Type指定的類型。
客戶端、Peer節點訪問Orderer
客戶端通過SDK和Orderer進行交互，執行鏈碼實例化、調用和升級，應用通道創建和更新，以及區塊結構獲取等操作。Peer節點可以直接向Orderer請求獲取區塊結構。兩者採用了同樣的獲取接口。
請求消息都採用了Envelope結構，並且都發往/orderer.AtomicBroadcast/Broadcast gRPC服務地址。從Orderer獲取信息時，則發往/orderer.AtomicBroadcast/Deliver gRPC服務地址。
鏈碼和Peer節點交互
對於原生鏈碼，在鏈碼容器啓動後，會向Peer節點進行註冊，gRPC地址爲/protos.ChaincodeSupport/Register。對於外部鏈碼，在其啓動後，Peer節點會主動發起連接請求，gRPC地址爲/protos.Chaincode/Connect。
鏈碼和Peer之間的交互消息爲ChaincodeMessage結構其中，Payload域中可以包括各種Chaincode操作消息，如GetHistoryForKey、GetQueryResult、PutStateInfo、GetStateByRange等。
註冊完成後，雙方建立起雙工通道，通過更多消息類型實現多種交互.
Peer節點之間Gossip交互
Peer之間可以通過Gossip協議來完成鄰居探測、Leader選舉、區塊分發、私密數據同步等過程，主要原理爲通過GossipClient客戶端的GossipStream雙向流進行通信，發送Signed-GossipMessage消息結構，gRPC服務地址主要爲/gossip.Gossip/GossipStream。
此外，Peer可通過單獨的Ping服務對遠端節點在線狀態進行探測，gRPC服務地址爲/gossip.Gossip/Ping。
Gossip交互過程
總結Gossip交互過程如圖14-16所示。利用不同的消息體，完成Peer之間的信息同步。
Gossip消息結構
Gossip採用簽名信封結構（SignedGossipMessage）用來封裝Gossip消息（GossipMessage）和對應的信封結構（Envelope）。
Gossip消息標籤
GossipMessage爲核心的數據結構。其可能的標籤值（GossipMessage_Tag）如下所示，這些標籤默認帶有GossipMessage前綴。
●UNDEFINED：標籤未定義，當標籤爲空時返回該值。
●EMPTY：空標籤，用於建立連接、心跳、請求和響應成員消息。
●ORG_ONLY：僅限組織內消息，如私密數據。
●CHAN_ONLY：僅限通道內消息。
●CHAN_AND_ORG：限通道內同一組織內，如獲取區塊數據。
●CHAN_OR_ORG：限通道內或限組織內，如狀態信息。
Gossip消息內容結構
GossipMessage通過消息內容類型來應用到不同場景。合法的消息內容結構（isGossipMessage_Content）下面詳細介紹，這些結構默認帶有GossipMessage前綴。
（1）成員消息適用於鄰居發現場景，定期維護存活的鄰居信息，不侷限在通道內，主要由gossip/discovery模塊實現。
（2）拉取消息
適用於從遠程節點拉取身份或區塊數據，主要數據結構爲：gossip/gossip/pull/pullstore.go#Mediator和gossip/gossip/algo/pull.go#PullEngine。包括如下兩種消息類型：
●PullMsgType_IDENTITY_MSG，獲取對方的身份信息，消息標籤爲EMPTY，不侷限在通道內。
●PullMsgType_BLOCK_MSG，獲取區塊數據。消息標籤爲CHAN_AND_ORG，侷限在通道內的同一組織內。
（3）數據消息
適用於從遠程節點同步區塊或私密數據。
（4）狀態消息
適用於與遠程節點同步賬本狀態。
（5）其他消息
其他消息包括連接消息、選舉Leader消息和空消息。
