使用Hyperledger Fabric发现服务与fabric-gateway。

huangapple go评论54阅读模式
英文:

Using hyperledger fabric discovery service with fabric-gateway

问题

在使用fabric-gateway时,指定多个可供客户端应用程序联系以在通道上启动事务的最佳方法是什么?

我在文档中找到的示例依赖于与单个对等体的连接,但我认为这有问题,因为如果对等体下线,应用程序将无法工作。我考虑手动在应用程序端分发请求,但我不确定这是否是预期的做法。

// 为特定客户端身份创建网关连接
gw, err := client.Connect(
	id,
	client.WithSign(sign),
	client.WithClientConnection(clientConnection),
	// 不同gRPC调用的默认超时时间
	client.WithEvaluateTimeout(5*time.Second),
	client.WithEndorseTimeout(15*time.Second),
	client.WithSubmitTimeout(5*time.Second),
	client.WithCommitStatusTimeout(1*time.Minute),
)
英文:

What is the best way to go about specifying several peers that client application could contact for them to start a transaction on a channel when using fabric-gateway?

Examples I've found in docs rely on connection to a single peer, which I find problematic, since if it goes offline the application won't work. I thought about distributing requests manually application-side, but I am not sure it is the intended way to go about it.

// Create a Gateway connection for a specific client identity
gw, err := client.Connect(
	id,
	client.WithSign(sign),
	client.WithClientConnection(clientConnection),
	// Default timeouts for different gRPC calls
	client.WithEvaluateTimeout(5*time.Second),
	client.WithEndorseTimeout(15*time.Second),
	client.WithSubmitTimeout(5*time.Second),
	client.WithCommitStatusTimeout(1*time.Minute),
)

答案1

得分: 0

这部分内容的翻译如下:

这里可能有助于将您的客户端应用程序连接到网关服务看作是类似于Web浏览器连接到特定网站。存在一个与单个逻辑终点的单个逻辑连接。这并不意味着如果一个网关节点(或Web服务器)下线,您的客户端应用程序(或Web浏览器)必须停止工作。

Fabric样本存储库中的此部分讨论了可以采取的一些方法,以确保高可用性:

https://github.com/hyperledger/fabric-samples/blob/main/full-stack-asset-transfer-guide/docs/ApplicationDev/01-FabricGateway.md#production-deployment-of-fabric-gateway

总结一下:

  • gRPC连接本身是一个逻辑构造,它封装的网络连接可以在客户端端点之间进行故障切换,可以使用基于单个DNS条目映射到多个IP地址的默认行为,也可以使用自定义策略。
  • gRPC连接将尝试透明地重新建立失败的网络连接,可以使用服务器端负载平衡将网络连接定向到不同的物理节点,以实现高可用性,而无需客户端担心它。

节点内的网关服务在事务调用时内部使用发现服务来帮助选择最佳的节点,并在事务流程期间管理故障切换。您的客户端应用程序应仅使用来自受信任组织的网关节点(理想情况下在单个端点地址上公开),因此无需与发现服务交互以发现其他网络节点。

英文:

It might help to think of your client application connecting to the Gateway service as similar to a Web browser connecting to a specific Website. There is a single logical connection to a single logical endpoint. That does not mean that your client application (or Web browser) must stop working if a single Gateway peer (or Web server) goes offline.

This section from workshop material in the Fabric samples repository discusses some of the approaches that can be taken to ensure high availability:

https://github.com/hyperledger/fabric-samples/blob/main/full-stack-asset-transfer-guide/docs/ApplicationDev/01-FabricGateway.md#production-deployment-of-fabric-gateway

To summarise:

  • The gRPC connection itself is a logical construct and the network connection(s) it encapsulates can fail-over from the client side between different endpoints, either using default behaviour based on single DNS entry mapping to multiple IP addresses, or using a custom policy.
  • The gRPC connection will transparently attempt to reestablish failed network connections, and network connections can be directed to different physical peers using server-side load balancing to achieve high availability without the client having to worry about it.

The Gateway service within the peer uses the discovery service internally to help select the best peers for transaction invocations, and to manage fail-over during the transaction flow. Your client application should only be using Gateway peers from a trusted organisation (ideally exposed on a single endpoint address) so should have no need to interact with the discovery service to discover other network peers.

huangapple
  • 本文由 发表于 2023年6月22日 04:28:34
  • 转载请务必保留本文链接:https://go.coder-hub.com/76526914.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定