一、架构
fabric可以从逻辑架构和系统架构两种层面上来解析，先看一下二者的结构图：
1、逻辑架构图：
从逻辑架构构图上来理解Fabric的整体的逻辑，联盟链和公链的不同之处在于，其逻辑结构有着完全的不同。比如看上面的逻辑结构，就会发现，较之于常见的公链体系，它要复杂的多。在普通的公链逻辑体系中，可以认为只有一个节点，既当爹又当妈，反正该操心的事儿他一个人都干了。可是在联盟链，特别是Fabric中，由于许可的存在，导致链本身的节点功能发生了本质的改变。
在联盟链上，节点仍然是那个节点（Peer），但是根据其实现的功能不同，可以分为CA节点，TLS节点，背书结点，提交节点，存储节点（记帐节点），排序节点，Leader节点，锚节点。这些节点，在一起共同组成了基础的逻辑节点。在向上走，又抽象出组织，排序，CA集群和存储这些概念。
这些逻辑节点，和普通的Peer节点有的是完全一致的，有的是多重兼有的，比如Leader节点，它也是提交节点。他本身也是存储节点，如果设置为锚节点的话它又是锚节点。下面说明一下这些概念：
CA节点：这个好理解，可以简单理解成证书管理的节点。
TLS节点：这个和上面相似，控制TLS访问的相关证书节点。
背书结点：首先得明白背书和背书策略，背书可以简单理解成对执行某种操作前的一个验和签的过程。而背书策略指如何对操作进行背书即达到成功的规则。
这样就明白了背书节点，它就是执行背书过程能实现背书策略的节点。
提交节点：组织中每一个对等节点都是提交结点。
存储节点：存储数据的节点，包括存储帐本或者相关的状态数据的节点。
排序节点：负责对交易排序出块的节点。
Leader节点：为了减少对等节点传播的复杂性，排序节点只把交易出块后的信息发给指定的Leader节点，由他来向同组织的其它对等节点发送。可以动态选举或者静态指定。
锚节点：在跨组织的过程中，可以在配置文件中指定某个节点跨组织通信，这个是可选的。
逻辑上，Fabric通过组织来划分不同的逻辑域，那么有没有具体的规则来划分组织呢？目前没有，组织的划分更倾向于实际的应用和设计者的个人倾向。一般来说可以参考以下几点：是否为区块链数据应用的主要部分；规模大小（原则上要有一定的规模性，太大和太小都无法呼应组织本身的划分逻辑）。是否控制区块链业务的核心部分。
组织的管理可以是集中式的，由单一某个逻辑节点来完成，也可以是联盟式的，即通过选举来实现。组织的外面表现可以是一个公司，一个团体或者政府机构。当然，从业务管理的角度也可以划分成，链的运营管理方和链的业务应用方。
通道（Channel），主要用于实现链上的业务的隔离；一业务一通道，一通道一帐本，在同一个通道中，每个Peer都是一个对等体（这个概念在Fabric中出现比较多），这也和其它公链类似，即每个对等体内存储着相同的数据。显然，这会造成一定的数据浪费，所以在Fabric中提供了Couchdb来实现分布式的数据存储，减少数据存储的成本。
组织和通道有什么关系呢？组织更倾向于在上层的逻辑上的划分，强调的是宽泛的宏观的管理。通道则是具体的业务的把控者，到底谁可以加入通道（业务），由它来确定。组织是原则，通道是手段。通道通过MSP来确定参与方的合法性。
一个Fabric网络包含一个或多个组织且含有不少于一台排序服务集，一个组织包含一个或多个节点服务，一个节点服务可以加入一个或多个通道，一个通道可以安装一个或多个智能合约。
在设计时，要根据实际情况和运维的安全性简便性进行仔细划分。
2、系统架构图：
在Fabric中，由上图可以看到，从宏观角度，其划分的主要的模块和层次。而在实际的工程中，其也分为五大模块，逻辑上和此图相应，即：
cryptogen:生成组织结构和帐号相关，对应着密码部分。
configtxgen:创世块等初始文件和通道初始文件，对应容器、共识等。
configtxlator:二进制文件和JSON的转换，对应着帐本、交易等。
orderer:排序服务，对应着图中的共识、区块等。
peer:一个整体上的逻辑概念，对应着帐本数据、链码、容器、MSP、接口等。
也就是说，逻辑上的概念和具体的模块的对应，还是应该清晰的了解，这样才能在后面的代码分析中，不乱了自己的阵脚。其实在代码分析中，重点还是倾向于对流程中产生的代码进行分析，也就是说对Orderer和Peer的内容进行了重点分析，而对其它几个，遇到相关部分则分析一下。
二、流程
整体的流程图如下：
在Fabric中，一个基本的交易流程，其实就代表了整体的流程的大部分。所以从一个交易入手来分析区块链（不管是公链还是联盟链），其实是最好的一种办法。从这个角度看整个链，会有一个相当清晰的脉络把握。
在上面的图中，一个交易，基本上从客户端（SDK或APP）发起，然后根据背书策略发送交易提案到相关的背书节点，背书节点拿到提案后，验证签名，模拟执行，创建读写集，签名然后返回结果给客户端，客户端依次收集背书策略中要求发送至节点的返回结果，如果符合背书策略后，利用SDK打包交易（验证策略，打包提案、提案反馈和背书签名），然后发送到排序节点。排序服务器根据不同的通道按时间顺序排序，生成区块（RAFT共识就在此处），注意，此处不进行区块交易合法性验证。广播区块到各个组织的Leader节点，其它验证区块后广播给相关组织的通道成员，并且每个成员都要进行相同的校验处理。
所有合法的区块交易都会将写入状态写入数据库（状态数据库和帐本数据库）并更新世界状态。
三、总结
架构和流程分析完成，下来就正式开始分析整个源码的流程和相关模块的具体的应用。一如既往，从整体的流程代码走通后，会重点分析用到的相关的模块和接口。在分析完成这些模块后，会对重点部分如共识、密码学等再分别进行分析。由上而下，提纲挈领，渐渐深入。
