超级账本节点类型

节点示意图

1 客户端节点

      客户端或应用程序代表由最终用户操作的实体，它必须连接到某一个Peer节点或者排序服务节点上与区块链网络进行通信。客户端向背书节点（Endorser

Peer）提交交易提案(Proposal)，当收集到足够背书后，向排序服务节点广播交易，进行排序，生成区块。

2 CA节点

      CA节点是fabric的证书颁发节点(Certificate Authority)，由服务器(fabric-ca-server)和客户端(fabric-ca-client)组成。

      CA节点接收客户端的注册申请，返回注册密码用于登录，以便获取身份证书。在区块链网络上所有的操作都会验证用户的身份。

      CA节点是可选的，也可以用其他成熟的第三方CA颁发证书。

3 Peer节点

      从上图中可以看出每个组织可以拥有一到多个Peer节点。每个Peer节点可以担任如下多种角色：

Endorser Peer（背书结点）

Leader Peer（主节点）

Committer Peer（记账节点）

Anchor Peer（锚节点）

注：每个Peer节点必定是一个记账节点，除记账节点外，它也可以担任其它一到多种角色，即某个节点可以同时是记账节点和背书节点，也可以同时是记账节点、背书节点、主节点，锚节点。

3.1 Endorser Peer（背书结点）

      部分节点会执行交易并对结果进行签名背书，充当背书节点的角色。

      所谓背书(Endorsement)，就是指特定peer执行交易并向生成交易提案( proposal )的客户端应用程序返回YES/NO响应的过程。

      背书节点是动态的角色，是与具体链码绑定的。每个链码在实例化的时候都会设置背书策略(Endorsement policy)，指定哪些节点对交易背书才有效。

      也只有在应用程序向节点发起交易背书请求时才成为背书节点，其他时候是普通的记账节点，只负责验证交易并记账。

在实例化链码时指定的：

peer chaincode instantiate -o

orderer.example.com:7050 -C mychannel -n mychannel -c '{"Args":["init","A","10","B","10"]}' -P "OR ('Org1MSP.member')"-v 1.0

-P注明了只有Org1的成员才可以进行背书

3.2 Leader Peer（主节点）

      从图中可以看出，主节点负责和Orderer排序服务节点通信，从排序服务节点处获取最新的区块并在组织内部同步。可以强制设置，也可以选举产生。

配置路径：

/opt/gopath/src/github.com/hyperledger/fabric/aberic/docker-peer.yaml

3.3 Committer Peer（记账节点）

      负责验证从排序服务节点接收的区块里的交易，然后将块提交（写入/追加）到其通道账本的副本。记账节点还将每个块中的每个交易标记为有效或无效。

3.4 Anchor Peer（锚节点）

      在一个通道(

channel )上可以被所有其他peer发现的peer，通道上的每个成员都有一个Anchor Peer(或多个Anchor peer 来防止单点故障)，允许属于不同成员的peer发现通道上的所有现有peer。

配置路径：

/opt/gopath/src/github.com/hyperledger/fabric/aberic/configtx.yaml

src/test/fixture/sdkintegration/e2e-2Orgs/configtx.yaml

4 Orderer（排序服务节点）

     排序服务节点接收包含背书签名的交易，对未打包的交易进行排序生成区块，广播给Peer节点。

     排序服务提供的是原子广播，保证同一个链上的节点为接收到机同的消息，并且有相同的逻辑顺序。

     排序服务独立于peer进程存在并且以先来先服务的方式对网络上的所有信道进行排序交易。排序服务旨在支持超出现有的SOLO和Kafka品种的可插拔实现。排序服务是整个网络的公共绑定; 它包含绑定到每个成员的加密身份材料。

5 总结

     Fabric系统是通过组织来划分的，每个组织内都包含承担不同功能的Peer 节点，每个Peer节点又可以担任多种角色。所有的组织共用一个统一的Orderer集群。因此在设计基于Hyperledger Fabric的系统时需要考虑组织之间的业务关系，以及内部每个模块之间的联系，以此来进行统一的规划。