Hyperledger Fabric官方中文教程-改进笔记（九）-Fabric Gateway

本Fabric中文文档专栏的阅读前言：前言

文章目录

• 编写客户端应用程序
• 客户端应用程序 API
• Gateway如何认可您的交易提案
• • 生成和执行背书计划
  • 针对特定的背书Peer节点
  • 重试和错误处理
  • • 重试尝试
    • 错误处理
    • 超时
• 监听事件
• 发现服务
• • 为什么需要发现服务？
  • Fabric中的发现服务工作原理
  • 发现服务的能力
  • 特殊要求

在运行一个应用之前，我们应该先认识一个什么是Fabric Gateway，熟悉 Fabric Gateway 服务及其与应用程序事务的关系流

Fabric Gateway 是 Hyperledger Fabric v2.4 Peer节点中引入的一项服务，它提供了一个简化的最小 API，用于将交易提交到 Fabric 网络。以前对客户端 SDK 提出的要求（例如从不同组织的peer收集交易背书）被委托给在peer中运行的 Fabric Gateway 服务，以便在 v2.4 中简化应用程序开发和交易提交。

编写客户端应用程序

从 Fabric v2.4 开始，客户端应用程序应使用其中一个 Fabric Gateway 客户端 API（Go、Node 或 Java），这些 API 经过优化以与 Fabric Gateway 交互。这些 API 公开了最初在 Fabric v1.4 中引入的相同高级编程模型。

Fabric Gateway（又名Gateway）管理以下交易步骤：

• 评估交易建议。这将在单个对等节点上调用智能合约（链码）函数并将结果返回给客户端。这通常用于查询账本的当前状态，而无需进行任何账本更新。 Gateway会优先将请求发送到 同一组织内的节点（而非跨组织节点），以减少延迟并提高安全性，然后选择具有最高账本区块高度的Peer节点。如果Gateway的组织中没有可用的节点，则它将选择其他组织的节点。

这里可能有人会困惑：选择背书节点不是背书策略决定的吗，为什么这里Gateway会有选择节点的权利？因为背书策略只约束在组织层面，至于具体组织内哪个节点进行背书就由Gateway选择。

举例：若背书策略要求 ORG1 和 ORG2 各提供一个背书，Gateway 会从 ORG1 和 ORG2 中分别选一个可用节点，但选择的具体节点（如 peer1.org1 或 peer2.org1）由 Gateway 决定。

• 认可交易提案。这将收集足够的背书响应，以满足组合签名策略 （见下文）并将准备好的交易信封返回给客户端进行签名。

• 提交交易。这会将签名的交易信封发送到排序服务以提交到账本。

• 等待提交状态事件。这允许客户端等待交易提交到账本并 获取提交（验证/失效）状态代码。

• 接收链码事件。这将允许客户端应用程序响应智能合约发出的事件 当交易提交到账本时，函数。

Fabric Gateway 客户端 API 将 Endorse/Submit/CommitStatus作组合到单个阻塞 SubmitTransaction 函数中，以支持使用单行代码提交交易。或者，可以调用单个作来支持灵活的应用程序模式。

客户端应用程序 API

Gateway及其客户端 API 旨在使作为客户端应用程序开发人员能够专注于应用程序的业务逻辑，而不必担心与 Fabric 网络关联的基础结构逻辑。 因此，API 提供的是组织（organization）和合约（contract）这类逻辑抽象，而非节点（peer）和链码（chaincode）这类操作抽象。

Hyperledger Fabric 目前支持三种语言的客户端应用程序开发：

• GO。有关完整详细信息，请参阅 Go API 文档。

• **NODE（Typescript/Javascript）。**有关完整详细信息，请参阅 Node API 文档。

• JAVA。有关完整详细信息，请参阅 Java API 文档。

Gateway如何认可您的交易提案

为了使交易成功提交到账本，需要足够数量的背书才能满足 背书政策。获得组织的认可涉及连接到一个组织并让它根据其账本副本模拟（执行）交易提案。Peer通过调用链码函数（由提案中的名称和参数指定）并构建（和签名）读写集来模拟交易。读写集包含当前账本状态和响应该函数中状态获取/设置指令的建议更改。

应用于交易的背书策略（或多个策略的组合）取决于所调用链码函数的实现方式，可能是以下策略的组合：

交易提案所适用的背书策略组合是在链码运行时动态确定的，无法通过静态分析完全预判。

生成和执行背书计划

Fabric Gateway 代表客户端管理交易背书，其流程如下：

Gateway依赖于发现服务（下文会详细讨论）来获取可用同类和排序服务节点的连接详细信息，并计算认可交易所需的同类组合。因此，发现服务必须始终在启用Gateway服务的同类上保持启用状态。

Gateway背书过程对提案中作为临时数据传递的私有数据的限制更大，因为它通常包含不得传递给所有组织的Peer节点的敏感或个人信息。在这种情况下，Gateway会将背书组织集限制为那些属于要访问的私有数据集合的成员（读取或写入）。如果对瞬态数据的此限制不满足背书策略，则Gateway会向客户端返回错误，而不是将私有数据转发给可能无权访问私有数据的组织。在这些情况下，应编写客户端应用程序以显式定义哪些组织应背书交易。

针对特定的背书Peer节点

