超级账本架构分析

　　Fabric整体架构

　　Fabric为应用提供了gRPC API，以及封装API的SDK供应用调用。应用可以通过SDK访问Fabric网络中的多种资源，包括账本、交易、链码、事件、权限管理等。应用开发者只需要跟这些资源打交道即可，无需关心如何实现。其中，账本是最核心的结构，记录应用信息，应用则通过发起交易来向账本中记录数据。交易执行的逻辑通过链码来承载。整个网络运行中发生的事件可以被应用访问，以触发外部流程甚至其他系统。权限管理则负责整个过程中的访问控制。账本和交易进一步地依赖核心的区块链结构、数据库、共识机制等技术；链码则依赖容器、状态机等技术；权限管理利用了已有的PKI体系、数字证书、加解密算法等诸多安全技术。底层由多个节点组成P2P网络，通过gRPC通道进行交互，利用Gossip协议进行同步。

　　层次化结构提高了架构的可扩展和可插拔性，方便开发者以模块为单位进行开发。

　　超级账本Fabric根据交易过程中不同环节的功能，在逻辑上将节点角色解耦为Endorser和Committer，让不同类型节点可以关注处理不同类型的工作负载。典型的交易处理过程如下图所示。

　　示例交易处理过程

　　在整个交易过程中，各个组件的功能主要为：

　　客户端（App）：客户端应用使用SDK来跟Fabric网络打交道。首先，客户端从CA获取合法的身份证书来加入到网络内的应用通道。发起正式交易前，需要先构造交易提案（Proposal）提交给Endorser进行背书（通过EndorserClient提供的ProcessProposal（ctx context.Context， signedProp *pb.SignedProposal）（*pb.ProposalResponse，error）接口）；客户端收集到足够（背书策略决定）的背书支持后可以利用背书构造一个合法的交易请求，发给Orderer进行排序（通过BroadcastClient提供的Send（env *cb.Envelope）error接口）处理。客户端还可以通过事件机制来监听网络中消息，来获知交易是否被成功接收。命令行客户端的主要实现代码在peer/chaincode目录下。

　　Endorser节点：主要提供ProcessProposal（ctx context.Context，signedProp *pb.SignedProposal）（*pb.ProposalResponse，error）方法（代码在core/endorser/endorser.go文件）供客户端调用，完成对交易提案的背书（目前主要是签名）处理。收到来自客户端的交易提案后，首先进行合法性和ACL权限检查，检查通过则模拟运行交易，对交易导致的状态变化（以读写集形式记录，包括所读状态的键和版本，所写状态的键值）进行背书并返回结果给客户端。注意网络中可以只有部分节点担任Endorser角色。主要代码在core/endorser目录下;

　　Committer节点：负责维护区块链和账本结构（包括状态DB、历史DB、索引DB等）。该节点会定期地从Orderer获取排序后的批量交易区块结构，对这些交易进行落盘前的最终检查（包括交易消息结构、签名完整性、是否重复、读写集合版本是否匹配等）。检查通过后执行合法的交易，将结果写入账本，同时构造新的区块，更新区块中BlockMetadata［2］（TRANSACTIONS_FILTER）记录交易是否合法等信息。同一个物理节点可以仅作为Committer角色运行，也可以同时担任Endorser和Committer这两种角色。主要实现代码在core/committer目录下;

　　Orderer：仅负责排序。为网络中所有合法交易进行全局排序，并将一批排序后的交易组合生成区块结构。Orderer一般不需要跟账本和交易内容直接打交道。主要实现代码在orderer目录下。对外主要提供Broadcast（srv ab.AtomicBroadcast_BroadcastServer）error和Deliver（srv ab.AtomicBroadcast_DeliverServer）error两个RPC方法（代码在orderer/server.go文件）;

　　CA：负责网络中所有证书的管理（分发、撤销等），实现标准的PKI架构。主要代码在单独的fabric-ca项目中。CA在签发证书后，自身不参与到网络中的交易过程。