Structural analysis of hyperledger fabric (I)

The previous analysis program focused on detailed analysis , There is no concept of a framework , It took two days to analyze and sort it out hyperledger fabric Architecture design , The analysis of the program did not refer to any data , Please correct me if there is any mistake , Common progress .

The author has the following questions before analyzing the procedure in detail ：

1）CLI（ Command line ） How the client sends commands to Peer node

2） Ben Peer How nodes receive data from other nodes , How to deal with the received data , The way and 1 What's the difference

3） When and how data is sent consensus modular

4）consensus How is the internal structure of the module Why does it look like helper executor pbft controller Put the folders together , Save respective handles , Mutual invocation

5）ChainCode（ Chain code , abbreviation CC） How to receive Peer The operation of it 、 Access to the

6）ChainCode How to call fabric API To query the written data

7） In the process of reading the source code initialization ,Peer Nodes create a large number of Server, these Server How we use it in the subsequent process

notes ： I am interested in the database 、Docker I don't know much about relevant knowledge , Try to avoid introducing these two parts so as not to mislead the reader .

The following will slowly penetrate the above issues .

Server ：

Every Server effect ：

AdminServer： Control the fate of the node , You can delete the process where the node is located .（Start Stop GetStatus ）

EventHubServer：Peer The node supports the client to listen to specified events , for example Rejection etc. . The client needs to register what it cares about first Events, When the event occurs trigger monitor .

OpenChainServer： External provision ledger Access interface , involve GetBlockchainInfo GetBlockByNumber etc. .

DevopsServer： Responsible for working with CLI Client docking , Outside CC Access to operation ,Deploy invoke query.

ChaincodeSupportServer： Responsible for working with shim/Chaincode signal communication ,ChainCode All calls to receive and send must be associated with the Server Information exchange .

PeerServer： The Server It's a Engine,Engine Associated with the internal message response implementation , At the same time for the surrounding Peer Node creation Client Communicate with .

RESTServer： The Server No analysis , Should be REST Interface format related .

First level module classification ：

Client： Create the client corresponding to the server , It can be understood as other nodes or CLI client etc. .

Protos： Middle layer ,Server And Client End API Interface definition

ServerProcess： Service response handler , Including all types of HandleMessage.

Consensus： Consensus module , At present, it is PBFT NOOPS

ChainCode Shim： In the code shim Not consistent with my understanding , take ChainCodeSupport It should also count to shim, The function of this module is to connect Peer Node and ChainCode The media of , use shim It can also be described .

ChainCode： Chain code , application ( For example, smart contract ).

DB: data storage .

Library： There is one in the code called Vendor Folder , The functional modules involved in this folder are self-contained , for example grpcServer etc.

API： ChainCode It will call Peer Node information .

Crypto： With data encryption and decryption . 

Ledger： Book operation .

The code uses Handler Trigger mode , Be careful when tracking code programs handler Object assignment position , Otherwise, it is easy to make mistakes HandleMessage, these Handler The names of processing functions are basically the same , Easy to operate disorderly .

Here are a few processes that readers should be most concerned about ：

1）Client adopt CLI To perform a invoke command

2） A node sends to this node ViewChange command

3）ChainCode call API putStatus

4）Consensus technological process

One 、 Client adopt CLI To perform a invoke command

1） stay Peer When the node is initialized establish DevopsServer

serverDevops := core.NewDevopsServer(peerServer)
pb.RegisterDevopsServer(grpcServer, serverDevops)

2）DevopsServer Set up Service standard , for example Invoke Message, call _Devops_Invoke_Handler function

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） among _Devops_Invoke_Handler Function in Protos modular , It is responsible for Client The accessed information is transferred to the corresponding Server modular

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） In the function devops Processing in the server code

func (d *Devops) Invoke(ctx context.Context, chaincodeInvocationSpec *pb.ChaincodeInvocationSpec) (*pb.Response, error) {
	return d.invokeOrQuery(ctx, chaincodeInvocationSpec, chaincodeInvocationSpec.ChaincodeSpec.Attributes, true)
}

5） Streamlining invokeOrQuery Code ,d.coord yes PeerServer object , ExecuteTransaction It's corresponding to Engine Implementation method

func (d *Devops) invokeOrQuery(ctx context.Context, chaincodeInvocationSpec *pb.ChaincodeInvocationSpec, attributes []string, invoke bool) (*pb.Response, error) {

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

6） This request is encapsulated into a transaction Struct, The processing is in PeerServer in .

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） Think about it , In the end transaction Is to hand it over to Consensus To deal with , So how to deliver it ？ Just below p.engine.ProcessTransactionMsg, among "p" Generation refers to PeerServer,engine Is to create PeerServer It's designated at the time of Engine, And this Engine Of handler Realize in Consensus in , In the realization of EngineHandler Loaded during PBFT Algorithm . therefore ProcessTransactionMsg The function is implemented in consensus modular engine In the code . This solves the questions raised at the beginning 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） From here on into consensus Internal processing , ad locum Consensus Modules are analyzed separately .

func (eng *EngineImpl) ProcessTransactionMsg(msg *pb.Message, tx *pb.Transaction) (response *pb.Response) {
       err := eng.consenter.RecvMsg(msg, eng.peerEndpoint.ID)
}

Draw a diagram to illustrate the above process ：

 

What is not reflected in this figure is that Devops Server Will be created PeerServer Object is passed in as a construction parameter , and PeerServer The process of creation is to create Engine The process of , Also load Engine-handler The process of , and Engine-handler Implementation in Consensus modular . The figure is directly from Devops Server Jump in Consensus The module is somewhat abrupt .