在某些情况下，客户端应用程序必须显式选择组织来评估或认可交易建议。 例如，瞬态数据通常包含个人或敏感信息，这些信息只能写入私有数据集合，从而限制了背书组织的池。 在这些情况下，客户端应用程序可以显式指定背书组织，以满足应用程序的隐私和背书要求;然后，Gateway将从每个指定组织中选择具有最高区块高度的（可用）背书Peer节点。 但是，如果客户端指定了一组不满足背书策略的组织，则交易仍可能得到指定的Peer节点的认可并提交以进行排序，但交易稍后将在验证和提交阶段被通道中的所有Peer节点失效。 此无效交易记录在账本上，但交易的更新不会写入任何通道Peer节点上的状态数据库。

重试和错误处理

Fabric Gateway 处理节点连接重试尝试、错误和超时，如下所述。

重试尝试

Gateway将使用发现服务信息重试由于对等节点或排序节点不可用而失败的任何交易。

错误处理

Fabric Gateway 管理与网络对等节点和排序节点的 gRPC 连接。如果Gateway服务请求错误源自网络对等节点或排序节点（即Gateway外部），那么Gateway将在Details消息字段中将错误、端点和组织 （MSP ID） 信息返回给客户机。如果该Details字段为空，则错误源自GatewayPeer节点。

if statusErr, ok := err.(*status.Status); ok {
details := statusErr.Details()
if len(details) == 0 {
log.Println("Error originated from Gateway peer")
}
}

超时

Gateway结构体的Evaluate和Endorse方法向Gateway外部的Peer节点发出 gRPC 请求。为了限制客户端必须等待这些集体响应的时间长度，可以在对等配置文件的gateway部分中覆盖peer.gateway.endorsementTimeout值（位于core.yaml）。

gateway:
endorsementTimeout: 30s

同样，Fabric Gateway 的Submit方法与排序服务节点建立 gRPC 连接，以广播认可的交易。为了限制客户机必须等待各个排序节点响应的时间长度，可以在对等配置文件的 gateway 部分中覆盖peer.gateway.broadcastTimeout值（位于core.yaml）。

gateway:
broadcastTimeout: 15s

Fabric Gateway 客户端 API 还提供了在从客户端应用程序调用时为每个Gateway方法设置默认超时和每次调用超时的机制。

client, err := gateway.Connect(
gateway.WithEvaluateTimeout(10*time.Second),
gateway.WithSubmitTimeout(20*time.Second),
)

监听事件

Gateway为客户端应用程序提供了一个简化的 API，用于在客户端应用程序中接收链码事件。客户端 API 提供了一种机制，用于使用特定于语言的习惯用法来处理这些事件。

发现服务

为什么需要发现服务？

客户端应用通过与Fabric网关交互来执行链码、向排序节点提交交易以及获取交易状态。因此，网关服务需要了解相关背书策略以及哪些节点已安装链码。

发现服务负责在节点间同步这些信息，Fabric网关通过与发现服务交互来确定需要哪些节点背书交易，以及将交易发送至哪些排序节点。

Fabric中的发现服务工作原理

应用启动时需要预先配置一个或多个可信网关节点，这些节点由应用开发者/管理员授权从其他节点收集背书。客户端应用优选使用同组织内的节点。注意：节点必须定义peer.gossip.externalEndpoint才能被发现服务识别，具体配置方法请参阅发现服务CLI文档。

发现服务客户端（如发现服务CLI或其他网关节点）向发现服务发起配置查询，获取通道内的节点信息。该信息可通过向节点的发现服务发送后续查询随时刷新。

发现服务运行在节点上，利用gossip通信层维护的网络元数据来发现在线节点，同时从节点的状态数据库获取相关信息（如背书策略）。

通过发现服务，代表客户端应用的网关节点只需向发现服务发送查询请求（指定通道和链码ID），发现服务将计算生成包含两个对象的描述符：

以下是策略AND(Org1, Org2)（每个组织有两个节点）生成的描述符示例：

Layouts: [
QuantitiesByGroup: {
"Org1": 1,
"Org2": 1,
}
],
EndorsersByGroups: {
"Org1": [peer0.org1, peer1.org1],
"Org2": [peer0.org2, peer1.org2]
}

即该背书策略要求来自Org1和Org2各一个节点的签名，并提供了这些组织中可用背书节点的名称（Org1和Org2中的peer0和peer1）。

在协调交易时，网关节点首先选择背书布局（如上例中的Org1 AND Org2策略），然后根据节点当前可用性和账本高度等信息从布局中选择具体背书节点。

发现服务的能力

发现服务可响应以下查询：

• 配置查询：返回通道内所有组织的MSP配置以及通道的排序节点端点

• 节点成员查询：返回已加入通道的节点列表

• 背书查询：返回指定通道内链码的背书描述符(当前交易的背书要求)

• 本地节点成员查询：返回响应查询的节点的本地成员信息。默认情况下客户端需具备管理员权限才能获取此查询响应

==注：==发现服务"只回答当前交易要求的策略" 以及 “哪些组织/节点符合策略”，而Gateway 决定 “具体选哪个节点、如何执行流程”。即前者进行查询，后者进行决定和执行

特殊要求

当节点启用TLS运行时，客户端连接节点时必须提供TLS证书。如果节点未配置验证客户端证书（clientAuthRequired为false），则可以使用自签名证书。