hyperledger fabric1.0总体架构与记帐逻辑架构的分析

一、关于逻辑架构的一些问题

1）CLI客户端和peer节点之间是如何沟通的？

2）Peer节点之间如何数据传输处理，与cli和peer之间的方式有何不一样？

3）数据什么时候进入orderer节点，orderer节点是如何处理的？（0.6里面就是共识这块怎么处理）

4）链码（CC）是如何与节点或cli或rest api交互的，怎么实现的？

二、新旧架构的比较

旧版本（0.6）的运行时架构：

新版本（1.0）的运行时架构：

三、fabric1.0记帐的逻辑分析

Fabric帐本逻辑架构

Fabric 1.0中的帐本分为3种：

区块链数据，这是用文件系统存储在Committer节点上的。区块链中存储了Transaction的读写集。

为了检索区块链的方便，因此用LevelDB对其中的Transaction进行了索引。

ChainCode操做的实际数据存储在State Database中，这是一个Key Value的数据库，默认采用的LevelDB，如今1.0也支持使用CouchDB做为State Database。

当执行a向b转帐10元，咱们在cli中执行的命令为：

peer chaincode invoke -o orderer.example.com:7050  --tls $CORE_PEER_TLS_ENABLED --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/cacerts/ca.example.com-cert.pem  -C mychannel -n devincc -c '{"Args":["invoke","a","b","10"]}'

 这个过程是这样的：

其中peer chaincode invoke代表这是一个Transaction调用。-c '{"Args":["invoke","a","b","10"]}'中的”invoke”说明调用的是example02.go中的invoke函数，具体函数咱们能够看看到底实现了什么功能：

// Transaction makes payment of X units from A to B

func (t *SimpleChaincode) invoke(stub shim.ChaincodeStubInterface, args []string) pb.Response {
var A, B string // Entities
var Aval, Bval int // Asset holdings
var X int // Transaction value
var err error
if len(args) != 3 {
return shim.Error("Incorrect number of arguments. Expecting 3")
    }
A = args[0]
B = args[1]
// Get the state from the ledger
// TODO: will be nice to have a GetAllState call to ledger
Avalbytes, err := stub.GetState(A)
if err != nil {
return shim.Error("Failed to get state")
    }
if Avalbytes == nil {
return shim.Error("Entity not found")
    }
Aval, _ = strconv.Atoi(string(Avalbytes))
Bvalbytes, err := stub.GetState(B)
if err != nil {
return shim.Error("Failed to get state")
    }

if Bvalbytes == nil {
return shim.Error("Entity not found")
    }

Bval, _ = strconv.Atoi(string(Bvalbytes))
// Perform the execution
X, err = strconv.Atoi(args[2])
if err != nil {
return shim.Error("Invalid transaction amount, expecting a integer value")
    }
Aval = Aval - X
Bval = Bval + X
    fmt.Printf("Aval = %d, Bval = %d\n", Aval, Bval)
// Write the state back to the ledger
err = stub.PutState(A, []byte(strconv.Itoa(Aval)))
if err != nil {
return shim.Error(err.Error())
    }
err = stub.PutState(B, []byte(strconv.Itoa(Bval)))
if err != nil {
return shim.Error(err.Error())
    }
return shim.Success(nil)
}

其中主要的4个关于StateDatabase调用是：

Avalbytes, err := stub.GetState(A)
Bvalbytes, err := stub.GetState(B)
err = stub.PutState(A, []byte(strconv.Itoa(Aval)))
err = stub.PutState(B, []byte(strconv.Itoa(Bval)))

