本文介绍了Fabric的架构，以及通过一个简单的Demo来熟悉整个交易流程。
Hyperledger fabric V1.0的架构
如下图所示：
application提供各种语言的SDK接口。
membership也就是fabric-ca提供成员服务，用来管理身份，提供授权和认证。
peer负责模拟交易和记账
- Endorser（背书）用来当peer执行一个交易以后返回yes/no。
- Committer将验证过的区块追加到通道上各个账本的副本。
- Ledger就是账本啦。
- Chaincode用来编写业务逻辑，交易指令用来修改资产，可以理解为 fabric 网络对外提供的一个交互接口（智能合约）。
- Event是fabric提供的一个事件框架，比如链代码事件，拒绝事件，注册事件等，在编写代码的时候可以订阅这些事件来实现自己的业务逻辑。
o-service用来实现共识。
交易流程
交易过程如下图所示：
- Application向一个或多个peer节点发送对交易的背书请求。
- Peer的endorse执行背书，但并不将结果提交到本地账本，只是将结果返回给应用。
- 应用收集所有背书节点的结果后，将结果广播给orderers，orderers执行共识，生成block，通过消息通道批量的将block发布给peer节点，更新lerdger。
可以看一下下面这张图，一样的过程，更加突出了多个peer背书的过程。
在介绍一下在交易过程中扮演重要角色的channel
channel是构建在Fabric网络上的私有区块链，实现了数据的隔离和保密。channel是由特定的peer所共享的，并且交易方必须通过该通道的正确验证才能与账本进行交互。
如下图所示:
可以看到不同颜色的channel隔离了不同的peer之间的通信。
构建Fabric网络
Fabric提供了一个first-network的demo来学习整个流程。
first-network有两个组织，每个组织各有两个个peer节点，以及一个排序服务。两个peer节点无法达成共识，三个peer节点无法容错，四个peer节点刚好完成演示。
Demo启动以后会自动完成一笔转账，并且打印出整个操作过程。
启动网络以后可以看到非常多的日志，这里我们只追踪关键步骤。
...
##########################################################
######### Generating Orderer Genesis block ##############
##########################################################
2018-02-05 15:13:08.760 CST [common/configtx/tool] main -> INFO 001 Loading configuration
2018-02-05 15:13:08.816 CST [common/configtx/tool] doOutputBlock -> INFO 002 Generating genesis block
2018-02-05 15:13:08.819 CST [common/configtx/tool] doOutputBlock -> INFO 003 Writing genesis block#################################################################
### Generating channel configuration transaction 'channel.tx' ###
#################################################################
2018-02-05 15:13:08.845 CST [common/configtx/tool] main -> INFO 001 Loading configuration
2018-02-05 15:13:08.849 CST [common/configtx/tool] doOutputChannelCreateTx -> INFO 002 Generating new channel configtx
2018-02-05 15:13:08.850 CST [common/configtx/tool] doOutputChannelCreateTx -> INFO 003 Writing new channel tx#################################################################
####### Generating anchor peer update for Org1MSP ##########
#################################################################
2018-02-05 15:13:08.876 CST [common/configtx/tool] main -> INFO 001 Loading configuration
2018-02-05 15:13:08.880 CST [common/configtx/tool] doOutputAnchorPeersUpdate -> INFO 002 Generating anchor peer update
2018-02-05 15:13:08.881 CST [common/configtx/tool] doOutputAnchorPeersUpdate -> INFO 003 Writing anchor peer update
...可以看到，在转账之前首先进行了fabric网络的初始化过程，创建了创世区块，配置了channel和生成了membership（MSP）身份服务。
Channel name : mychannel
Creating channel...
CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt
CORE_PEER_TLS_KEY_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/server.key
CORE_PEER_LOCALMSPID=Org1MSP
CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
CORE_PEER_TLS_CERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/server.crt
CORE_PEER_TLS_ENABLED=true
CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
CORE_PEER_ID=cli
CORE_LOGGING_LEVEL=DEBUG
CORE_PEER_ADDRESS=peer0.org1.example.com:7051
2018-02-05 07:13:13.382 UTC [msp] GetLocalMSP -> DEBU 001 Returning existing local MSP
2018-02-05 07:13:13.382 UTC [msp] GetDefaultSigningIdentity -> DEBU 002 Obtaining default signing identity
2018-02-05 07:13:13.406 UTC [channelCmd] InitCmdFactory -> INFO 003 Endorser and orderer connections initialized
2018-02-05 07:13:13.409 UTC [msp] GetLocalMSP -> DEBU 004 Returning existing local MSP
dd接着可以看到在转账前首先创建了channel，其中包括了身份认证的ca文件，key以及通信的socket信息和MSP的信息。
Attempting to Query PEER0 ...3 secs2018-02-05 07:13:55.998 UTC [msp] GetLocalMSP -> DEBU 001 Returning existing local MSP
2018-02-05 07:13:55.998 UTC [msp] GetDefaultSigningIdentity -> DEBU 002 Obtaining default signing identity
2018-02-05 07:13:55.998 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 003 Using default escc
2018-02-05 07:13:55.998 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 004 Using default vscc
2018-02-05 07:13:55.999 UTC [msp/identity] Sign -> DEBU 005 Sign: plaintext: 0A95070A6708031A0C08B388E0D30510...6D7963631A0A0A0571756572790A0161
2018-02-05 07:13:55.999 UTC [msp/identity] Sign -> DEBU 006 Sign: digest: D6BB27BAC40E5A58ED3CF0AFB147280B60E305053D9B97A38461A398736ED7C7
Query Result: 100接着在很不起眼的地方看到了上面这些日志，差点看瞎我~重点来了~
在转账之前使用默认的ESCC（背书链码），VSCC（验证链码），以及自身的签名查询了Peer0得到余额是100。
2018-02-05 07:14:14.950 UTC [chaincodeCmd] chaincodeInvokeOrQuery -> DEBU 009 ESCC invoke result: version:1 response:<status:200 message:"OK" > payload:"n 3703165...,k363_(n212027" >
2018-02-05 07:14:14.952 UTC [chaincodeCmd] chaincodeInvokeOrQuery -> INFO 00a Chaincode invoke successful. result: status:200
2018-02-05 07:14:14.953 UTC [main] main -> INFO 00b Exiting.....
===================== Invoke transaction on PEER0 on channel 'mychannel' is successful =====================调用链码进行转账操作，发现两边的状态码都是200表示转账成功，其中payload是发送转账的一些具体信息。
Attempting to Query PEER3 ...3 secs2018-02-05 07:14:18.566 UTC [msp] GetLocalMSP -> DEBU 001 Returning existing local MSP
2018-02-05 07:14:18.566 UTC [msp] GetDefaultSigningIdentity -> DEBU 002 Obtaining default signing identity
2018-02-05 07:14:18.566 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 003 Using default escc
2018-02-05 07:14:18.566 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 004 Using default vscc
2018-02-05 07:14:18.567 UTC [msp/identity] Sign -> DEBU 005 Sign: plaintext: 0A95070A6708031A0C08CA88E0D30510...6D7963631A0A0A0571756572790A0161
2018-02-05 07:14:18.567 UTC [msp/identity] Sign -> DEBU 006 Sign: digest: 9E93A6D0549C627788C5074633DE28C9D08F36A4763EFF55479613B2DD32CADB
Query Result: 90
2018-02-05 07:14:37.014 UTC [main] main -> INFO 007 Exiting.....最后查询Peer3发现余额只有90了，这样就完成了一个最小区块链网络的交易示例。
