HyperLedger - 序列2 - Fabric 1.0 架构解析与Transaction处理全流程

从本篇开始，正式进入Fabric的序列。大家如果看过前面以太坊的序列文章，知道以太坊的架构，理解Fabric会很容易。

逻辑架构
下面这张图摘自网络(http://www.8btc.com/hyperledger-fabric1-0)，展示了HyperLedger的逻辑架构。图画的很好，我就不另外再画了。本文主要结合这些图，用通俗的语言，把Fabric 1.0的架构讲清楚。

竖着来看，3大块：
（1）最左边的，Memship，就是上1篇所讲的联盟链特有的：身份认证相关的内容。比如组织注册，公钥证书发放，交易签名，验证等等。。
（2）中间1块：区块链的基础东西，和比特币、以太坊类似，BlockChain、Transaction、Ledger(分布式账本）、P2P协议。。
（3）最右边1块：智能合约。在以太坊里面，称为Smart Contract，这里换了个名字，叫做ChainCode而已。本质还是同1个东西。

运行架构
下面这张图，展示了Fabric运行时的架构是什么样子(Fabric采用Go语言开发，通常运行在Docker容器里面，每1个Node对应1个Docker容器）
（1）这里的application/SDK，并不是指我们通常的APP的客户端。而是整个Fabric网络的调用端，通常是我们的Web应用服务器。
（2）membership 服务，就是上图中的注册登记、身份认证。在这个地方，你可以认为是一个服务的集群。
（3）peer 就是区块链网络中说的物理上的node。peer呢，有2个角色（对应2个模块），1个叫Endorser，1个叫Commiter（这个后面会详细讲述）。
peer上面存的是Ledger(区块链 + WorldState)，存的智能合约ChainCode，然后peer之间、peer和客户端之间，用event通信。
（4）Order-Servce 排序服务。为了Consesus用的，后面会专门来讲述。

总结一下：Fabric相对以太坊，大部分其实很类似（比如peer，peer上面的账本、worldState）。多了2个东西出来，1个是membership（用于注册、身份认证），1个是order service，用于共识算法。

网络节点示意图
下面这张图，示意了整个Fabric运行过程中，网络的节点情况。

有3个组织Org1, Org2, Org3，各自有1堆的Peer（也就是Node），这些Peer呢，既是Endoser角色，又是Commiter角色，所有的Peer组成1个联盟链。通过Ordering Service，所有节点达成共识。
（注：这张图上省去了客户端、Membership服务）
，
网络运行全过程介绍 - Transaction的深入理解
知道了整个网络的运行架构，接下来看一下整个网络是怎么运作的。

2大流程：
流程1： 写ChainCode，编译，部署。 这个整个的过程，跟前面介绍的，以太坊的Solidity很类似，只是这里用的Go语言。
额外说1句，Fabric的智能合约的编写，比以太坊还简单！！！这得归功于Fabric良好的接口设计。

流程2：客户端注册，向整个网络发送请求。具体来说，
Step1: 你要加入这个网络，首先肯定要向Membership服务注册，给你发证书。也就是上图中的步骤0 Enroll

Step2: 注册完成，接下来就可以向网络发送交易了。

这里要特别强调一下，Transaction这个词在这里的意思。
我们知道，在比特币网络中，当我们说Transaction，特指买卖双方的转账；到了以太坊中，Transaction这个词有了扩展，不仅指交易，也可以用来部署、调用智能合约；

到了Fabric中，这里Transaction这个词就更加泛化了，其实就是指客户端的发生Request ！ 当然，指的是Write Requerst，会改变WorldState，会被加到区块链里面。说的再通俗点，就是请求的日志流水！！！！

对于只读的请求，Query Request，并不改变WorldState，你可以不写入到区块链里面去。当然，你也可以把它当做Transaction，按照Write Request的方式去处理，只是一般没有必要。

再次强调一遍，这里的Transaction，就是我们通常的客户端发出去的请求的日志流水！！！

日志流水 + 状态机的这个模型，我们在前面以太坊的序列中，讲解过；在另1个专门讲Paxos/Raft的分布式一致性算法里面，也讲过。

这个是计算机领域一个个非常非常常见的模型，明白了这个，就会发现Fabric其实很简单。

Transaction Flow – 一致性如何达到
知道了Transaction就是客户端发的请求，接下来就来看一下，请求进入Fabric的网络中，被怎么写入到所有Peer的。即如何保证所有Peer上面的数据一致性？？

下图展示了1个Transaction被处理的详细过程：
Step1: 客户端向其中1个Peer提交Transaction。注意，这里的Client是真正的客户端。而这里的submiting peer，你可以认为是fabric网络的客户端（对客户端来说，这个submiting peer是服务器）

Step2: submiting peer把请求给多个endoser模拟执行，然后从每个endoser收集返回结果。也就是图中的步骤 圆圈2,3。

在Fabric里面，把这个“模拟执行”的过程，称为“背书”，endoser。 至所以这么叫，是因为如果模拟执行不通过的话，这个Transaction就直接被拒绝了。模拟执行通过，才有机会进入下面的过程，才有机会被区块链网络接受。
所以，“背书”，通俗点讲，就是“告诉整个区块链网络，这个Transaction被我模拟执行过了，有效的，你们要不也试试看？”

这里有2个关键点：1.发给几个endoser取决于你的endose poclicy怎么配置的，你配置成只有1个endoser也可以。
2.注意这里只是“模拟执行”。endoser并不会把结果直接写到worldState里面。（模拟执行的结果是ReadWriteSet，这个后面单独来讲）

Step3: submiting peer 把这个Transaction + 模拟执行的结果（ReadWriteSet），发给Orderering Service。也就是图中的步骤 圆圈 4
关键点：因为有很多个Client往不同的submit peer发送请求，所以这个Ordering Service会收到1笔笔的Transaction。
Orderering Service呢，会对这些Transaction进行打包，形成Block。

Step4: Ordering Service再把这个Block广播给每个Peer(此时，Peer充当了另外1个角色，不是Endoser，而是Commiter)。所有Commiter接受到这个Block，真正写入：把交易加入区块链，同时更新WorldState，也就是分布式账本(Ledger)

Step5: 给Client发送Event，通知其交易已被执行。

依赖问题
（1）为什么按照上面的流程来处理Transaction，就可以保证所有Peer的数据是一致的呢？
换句话说：你所有的Peer都在接收Transaction，所有的Peer都在写入数据，网络又是有延迟的，如何保证所有Peer数据一致？？

这就是接下来要讨论的分布式一致性算法问题，这个也是分布式系统的1个典型问题。在Paxos/Raft序列里面，有过探讨。在接下来，会结合Fabric来再次深入讨论这个问题。

（2）写入的时候，多个Transaction改同1个状态（比如多个Transaction同时从同1个账号转钱出去），并发怎么控制？

相关链接：
《HyperLedger - 序列1 - 公有链 vs 联盟链》

有兴趣朋友也可以进一步关注公众号“架构之道与术”， 获取原文。 或扫描如下二维码：