1.客户端SDK把'{"Args":["invoke","a","b","10"]}'这些参数发送到endorser peer节点，
2.endorser peer会与ChainCode的docker实例通讯，并为其提供模拟的State Database的读写集，也就是说ChainCode会执行完逻辑，可是并不会在stub.PutState的时候写数据库。
3.endorser把这些读写集连同签名返回给Client SDK。
4.SDK再把读写集发送给Orderer节点，Orderer节点是进行共识的排序节点，在测试的状况下，只启动一个orderer节点，没有容错。在生产环境，要进行Crash容错，须要启用Zookeeper和Kafka。在1.0中移除了拜占庭容错，没有0.6的PBFT，也没有传说中的SBFT，不得不说是一个遗憾。
5.Orderer节点只是负责排序和打包工做，处理的结果是一个Batch的Transactions，也就是一个Block，这个Block的产生有两种状况，一种状况是Transaction不少，Block的大小达到了设定的大小，而另外一种状况是Transaction不多，没有达到设定的大小，那么Orderer就会等，等到大小足够大或者超时时间。这些设置是在configtx.yaml中设定的。
6.打包好的一堆Transactions会发送给Committer Peer提交节点,
7.提交节点收到Orderer节点的数据后，会先进行VSCC校验，检查Block的数据是否正确。接下来是对每一个Transaction的验证，主要是验证Transaction中的读写数据集是否与State Database的数据版本一致。验证完Block中的全部Transactions后，提交节点会把吧Block写入区块链。而后把全部验证经过的Transaction的读写集中的写的部分写入State Database。另外对于区块链，自己是文件系统，不是数据库，全部也会有把区块中的数据在LevelDB中创建索引。

 

查询a帐户的cli命令是：

peer chaincode query -C mychannel -n devincc -c '{"Args":["query","a"]}'

这样系统会调用ChainCode中的invoke函数，可是传入的function name是query。也就是会执行以下代码：

} else if function == "query" {
// the old "Query" is now implemtned in invoke
return t.query(stub, args)
}
// query callback representing the query of a chaincode
func (t *SimpleChaincode) query(stub shim.ChaincodeStubInterface, args []string) pb.Response {
var A string // Entities
var err error
if len(args) != 1 {
return shim.Error("Incorrect number of arguments. Expecting name of the person to query")
}
A = args[0]
// Get the state from the ledger
Avalbytes, err := stub.GetState(A)
if err != nil {
jsonResp := "{\"Error\":\"Failed to get state for " + A + "\"}"
return shim.Error(jsonResp)
}

if Avalbytes == nil {
jsonResp := "{\"Error\":\"Nil amount for " + A + "\"}"
return shim.Error(jsonResp)
}
jsonResp := "{\"Name\":\"" + A + "\",\"Amount\":\"" + string(Avalbytes) + "\"}"
fmt.Printf("Query Response:%s\n", jsonResp)
return shim.Success(Avalbytes)
}

咱们能够看到，咱们只是调用了stub.GetState(A)，并无写操做，那么会像前面说的Transaction同样那么复杂吗？答案是不会。由于调用调用的是peer query，在代码中，只有invoke的时候才会执行Transaction步骤中的四、五、六、7.可是若是咱们使用peer invoke，那么会怎么样呢？好比以下的命令：

peer chaincode invoke -o orderer.example.com:7050  --tls $CORE_PEER_TLS_ENABLED --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/cacerts/ca.example.com-cert.pem  -C mychannel -n mycc -c '{"Args":["query","a"]}'

那么从代码上来看，虽然咱们是一个查询，却会以Transaction的生命周期来处理。

 

Fabric不支持对同一个数据的并发事务处理，也就是说，若是咱们同时运行了a->b 10元，b->a 10元，那么只会第一条Transaction成功，而第二条失败。由于在Committer节点进行读写集版本验证的时候，第二条Transaction会验证失败。这是我彻底没法接受的一点！

Fabric是异步的系统，在Endorser的时候a->b 10元，b->a 10元都会返回给SDK成功，而第二条Transaction在Committer验证失败后不进行State Database的写入，可是并不会通知Client SDK，因此必须使用EventHub通知Client或者Client从新查询才能知道是否写入成功。

无论在提交节点对事务的读写数据版本验证是否经过，由于Block已经在Orderer节点生成了，因此Block是被整块写入区块链的，而在State Database不会写入，因此会在Transaction以外的地方标识该Transaction是无效的。