一、系统架构
fabric系统架构由 应用程序层 和 底层区块链层构成。
fabric为应用程序提供了 grpc接口，针对不同语言封装了不同的sdk（go、nodejs、Java）
应用程序与底层交互的媒介有4个 身份、账本、交易和智能合约
- 1.身份服务
由fabric的成员服务提供，用pka体系和ca系统提供注册登录及身份认证功能，这里的册登录不是账号密码那种，也不需要在区块链上为每一个应用程序建立一个身份，有点像数据库的身份管理，这个身份是应用程序用来与fabric网络进行交互的。fabric里的一个身份有多个证书， 有用户证书、交易证书、tls证书（用户加密传输）这些证书都在crypto-config文件夹下可以看到。 - 2.账本管理
实际上是对区块的管理，有两种查询方法 按区块高度 或 按区块哈希查询，账本会根据通道进行隔离，包括物理上分文件夹存储。
注：可以用交易id查询区块不太好理解。 - 3.交易
应用程序提交交易到背书节点进行背书（有点担保的意思）然后给排序节点进行排序并打包成区块之后分发 - 4.智能合约
相当于函数定义，交易则是函数调用。
cap原理一致性、可用性、分区容忍性、farbic为了提高可用性和分区容忍性降低了一致性，fabric为了满足一致性提出了共识机制。
fabric的共识 应用程序向背书节点提出交易请求，背书节点进行交易模拟确认交易并背书然后把背书结果和签名返回给应用程序，应用程序再将背书后的交易发送给排序节点进行排序并生成区块向全网的记账节点进行广播，记账节点会对交易进行再次确认，认证后再存入本地账本。
fabric网络里有两种通信方式 排序节点与每个组织的锚节点用grpc 组织的锚节点与其他节点之间用gossip协议完成交易广播.
链码服务 通过容器实现，不是很理想，环境所占的空间比较大。
国内的应用程序必须要采用国密。椭圆曲线和SHA256都不被认可。
二、fabric中的节点：
-
1.客户端节点 cli
介于应用程序和底层之间并不能算是底层节点，运行时需要与orderer、peer节点建立连接才可以发挥作用 例：连接到orderer节点进行通道创建，与peer节点连接进行交易模拟等 -
2.peer节点 peer
包括anchor节点、endorser节点、 committer节点
anchor节点一个组织只有一个anchor节点（锚节点，一个组织内唯一的一个与orderer节点进行通信的节点，初始化组织的时候进行指定，系统运行中锚节点挂掉之后会自动选出一个新的锚节点与orderer连接）
endorser节点（背书节点，担保节点，每个智能合约安装时都会设置背书策略即由哪些节点担保后这笔交易才有效，只有背书节点才会运行智能合约）
committer节点 （记账节点，最基本的peer节点从某种意义来说每个节点都有记账功能都是committer节点，如果一个节点既不是锚节点也不是背书节点那么他就是普通的记账节点）验证从orderer节点收到的区块及交易的有效性，验证过后记录到本地的账本中，如果交易有效还会同时更改区块链的状态数据。这三种节点并不冲突。 -
3.orderer节点 orderer
排序节点，从全网的客户端节点接受交易，将交易排序，按固定时间间隔将排序好的交易打包成区块分发给其他组织的主节点 目前有两种排序方式 solo单机只有一个排序节点只适用于测试 Kafka集群排序 -
4.ca节点 ca
证书颁发机构，主要用于建立一个区块链的身份，判断一个身份是否是有效合法的，只有ca认可的机构才能够在区块链上进行交易 ca节点可以选择。
三、fabric的网络拓扑结构
-
1.客户端节点（基于区块链的应用程序）向ca机构（可以是官方的也可能是非官方的）表明身份获得证书用于后续的操作
-
2.客户端可以向不同组织的背书节点发送交易提案，获得背书后在向orderer节点提交交易
-
3.orderer节点向上提交给Kafka集群，由orderer和kafka集群完成排序后orderer向每个组织的锚节点广播。
-
4.锚节点再在组织内通过gossip协议扩散区块消息。
这里存在一个树形结构：
Kafka->orderer->anchor(锚节点）->所有的peer节点
树形结构的好处：假如每个组织对应一个企业那么内部数据可以只在组织内部传播，对外只需要暴露出一个anchor锚节点即可，保证了数据的安全性。
注：每个组织都有一个ca的根证书，网络中的ca节点的根证书要被其他组织所认可
四、fabric网络中的交易流程
（文中序号与图中标号不对应）
-
1.应用程序在本地构造交易提案并向背书节点发送交易提案（这里背书节点是智能合约中的背书策略规定的，例如，智能合约的背书策略要求至少两个背书节点背书那么客户端就需要把交易提案发送到至少两个背书节点，如果没有获得结果就继续发送，否则交易无效，这里面的背书节点的顺序没有要求）
-
2.背书节点模拟执行交易提案并签名，背书节点收到交易提案后会进行检查工作如格式、是否已经提交过、签名及发送节点是否有权限等，验证通过后背书节点会把交易发送给智能合约隔离执行，执行完后背书节点对结果签名（背书）并返回给应用程序，这里只是模拟执行，不会产生持久化操作。
-
3.应用程序（客户端节点）收到返回的结果，首先对结果进行验证主要是签名，验证通过后，如果是查询交易，返回结果就是需要的内容，如果是写交易应用程序需要收到足够多的背书结果（智能合约的背书策略规定的），然后把交易提案、背书结果和自己的签名（称为交易），把交易发送给排序节点orderer进行排序。
-
4.排序节点收到交易对交易排序，排序节点收到交易后首先验证背书结果是否一致，如果不一致排序节点也发现不了（之后会有检测），依然会按照交易提交的顺序对交易排序然后打包发送给各个组织的主节点anchor
-
5.主节点验证、保存区块，主节点收到区块后会首先验证区块里的每笔交易是否有效，无效交易会标记为无效交易（当前版本里不会删除，依然会保存到账本里但不会更新状态数据库）
-
6.主节点在组织内通过gossip协议向各个peer节点同步区块，每个peer节点都会像主节点一样验证区块里的每笔交易是否有效并更新状态数据库
五、fabric中的共识
（这里只是简单介绍共识）
所谓共识：一般指三个过程
交易背书（模拟 与endorser（背书节点）节点相关）
交易排序（排序 与orderer（排序节点）相关）
交易验证（验证 与committer（记账节点）相关）
这里面共识主要指交易排序
orderer节点功能 交易排序、 区块分发、 通道隔离
- 1.交易排序：保证系统交易顺序的一致性，现阶段有两种solo和kafka
- 2.区块分发：排序节点排完序后会把交易打包成区块，这个区块是中间区块（包括所有收到的交易）各个peer节点收到区块后还要对区块里的每笔交易进行验证，验证完后会把无效交易标出来
- 3.通道隔离：交易按通道进行排序，在客户端提交交易时会标出交易要发往的通道，orderer节点收到交易后会根据这个通道对交易分别进行排序，然后发往通道中各个组织的的锚节点。一个组织的各节点可以订阅多个通道，通道与通道之间是隔离的，彼此之间不知道对方的存在。