本文主要是介绍Hyperledger Fabric 2.4 Fabric Gateway文档翻译，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
翻译：原文地址
Fabric Gateway是Hyperledger Fabric v2.4 在peers上增加的一项服务，为向网络提交事务提供简单的小型的API。之前客户端SDK的需求，比如从不同组织的peers中收集交易背书，在v2.4中通过使用Fabric Gateway服务，只需要一个peer运行一个应用进程即可提交事务。
写客户端应用
使用Fabric2.4，写客户端应用可以用到 Fabric Gateway 的一些API，而且流程经过了优化。这些API如同v1.4版本时介绍的高水平编程模型。
Fabric Gateway 管理如下事务步骤：
- 评估交易提案。这将在一个peer上调用职能合约并返回结果给客户端。这个操作通常用于查询当前账本的状态而不是用于账本更新。gateway优先选择同一个组织的peer作为the gateway peer ，且选择的是账本中区块最高的peer。如果gateway的组织内没有合适的peer，此时会从其他组织中选择peer。
- 背书（签署）交易提案。gateway会收集足够的背书来满足联合签名策略，将准备好的交易envelope返回给客户端，让其进行签名。
- 提交交易。提交交易事务到order服务上，提交到账本中。
- 等待提交状态事件。让客户端可以等待交易提交到账本后的结果，获取交易状态码
- 接收链码事件。这会允许客户端应用根据链码执行后返回的数据进行响应。
Fabric Gateway 客户端的 API组合Endorse/Submit/CommitStatus 动作到一个 SubmitTransaction函数，来做到一行代码实现交易事件。或者，可以使用单个操作来支持灵活的应用程序模式。
客户端应用API
Fabric Gateway及其API设计的目的是，让客户端应用开发者能够专注于业务逻辑，而不必关系Fabric的基础架构逻辑。因此，API提供了组织和合约的逻辑抽象，而不是对操作抽象也不是对链码和peer的抽象。【旁注——很明显，管理API希望公开这些操作抽象，而不是管理API】
Fabric当前支持以下三种客户端应用编程语言：
- Go 查看GO API
- Node，查看Node API
- Java,查看 Java API
gateway怎么背书（签署）交易提案
为了交易事务成功提交到账本中，需要满足背书策略要求的背书数量。获取一个组织的背书需要联系组织中的一个peer，并让它在自己复制的账本上模拟执行。peer通过调用链码来模拟执行交易事务，以交易的名称和参数做标记，建立一个读写集合。这个读写集包含了当前账本状态和执行交易后的状态。
应用于事务的背书策略或多个策略之和取决于正在调用的链码函数的实现，可以使以下各项的组合：
- 链码背书策略。channel的组织成员在批准链码时同意的策略。如果链码函数调用了另一个链码，则两方策略都需要满足。
- 私有数据集合背书策略。如果链码向私有数据中写入一个状态，则该集合的认可策略将覆盖该状态的链码策略。
- 如果链码函数从私有数据集合中读取数据，则它将仅限于该集合成员的组织。
- 基于状态的背书策略（SBE）。这些策略也被称为密钥级签名策略，可应用于单独的状态，并将覆盖链码策略或者私有数据集合的策略。背书策略存贮在账本上，可以通过交易事务更新。
应用于交易事务的背书策略组合是在链码运行是确定的，不一定是从静态分析得出的。gateway使用以下过程代表客户端管理交易背书的复杂性：
- gateway从组织中选择peer做背书，选择的是最高块高度的peer。假设在gateway peer组织内的peer都是被联系它的客户端所信任的。
- 在选定的peer上模拟交易提案。该模拟获取有关访问状态的信息，因此，需要将背书策略结合起来（包括peer上任何独立地基于状态的背书策略）。
- 捕获的背书策略被组装入
ChaincodeInterest协议结构，并将其传递给发现服务，以得出特定于交易事务的背书计划。 - gateway通过请求满足计划中所有政策所需来批准应用批准计划。对于每个组织，gateway peer会选取组织中区块最高的peer
gateway是依靠discovery service 来获取需要联系的peer和order的信息，并计算交易事务需要背书所需哪些peer。所以在gateway服务开启的peer上，discovery service也要开启。
gateway背书进程对私密数据有严格的限制，数据会以临时数据的方式在组织中传递，因为私密数据往往是敏感和个人数据，不能在全部组织中传递。对于这种情况，gateway需要限制背书组织为私密数据集合的成员（或读或写）。如果限制没有满足背书策略，gateway会返回error到客户端，而不是继续将私密数据在组织间传递，因为这可能会被私密数据拒绝访问。这种情况下客户端应用需要写清楚 explicitly define which organizations should endorse。
指明背书peer
在某些情况下，一个客户端应用必须明确指定需要哪些组织来审议和背书交易提案。例如，临时数据经常包含个人或敏感信息只能写入到私密数据集合，因此需要限制背书组织集合。这些情况下，客户端应用指明背书组织，以满足隐私和背书需求；gateway需要从指定的背书组织中选取区块最高的peer。但是，如果客户端指明的背书组织没有满足背书策略，交易依然会获取指明的peer的背书，并提交到order，但在验证和提交阶段，所有peer会使交易无效。这次无效会记录在账本上，但交易不会写入到状态任何peer的状态数据库中。
重试和错误处理
gateway处理节点有重试连接，错误和延时处理。
重试
gateway会使用discovery service的信息来重试连接不可以用peer和node。如果一个组织运行了多个peer或order节点，那另一个合格的节点会被尝试连接。如果一个组织背书交易时失败，那另一个组织会被尝试。如果一个组织一致背书失败，一组满足条件的组织会成为新的目标。只有没有了满足背书策略的peer可用，gateway才会停止尝试。gateway会一致尝试，直到所有可能的背书peer都被试过。
错误处理
Fabric gateway通过gRPC联系网络中的peer和order。如果gateway请求错误源于peer和order的网络（也就是gateway外部），gateway会返回错误，端口，和组织ID信息给客户端在details字段中。如果details字段为空，那错误来自原gateway peer。
超时
Fabric gateway的评估和背书方法向外部的gateway发送gRPC请求。为了限制客户端需要等待响应的时间，core.yaml中的peer.gateway.endorsementTimeout可以再gateway中重置。
Fabric gateway客户端api也提供了默认设置和单次调用超时设置的机制。
接收事件
gateway 提供了简单的接受chaincode events的API。客户端API提供了一种机制，可以使用特定于语言的习惯用法来处理这些事件。
这篇关于Hyperledger Fabric 2.4 Fabric Gateway文档翻译的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
