區塊鏈愛好者（QQ：53016353）
先前分析程序着眼於細節分析，這樣沒有框架的概念，花了兩天時間分析整理了一下hyperledger fabric的架構設計，分析該程序沒有參照任何資料，如有錯誤歡迎指正，共同進步。
筆者在詳細分析程序前有以下疑問：
1）CLI（命令行）客戶端如何發送命令給Peer節點
2）本Peer節點如何接收其他節點的數據，接收到數據又如何處理，處理的方式和1又有什麼區別
3）數據是何時又是如何被送入consensus模塊
4）consensus模塊內部又是如何架構的 爲什麼看起來helper executor pbft controller文件夾交至在一起，保存各自句柄，相互調用
5）ChainCode（鏈碼，簡稱CC）是如何接收到Peer對其的操作、訪問的
6）ChainCode是如何調用fabric API來查詢寫入數據的
7）在閱讀源碼初始化過程中，Peer節點會創建大量Server，這些Server後續過程我們是如何使用的
注：本人對於數據庫、Docker相關知識不是很瞭解，儘量避免關於這兩個部分的介紹以免錯誤的引導讀者。
下面會慢慢的滲透以上涉及的問題。
Server ：
每個Server作用：
AdminServer：控制該節點的命運，可以刪除該節點所在的進程。（Start Stop GetStatus ）
EventHubServer：Peer節點支持客戶端對指定事件進行監聽，例如Rejection等。客戶端需要先註冊自己關心的Events，當事件發生時trigger 監聽者。
OpenChainServer：對外提供ledger的訪問接口，涉及GetBlockchainInfo GetBlockByNumber等。
DevopsServer：負責與CLI Client對接，外部進行CC操作的入口，Deploy invoke query。
ChaincodeSupportServer：負責與shim/Chaincode通信，ChainCode的所有調用接收發送都要與該Server信息交互。
PeerServer：該Server是一個Engine，Engine關聯了內部消息響應實現，同時爲周圍Peer節點創建Client與之通信。
RESTServer：該Server沒有進行分析，應該是REST接口格式相關。
一級模塊分類：
Client： 之前創建服務器與之對應的客戶端，可以理解成其他節點或者CLI client等。
Protos： 中間層，Server與Client端 API接口定義
ServerProcess：服務響應處理函數，包括各類型的HandleMessage。
Consensus： 共識模塊，目前採用的是PBFT NOOPS
ChainCode Shim：代碼中shim和我理解的不一致，將ChainCodeSupport也應該算到shim，該模塊的作用是連接Peer節點與ChainCode的媒介，用shim形容也可。
ChainCode： 鏈碼，應用(例如智能合約)。
DB: 數據存儲。
Library： 代碼裏有一個叫做Vendor的文件夾，該文件夾裏涉及的功能模塊自成一體，例如grpcServer等
API： ChainCode裏面會調用Peer節點信息。
Crypto： 伴隨着數據加解密。
Ledger： 賬本操作。
該代碼使用Handler觸發模式，在跟蹤代碼程序時要注意handler對象賦值位置，否則容易找錯HandleMessage，這些Handler處理函數命名基本相同，容易操作混亂。
下面分析幾個讀者應該最關心的流程：
1）Client通過CLI執行一條invoke命令
2）某節點發送給該節點ViewChange命令
3）ChainCode調用API putStatus
4）Consensus流程
一、 Client通過CLI執行一條invoke命令
1）在Peer節點初始化的時候 創建DevopsServer
serverDevops := core.NewDevopsServer(peerServer)
pb.RegisterDevopsServer(grpcServer, serverDevops)
2）DevopsServer設置Service規範，例如Invoke Message，調用_Devops_Invoke_Handler函數
var _Devops_serviceDesc = grpc.ServiceDesc{
ServiceName: "protos.Devops",
HandlerType: (*DevopsServer)(nil),
Methods: []grpc.MethodDesc{
{
MethodName: "Login",
Handler: _Devops_Login_Handler,
},
{
MethodName: "Build",
Handler: _Devops_Build_Handler,
},
{
MethodName: "Deploy",
Handler: _Devops_Deploy_Handler,
},
{
MethodName: "Invoke",
Handler: _Devops_Invoke_Handler,
},
{
MethodName: "Query",
Handler: _Devops_Query_Handler,
},
{
MethodName: "EXP_GetApplicationTCert",
Handler: _Devops_EXP_GetApplicationTCert_Handler,
},
{
MethodName: "EXP_PrepareForTx",
Handler: _Devops_EXP_PrepareForTx_Handler,
},
{
MethodName: "EXP_ProduceSigma",
Handler: _Devops_EXP_ProduceSigma_Handler,
},
{
MethodName: "EXP_ExecuteWithBinding",
Handler: _Devops_EXP_ExecuteWithBinding_Handler,
},
},
Streams: []grpc.StreamDesc{},
}
3）其中_Devops_Invoke_Handler函數在Protos模塊，其負責將Client接入的信息傳遞到對應的Server模塊
func _Devops_Invoke_Handler(srv interface{}, ctx context.Context, dec func(interface{}) error) (interface{}, error) {
in := new(ChaincodeInvocationSpec)
if err := dec(in); err != nil {
return nil, err
}
out, err := srv.(DevopsServer).Invoke(ctx, in)
if err != nil {
return nil, err
}
return out, nil
}
4）在函數在devops服務端代碼中處理
func (d *Devops) Invoke(ctx context.Context, chaincodeInvocationSpec *pb.ChaincodeInvocationSpec) (*pb.Response, error) {
return d.invokeOrQuery(ctx, chaincodeInvocationSpec, chaincodeInvocationSpec.ChaincodeSpec.Attributes, true)
}
5）精簡invokeOrQuery代碼，d.coord 是PeerServer對象，ExecuteTransaction 是對應Engine的實現方法
func (d *Devops) invokeOrQuery(ctx context.Context, chaincodeInvocationSpec *pb.ChaincodeInvocationSpec, attributes []string, invoke bool) (*pb.Response, error) {
resp := d.coord.ExecuteTransaction(transaction)
}
6）本次請求被封裝成交易Struct，該處理是在PeerServer中。
func (p *Impl) ExecuteTransaction(transaction *pb.Transaction) (response *pb.Response) {
if p.isValidator {
response = p.sendTransactionsToLocalEngine(transaction)
} else {
peerAddresses := p.discHelper.GetRandomNodes(1)
response = p.SendTransactionsToPeer(peerAddresses[0], transaction)
}
return response
}
7）思考可知，最終這筆transaction是要交給到Consensus進行處理，那麼如何傳遞的呢？就在下面p.engine.ProcessTransactionMsg，其中"p"代指PeerServer，engine是在創建PeerServer的時候指定的Engine，而這個Engine的handler實現在Consensus裏，在實現EngineHandler過程中加載了PBFT算法。所以ProcessTransactionMsg函數的實現在consensus模塊engine代碼裏。這樣解決了開始時提出的疑問3)。
func (p *Impl) sendTransactionsToLocalEngine(transaction *pb.Transaction) *pb.Response {
peerLogger.Debugf("Marshalling transaction %s to send to local engine", transaction.Type)
data, err := proto.Marshal(transaction)
if err != nil {
return &pb.Response{Status: pb.Response_FAILURE, Msg: []byte(fmt.Sprintf("Error sending transaction to local engine: %s", err))}
}
var response *pb.Response
msg := &pb.Message{Type: pb.Message_CHAIN_TRANSACTION, Payload: data, Timestamp: util.CreateUtcTimestamp()}
peerLogger.Debugf("Sending message %s with timestamp %v to local engine", msg.Type, msg.Timestamp)
response = p.engine.ProcessTransactionMsg(msg, transaction)
return response
}
8）從這裏開始進入了consensus內部處理，在這裏Consensus模塊是單獨分析。
func (eng *EngineImpl) ProcessTransactionMsg(msg *pb.Message, tx *pb.Transaction) (response *pb.Response) {
err := eng.consenter.RecvMsg(msg, eng.peerEndpoint.ID)
}
畫圖說明上述流程：
該圖中沒有體現的一點是在Devops Server創建的時候將PeerServer對象作爲構造參數傳入，而PeerServer創建的過程就是創建Engine的過程，也是加載Engine-handler的過程，而Engine-handler的實現在Consensus模塊。圖中直接從Devops Server 跳入Consensus模塊有些突兀。