6.2.1 架构演进
Fabric架构经历了0.6版本到1.0版本的演进，架构上进行了重大改进，从0.6版本的结构简单演进到可扩展、多通道的设计，在架构上有了质的飞跃；从1.0版本以后，架构未做重大调整，到目前为止，最新发布为1.2版本。
视频教程：https://study.163.com/course/introduction/1210196297.htm
Fabric 0.6版本架构主要是应用、成员管理和Peer的三角形关系，业务逻辑全部集中在Peer节点上，结构过于简单，只能用于一些商业场景的验证。
Fabric 1.0版本在0.6版本的基础上做了重大改进和重构，把承载过多业务的Peer节点进行拆分，将区块链的数据维护和共识服务器进行分离，共识服务从Peer节点中完全分离出来，独立为Orderer节点专门提供共识服务；membership从架构中分离出来形成Fabric-ca单独组件；在架构中加入了多通道（channel）结构，实现更为灵活的业务适应性，支持更强的配置功能和策略管理功能，进一步增强系统的灵活性和适应性。
图：架构演进
6.2.2 总体架构
总体架构核心部分由成员管理（Membership services）、共识服务（Consensus services）和智能合约（Chain-code Services）三部分, 加上安全和加密服务（Security and Crypto Services）贯穿于其他各个组件，应用端通过接口（APIs、Events、SDKs）调用身份（IDENTITY）、账本（LEDGER）、交易（TRANSACTIONS）、智能合约等信息,架构图如下：
图：整体架构
- 成员管理（Membership services）：提供成员服务功能，包括注册、登记、申请证书等功能；考虑到商业应用对安全、隐私、监管、审计和性能的要求，节点、成员只有获得证书才能加入到区块链网络中，在1.0版本以后单独由可插拔的Fabric CA组件来处理。
- 共识服务（Consensus services）：负责分布式账本的计算和存储（Distrbuted Ledger）、节点间的共识服务（Ordering Service）、背书验证管理（Endorsement Validation）以及节点间的网络传输协议（Network Protocol）功能的实现，是区块链的核⼼心组成部分，为区块链的主体功能提供了底层支撑。
- 智能合约（Chain-code Services）：智能合约（SMART CONTRACT）称为链码（chaincode）, 是基于标准的一段代码，实现具体业务逻辑。链码和底层账本是解偶的，链码的更新不影响到原有的数据。链码目前可以使用GO、Java、Node.js语言来编写，通过Docker容器来运行chaincode，安装和实例化后通过gRPC与同一通道内的Peer节点进行连接。
- 安全和加密服务（Security and Crypto Services）：节点或成员必须被许可才能进入网络，通过证书、加密和签名等手段保证安全，通过多通道隔离功能，保证只有参与交易的节点能访问到数据，其他的节点看不到，真正实现了逻辑与数据的分离。
- 接口（APIs, Events, SDKs）：提供API方式给第三方应用调用，方便二次开发，目前已提供Node.js和Java SDK两种语言接口；可以通过SDK或CLI方式进行安装、测试链码，还可以查询交易状态和数据等功能，同时通过Events监听区块链网络中发现的事件，方便第三应用系统调用和处理。
HyperLedger Fabric 1.4 交易流程（6.3）
区块链最主要的特性之一是去中心化，没有了中心机构的集中处理，为了达成数据的一致性，就需要网络中全民参与管理，并以某种方法达成共识，所以区块链的交易流程也就是共识的过程。
视频教程：https://study.163.com/course/introduction/1210196297.htm
在Fabric中，本由一个节点处理的过程，在逻辑上被分解为不同的角色，每个角色承担不同的功能；节点（Peer）分解为背书节点（Endorser peer）和提交节点（Committer peer），为了达到处理的顺序性，提炼出排序（Orderer）角色。
Fabric是应用于联盟链的场景，在处理每一笔交易时，每个环节上需要对交易信息进行权限校验。
Fabric交易流程图如下所示：
图：Fabric交易流程
交易过程详细流程：
1) 应用程序客户端通过SDK调用证书服务（CA）服务，进行注册和登记，并获取身份证书；
2) 应用程序客户端通过SDK向区块链网络发起一个交易提案（Proposal），交易提案把带有本次交易要调用的合约标识、合约方法和参数信息以及客户端签名等信息发送给背书（Endorser）节点。
3) 背书（Endorser）节点收到交易提案（Proposal）后，验证签名并确定提交者是否有权执行操作，同时根据背书策略模拟执行智能合约，并将结果及其各自的CA证书签名发还给应用程序客户端。
4) 应用程序客户端收到背书（Endorser）节点返回的信息后，判断提案结果是否一致，以及是否参照指定的背书策略执行，如果没有足够的背书，则中止处理；否则，应用程序客户端把数据打包到一起组成一个交易并签名，发送给Orderers。
5) Orderers对接收到的交易进行共识排序，然后按照区块生成策略，将一批交易打包到一起，生成新的区块，发送给提交（Committer）节点；
6) 提交（Committer）节点收到区块后，会对区块中的每笔交易进行校验，检查交易依赖的输入输出是否符合当前区块链的状态，完成后将区块追加到本地的区块链，并修改世界状态。