欢迎阅读第 3 篇文章,这是揭秘 Hyperledger Fabric系列的最后一篇文章。 在第一篇文章中,已经解释了 Hyperledger Fabric 的底层架构。 第 2 篇文章描述了称为私有数据集合的 Fabric 的重要特性之一。
我想用这篇文章来讨论 Hyperledger Fabric 中的一些辅助补充服务,包括以下主题:网络流量处理(Network Traffic Handling)、服务发现(Service Discovery)和运营服务(Operations Service)。
本文目录:
- 网络流量处理(Network Traffic Handling)
- 服务发现(Service Discovery)
- 运营服务(Operations Service)
- 运营指标:基于 Prometheus 的拉取模型
- 运营指标:基于 StatsD 的推送模型
- 总结
网络流量处理(Network Traffic Handling)
由于多个参与组织加入通道,网络流量堵塞可能是 Fabric 通道上最潜在的问题之一。此外,每个组织可以拥有多个节点。让我们想象一下,如果参与组织和相关节点的数量随着时间的推移而增加,则 排序节点(Orderer)将因将交易块分发给每个通道上的每个节点的任务而负担过重。因此,排序节点(Orderer)容易出现单点故障。
为了向排序节点(Orderer) 提供崩溃容错 (Crash Fault Tolerance, CFT),Hyperledger Fabric 目前支持 CFT 排序服务的两种实现,即 Kafka 和 Raft。此外,几种类型的拜占庭容错(Byzantine Fault Tolerant,BFT)排序服务也在开发中。请参阅此链接了解更多信息。
除了减轻(Orderer) 的区块分配开销之外,还向所有参与组织引入了领先节点(Leading Peers)。每个组织都可以选择性地授权哪些节点成为领先节点。如下图 1 所示,Org1 的#2节点和 Org2 的@#2节点被指定为领先节点。
![](https://code84.com/wp-content/uploads/2022/08/v2-b2d4f5a54698ae71022967965753a28a_b.jpg)
图 1 描述了使用领先节点的 Fabric 区块传播方案的工作流程:
- 客户端向选定的背书节点发送交易提议。
- 每个背书节点生成一个交易响应并将已背书的响应发送回客户端。
- 客户端将附有背书响应的交易提交给排序节点(Orderer)。
- 排序节点(Orderer)创建一个有序交易区块,然后将创建的区块分发给与组织关联的每个 领先节点。
- 每个领先节点通过八卦数据传播协议(gossip data dissemination protocol)将接收到的区块传播给属于同一组织的其他节点。
前面讨论的 Fabric 区块传播方案可以显著减少排序节点(Orderer)的开销。因此,这个方案对于 Hyperledger Fabric 是必要的。每个组织都可以静态定义哪些节点成为领先节点。但是,如果没有静态指定节点,Fabric 系统还具有自动运行的动态领先节点选择算法。
服务发现(Service Discovery)
为了调用交易来更改账本的状态,客户端应用程序(client application)必须知道背书交易提议所需的一组背书节点。在 Fabric 1.2 版之前,此信息被静态编码到特定通道的 Fabric 系统链码中。
但是,这种静态配置不能适应网络变化。例如,当新组织加入频道或更改链码背书策略时。此外,静态配置也是不灵活的,以防有背书节点暂时离线。
在 Fabric 1.2 版中,引入了发现服务(discovery service)以方便客户端应用程序发现成员和背书配置、所有活动节点以及其他可用服务。请参阅此链接以了解发现服务的功能。发现服务在 Fabric SDK 方面提供 API 接口,供客户端向属于同一组织的节点查询所需的信息(例如,列出通道上的所有活动节点)。反过来,被查询的节点动态计算所需的信息并将可消费信息返回给客户端。
![](https://code84.com/wp-content/uploads/2022/08/v2-b8316058a1e0312ca6da80b21cc5b213_b.jpg)
为了使发现服务(discovery service)有效工作,必须为每个组织配置称为锚点节点(Anchor Peer) 的特殊类型 Fabric节点。 锚点节点的主要作用之一是节点发现。更具体地说,所有节点都可以查询属于同一组织的锚点节点,以动态发现通道上属于其他组织的所有其他节点。为了防止单点故障,一个组织可以有多个锚点节点。如图 2 所示,Org1 的节点#2和 Org2 的节点#2被配置为锚点节点。
图 2 说明了在锚点节点支持下的节点发现的工作流程:
- 普通节点通过八卦协议(gossip protocol)定期与属于同一组织的锚点节点保持同步。
- Org1 的锚点节点使用八卦协议定期将 Org1 的活动节点列表更新为 Org2 的锚点节点。
- Org2 的锚点节点还通过八卦协议定期将 Org2 的活动节点列表更新为 Org1 的锚点节点。
- 一旦客户端需要知道通道上所有活动节点的列表,客户端会使用 Fabric SDK 发出查询请求,并将请求发送到属于同一组织的节点之一。
- 查询节点向客户端响应所有活动节点的列表。
运营服务(Operations Service)
在 1.4 版本的发布中,Hyperledger Fabric 主要着眼于完善其稳定性和生产运营。运营服务是主要更新之一。运营服务可以帮助系统运营商确定排序节点(Orderer)、节点(Peers)和Fabric CA 的活跃度和健康状况。这项服务还可以帮助运营商更好地了解 Fabric 系统如何随着时间的推移而执行。
每个节点(包括 Orderer 节点、节点(Peers) 和 Fabric CA)通过向系统操作员公开 HTTP RESTful API 来提供操作服务。为了限制对任何敏感信息的访问,该 API 与 Fabric 区块链服务隔离,该 API 旨在仅用于操作员操作和监控 Fabric 系统组件的健康状况。
API 公开了以下功能:
在本节中,我想重点关注运营指标。 Hyperledger Fabric 提供了两种模型来暴露运营指标,即基于 Prometheus 的拉模型和基于 StatsD 的推模型。
运营指标:基于 Prometheus 的拉取模型
我们可以设置 Prometheus,通过连接到检测目标节点公开的 /metrics API 端点(endpoint),定期从节点(包括 排序节点(Orderer)、节点(Peers)和 Fabric CA)抓取运营指标。 Prometheus 通常配备 WebUI 用于指标可视化以及警报和通知服务。
要使 Fabric 节点支持 Prometheus,请查看此文档。 以下是 Prometheus 当前导出以供使用的指标列表。
![](https://code84.com/wp-content/uploads/2022/08/v2-99c3fef2b0ea09675e5f76153240e03b_b.jpg)
图 3 描述了利用 Prometheus 从不同类型的节点提取运营指标的工作流程:
- Prometheus 会定期发出拉取请求以将指标抓取到 Fabric 目标节点。
- 每个 Fabric 目标节点都会向 Prometheus 响应其相关指标。
- 系统操作员通过 Prometheus 的 WebUI 监控聚合指标。
- Prometheus 根据操作员设置的条件向系统操作员发送警报和通知。
运营指标:基于 StatsD 的推送模型
除了利用 Prometheus 作为拉取运营指标的引擎,Hyperledger Fabric 还支持基于 StatsD 的推送模型。 我们可以配置 Fabric 节点(包括 排序节点(Orderer)、节点(Peers)和 Fabric CA)来定期向 StatsD 守护程序提交运营指标。 然后可以将 StatsD 聚合的指标推送到一个或多个可插拔后端服务,例如 Graphite,用于指标可视化和警报。
要配置 Fabric 节点以将指标提交给 StatsD,请遵循此文档。 以下是 StatsD 当前为使用而发出的指标列表。
![](https://code84.com/wp-content/uploads/2022/08/v2-837954ea269f708efa90b296e53c2274_b.jpg)
将运营指标从不同类型的节点推送到 StatsD 的工作流程如图 4 所示:
- 每个 Fabric 节点定期向 StatsD 提交其相关指标。
- StatsD 将汇总的指标提交给后端服务,例如 Graphite,用于指标可视化和警报。
- 系统操作员通过后端服务的 WebUI 监控聚合指标。
- 后端服务根据操作员设置的条件向系统操作员发送警报和通知。
总结:
这是揭秘Hyperledger Fabric 系列的最后一篇文章。 您已经学习了 Hyperledger Fabric 中的多项服务,这些服务为区块链开发人员、区块链架构师和系统运营商提供了便利。
实际上,还有几个有趣的话题需要讨论,包括:
- Hyperledger Fabric 中的多版本并发控制
- Hyperledger Fabric 中的身份、身份验证和授权
- 通道级访问控制和策略
- 高级链码开发
- 链码级基于属性的访问控制
- 链码级加密
- Fabric排序服务
- Hyperledger Fabric 中的零知识证明
- 高级Fabric性能优化和高可用性