一、架构图
1、应用层
- API：提供GRPC，RPC框架
- SDK：在API基础上封装的SDK，go、java、python、nodejs
- 事件：分布式系统中，达成共识需要一定的时间，fabric使用异步通信模式开发，触发回调函数执行
- 身份：依托于底层的成员服务，是联盟链的认证功能，例如CA
- 账本：区块链的查询数据，是账本中查出来的，区块高度+交易ID，不重复
- 交易：对区块链数据进行修改，先提交交易到背书节点，签名认证之后再执行
- 智能合约：做合约的安装、实例化和升级
2、区块链底层
- 成员服务：提供证书，用于加密和签名
- 共识服务：CAP（不能全满足，只能满足两个，一致性、可用性和分区容忍性），实际上区块链弱化了一致性，所以需要共识算法保证一致性，fabric的共识大概分为3个阶段
- 首先客户端向背书节点发送一个背书提案，背书节点进行交易模拟，将背书结果和签名返回客户端
- 客户端将背书后的交易交给排序节点进行排序，由排序节点生成区块，向全网广播，网络节点收到广播后，先验证区块交易的正确性
- 验证通过后，存入本地账本
- PS：排序节点与组织的锚节点使用的是GRPC通信，组织内使用的是gossip协议通信；
- 排序服务：顺序一样就认为状态是一样的，达成一个分布式一致性
- 链码服务：提供安全的、可隔离的交易环境，所以fabric使用docker，链码直接与docker通信，目前阶段对k8s支持的不好，会出问题
- 安全及密码服务：fabric定义了一个BCCSP接口，定义签名、加密解密等功能，默认实现了一套国际通用的密码服务，如sha256等
二、网络拓扑图
1、概念
- 客户端节点：应用程序和底层的交互媒介，与上层和peer和orderer连接发挥作用，连接peer做交易模拟
- peer节点：
- 锚节点（主节点），在一个组织内可以有多个peer，一个组织中锚节点只有一个，锚节点的作用是与orderer进行通信，锚节点需要HA支持，若锚节点挂了，组织内会选举新的节点与orderer进行通信
- 背书节点（endorse）理解为担保，与智能合约绑定，每一个智能合约安装到区块链中，会有一个专属的背书策略，适应企业复杂的业务需求
- 记账节点（committer）所有的peer结点都是记账节点，用于验证从orderer接收到的区块，验证交易的有效性，验证通过后，同步到本地账本
- orderer节点：排序节点，接受全网客户端节点的交易信息，按照一定规则进行排序，将排序好的交易，按照固定的时间间隔打包成区块，与其他组织的主节点进行通信，排序可以用solo（整个网络中只有一个排序节点，适用于开发和测试）和kafka（生产环境下使用，分布式消息队列）模式
- CA节点：可选的，作用：颁发证书，只有被CA认证的节点才能进行交易，因此，fabric不存在51%攻击问题。
2、动作和行为
- 注册登记：由客户端发起，向CA机构表明自己的身份，获取证书，上图中是第三方的CA，也可以使用官方提供的CA
- 交易提案：向组织的背书节点提交请求，背书节点实际上就是peer节点，组织是独立的，可以理解为现实中的商业主体（京东、淘宝）；组织的数据来源有两个（客户端来的数据用来做模拟，排序节点来的数据用来执行）
- 提交交易：客户端节点向排序节点发请求，orderer内部进行排序打包成区块，广播给其他组织的锚节点，上图是基于kafka实现的，每个组织会选择一个orderer节点进行通信
三、交易流程图
客户端提交交易，最终到记账节点同步数据
- 智能合约安装要指定背书节点，正常情况下，背书节点返回相同的结果，但签名是不一样的
- 背书节点是模拟的过程，不会持久化
- 1，2，3步是交易模拟；4，5步是交易排序；6，7，8，9是交易同步和记账，交易模拟对应智能合约，交易排序对应共识机制，同步和记账对应账本存储