类别:比特币资讯 / 日期:2020-10-10 / 浏览:28 / 评论:0

从前剖析程序着眼于细节剖析,这样没有结构的概念,花了两天时刻剖析整理了一下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节点会创立很多Serer,这些Serer后续进程咱们是怎么运用的

注:自己关于数据库、Docker相关常识不是很了解,尽量防止关于这两个部分的介绍避免过错的引导读者。
下面会渐渐的浸透以上触及的问题。

Serer :

hyperledger fabric 结构剖析(一) - 区块链教程



每个Serer效果:
AdminSerer:操控该节点的命运,能够删去该节点地点的进程。(Start Stop GetStatus )
EentHubSerer:Peer节点支撑客户端对指定事情进行监听,例如Rejection等。客户端需求先注册自己关怀的Eents,当事情产生时trigger 监听者。
OpenChainSerer:对外供给ledger的拜访接口,触及GetBlockchainInfo GetBlockByNumber等。
DeopsSerer:担任与CLI Client对接,外部进行CC操作的进口,Deploy inoke query。
ChaincodeSupportSerer:担任与shim/Chaincode通讯,ChainCode的一切调用接纳发送都要与该Serer信息交互。
PeerSerer:该Serer是一个Engine,Engine相关了内部消息呼应完成,一起为周围Peer节点创立Client与之通讯。
RESTSerer:该Serer没有进行剖析,应该是REST接口格局相关。


一级模块分类:

hyperledger fabric 结构剖析(一) - 区块链教程


Client: 之前创立服务器与之对应的客户端,能够了解成其他节点或许CLI client等。
Protos: 中间层,Serer与Client端 API接口界说
SererProcess:服务呼应处理函数,包含各类的HandleMessage。
Consensus: 一致模块,现在选用的是PBFT NOOPS
ChainCode Shim:代码中shim和我了解的不一致,将ChainCodeSupport也应该算到shim,该模块的效果是衔接Peer节点与ChainCode的前言,用shim描述也可。
ChainCode: 链码,运用(例如智能合约)。
DB: 数据存储。
Library: 代码里有一个叫做Vendor的文件夹,该文件夹里触及的功能模块自成一体,例如grpcSerer等
API: ChainCode里边会调用Peer节点信息。
Crypto: 伴随着数据加解密。
Ledger: 账本操作。

该代码运用Handler触发形式,在盯梢代码程序时要注意handler目标赋值方位,不然简单找错HandleMessage,这些Handler处理函数命名根本相同,简单操作紊乱。

下面剖析几个读者应该最关怀的流程:
1)Client经过CLI履行一条inoke指令
2)某节点发送给该节点ViewChange指令
3)ChainCode调用API putStatus
4)Consensus流程

一、 Client经过CLI履行一条inoke指令
1)在Peer节点初始化的时分 创立DeopsSerer


sererDeops := core.NewDeopsSerer(peerSerer)
pb.RegisterDeopsSerer(grpcSerer, sererDeops)


2)DeopsSerer设置Serice标准,例如Inoke Message,调用_Deops_Inoke_Handler函数

ar _Deops_sericeDesc = grpc.SericeDesc{
SericeName: “protos.Deops”,
HandlerType: (*DeopsSerer)(nil),
Methods: []grpc.MethodDesc{
{
MethodName: “Login”,
Handler: _Deops_Login_Handler,
},
{
MethodName: “Build”,
Handler: _Deops_Build_Handler,
},
{
MethodName: “Deploy”,
Handler: _Deops_Deploy_Handler,
},
{
MethodName: “Inoke”,
Handler: _Deops_Inoke_Handler,
},
{
MethodName: “Query”,
Handler: _Deops_Query_Handler,
},
{
MethodName: “EXP_GetApplicationTCert”,
Handler: _Deops_EXP_GetApplicationTCert_Handler,
},
{
MethodName: “EXP_PrepareForTx”,
Handler: _Deops_EXP_PrepareForTx_Handler,
},
{
MethodName: “EXP_ProduceSigma”,
Handler: _Deops_EXP_ProduceSigma_Handler,
},
{
MethodName: “EXP_ExecuteWithBinding”,
Handler: _Deops_EXP_ExecuteWithBinding_Handler,
},
},
Streams: []grpc.StreamDesc{},
}

3)其间_Deops_Inoke_Handler函数在Protos模块,其担任将Client接入的信息传递到对应的Serer模块

func _Deops_Inoke_Handler(sr interface{}, ctx context.Context, dec func(interface{}) error) (interface{}, error) {
in := new(ChaincodeInocationSpec)
if err := dec(in); err != nil {
return nil, err
}
out, err := sr.(DeopsSerer).Inoke(ctx, in)
if err != nil {
return nil, err
}
return out, nil
}

4)在函数在deops服务端代码中处理

func (d *Deops) Inoke(ctx context.Context, chaincodeInocationSpec *pb.ChaincodeInocationSpec) (*pb.Response, error) {
return d.inokeOrQuery(ctx, chaincodeInocationSpec, chaincodeInocationSpec.ChaincodeSpec.Attributes, true)
}

5)精简inokeOrQuery代码,d.coord 是PeerSerer目标,ExecuteTransaction 是对应Engine的完成办法

func (d *Deops) inokeOrQuery(ctx context.Context, chaincodeInocationSpec *pb.ChaincodeInocationSpec, attributes []string, inoke bool) (*pb.Response, error) {

resp := d.coord.ExecuteTransaction(transaction)
}

6)本次恳求被封装成买卖Struct,该处理是在PeerSerer中。

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”代指PeerSerer,engine是在创立PeerSerer的时分指定的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 AMPLpb.Response{Status: pb.Response_FAILURE, Msg: []byte(fmt.Sprintf(“Error sending transaction to local engine: %s”, err))}
}

ar response *pb.Response
msg := AMPLpb.Message{Type: pb.Message_CHAIN_TRANSACTION, Payload: data, Timestamp: util.CreateUtcTimestamp()}
peerLogger.Debugf(“Sending message %s with timestamp % 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.RecMsg(msg, eng.peerEndpoint.ID)
}

画图阐明上述流程:

hyperledger fabric 结构剖析(一) - 区块链教程



该图中没有表现的一点是在Deops Serer创立的时分将PeerSerer目标作为结构参数传入,而PeerSerer创立的进程便是创立Engine的进程,也是加载Engine-handler的进程,而Engine-handler的完成在Consensus模块。图中直接从Deops Serer 跳入Consensus模块有些突兀。

打赏
版权声明 : 本文未使用任何知识共享协议授权,您可以任何形式自由转载或使用。

 可能感兴趣的文章

评论区

发表评论 / 取消回复

必填

选填

选填

◎欢迎讨论,请在这里发表您的看法及观点。