在刚接触fabric的时候一般都是直接跟着wiki的教程一步步安装配置，执行一系列命令，最终将其运行起来，但很多人对其中的运行流程及其基础知识点可能不是很了解。基于此今天我将以$FABRIC_ROOT/examples/e2e_cli/ 经典Demo为例来分享一些我的理解，希望可以对入门者有所帮助。
生成证书
fabric是有准入门槛的联盟链，通过MSP服务来进行对其中的成员进行统一管理。既然提到了MSP，那就肯定离不开证书这一概念。证书的作用一方面是用于验证消息的签名是否有效从而验证交易是否有效，另一方面可以用于确认该证书的拥有者身份。
所以要运行起整个fabric网络首先得生成证书，生成证书的配置文件在crypto-config.yaml中，根据自己的需求定义好OrdererOrgs和PeerOrgs信息，之后在generateArtifacts.sh脚本中执行generateCerts方法即可在当前目录下生成包含证书文件的crypto-config目录。
ordererOrganizations example.com ca # 包含给Orderer组织颁发MSP证书的ca的公私钥 msp # 包含Orderer组织的msp相关证书（admincerts，cacerts，tlscacerts） orderers orderer.example.com msp admincerts # 管理员证书 cacerts # 给Orderer组织颁发MSP证书的ca的证书 keystore # 当前Orderer组织的私钥 signcerts # 当前Orderer组织的证书（包含公钥） tlscacerts # 给Orderer组织颁发TLS证书的ca的证书 tls ca.crt # 给Orderer组织颁发TLS证书的ca的证书 server.crt # 当前Orderer组织的tls证书（包含公钥） server.key # 当前Orderer组织的tls私钥 tlsca # 包含给Orderer组织颁发TLS证书的ca的公私钥 users # 包含Orderer下普通用户和管理员用户的msp和tls证书以上是以Orderer组织为例说明了下生成的证书目录层级结构及其对应的目录或文件的含义，Peer组织的类似。
TLS（Transport Layer Security Protocol）是Https建立在SSL 3.0之上的一个标准的安全传输层协议。负责安全通信，安全传输数据包。需要做数字签名的认证才能正常的去继续做http的握手然后再做交互。
MSP（Membership Service Provider）是负责成员是否被认证过进入我们这个网络里的安全管理
生成genesis.block
证书生成好之后接下来就可以定义Orderer的配置以生成genesis.block了。该配置在configtx.yaml中的Profiles.TwoOrgsOrdererGenesis下。
TwoOrgsOrdererGenesis: Capabilities: <<: *ChannelCapabilities Orderer: <<: *OrdererDefaults Organizations: - *OrdererOrg Capabilities: <<: *OrdererCapabilities Consortiums: SampleConsortium: Organizations: - *Org1 - *Org2*OrdererDefaults：引用包含了Orderer的基本信息如下
- OrdererType（共识类型）是solo还是kafka。solo就是一个模拟kafka的本地的单机的文件系统实现的消息队列，缺点是在执行速度和效率上肯定不如kafka，测试环境一般就用solo，生产环境用kafka。kafka目前是通过消息队列保证所有的节点对transaction的时间有一个共识，并没有具体的像比特币之类的pow共识算法，以前的0.6版本有pbft算法，但1.0以后还没有实现。
- Addresses：Orderer服务的地址列表
- BatchTimeout：Orderer节点的出块时间
- BatchSize：区块大小包含最大交易笔数（MaxMessageCount），最大区块大小（AbsoluteMaxBytes）以及建议区块大小（PreferredMaxBytes）
- Kafka：包含brokers列表。当设置了OrdererType为kafka才生效，如果是solo则该配置不生效。
*OrdererOrg：引用包含了OrdererOrg的MSP信息
- Name：OrdererOrg
- ID：Orderer的MSPID
- MSPDir：Orderer组织的MSP目录（就是上面生成的msp目录）
*Org1 同OrdererOrg引用一样
*Org2 同OrdererOrg引用一样
综上，通过这些配置生成genesis.block之后，Orderer服务就会明确所使用的共识类型，服务地址列表，出块时间，出块大小。同时也就拥有了Orderer节点MSPID和MSP证书（包含Orderer的管理员证书，Orderer的CA证书，Orderer的TLS CA证书），以及联盟里面的所有Org（这里是Org1和Org2）的MSPID和MSP证书（包含Org的管理员证书，Org的CA证书，Org的TLS CA证书）,待整个fabric网络运行起来之后Orderer服务便可以利用这些CA证书很容易的验证节点传过来的证书是否有效。
生成通道配置交易
Orderer配置好之后，同样通过configtx.yaml中的Profiles.TwoOrgsChannel配置信息来生成一个通道配置类型的交易（ConfigUpdateEnvelope）。
TwoOrgsChannel: Consortium: SampleConsortium Application: <<: *ApplicationDefaults Organizations: - *Org1 - *Org2 Capabilities: <<: *ApplicationCapabilities启动网络
在e2e_cli这个Demo项目里面我们是通过Docker的方式来运行fabric网络的。正常我们的docker，比如在我们本地已经build出了很多docker image，比如我们有hyperledger/fabric-peer，如果想让docker image运行起来，一般都是通过docker run这样的命令，比如我单独去run一个peer，docker run + 这个docker image的名字，然后加一些参数就启动了一个docker container，docker container运行了这个docker image的环境。如果有多个image，我们手动的一个个去启动太麻烦了，我们想有一个配置文件，能让批量的很多很多的节点一起启动，那这个功能就引出了docker-compose。简单说，docker-compose就是把多个docker image启动的定义和配置组合在一起放在一个文件里一起启动起来。
# 启动fabric网络所需要的所有Docker Container并在后台挂起 docker-compose -f docker-compose-cli.yaml up -d # 进入container_name为 orderer.example.com 的Docker Container docker exec -it orderer.example.com bash
