从现在开始，努力学习吧！本文《收到另一个请求后提供 HTTP 请求的响应》主要讲解了等等相关知识点，我会在golang学习网中持续更新相关的系列文章，欢迎大家关注并积极留言建议。下面就先一起来看一下本篇正文内容吧，希望能帮到你！

我的用例是在从单独的服务器接收到另一个请求后提供 HTTP 请求的响应。

1. 我希望以尽可能最好的方式做到这一点，同时牢记扩展性。
2. 我们使用 Golang 1.19 和 Gin 框架。
3. 服务器将有多个 Pod，因此通道将无法工作。
4. 所有请求都会超时，初始请求将在 60 秒后超时。

我当前的解决方案是使用共享缓存，其中每个 Pod 都会不断检查缓存。我相信，我可以通过通道来优化这一点，系统定期检查任何已完成的响应，而不是逐一检查缓存。

我还想知道如何用其他编程语言实现它。

PS：这是基于设计的查询，我在这里有一些分享赏金的声誉，因此在这里询问。如果问题不清楚，请随时编辑。

正确答案

tl;博士

问题描述

因此，假设您的服务器应用程序名为 server_app，例如有 3 个 pod：

+---------------------+
     |  server_app_service |
     +---------------------+
     |  server_app_pod_a   |
     |  server_app_pod_b   |
     |  server_app_pod_c   |
     +---------------------+

您的服务收到一个名为 "request a" 的请求，并决定将其传递给 server_app_pod_a。现在，您的 server_app_pod_a 将请求转发到某个网关，并等待某种通知，以继续处理客户端的响应。正如您所知，无法保证当网关执行 request b 时，服务会再次将其传递给 server_app_pod_a。即使这样做，应用程序的状态管理也将成为一项艰巨的任务。

消息传递

正如您可能已经注意到的，我在上一段中将“通知”一词加粗，这是因为如果您认真考虑一下，request“b”看起来更像是带有一些消息的通知 而不是对某些资源的请求。所以我的第一选择是像 kafka 这样的消息队列（正如你所知，有很多这样的消息队列）。这个想法是，如果您可以定义一种算法来计算请求的唯一键，那么您就可以在完全相同的 pod 中收到结果通知。这样，状态管理会更简单，而且在同一个 pod 中获得通知的机会也会更高（当然这取决于很多因素，比如消息队列的状态）。看看您的问题：

1. 我希望以尽可能最好的方式做到这一点，同时牢记扩展性。

当然，您可以像 kafka 一样使用这些消息队列，以实现消息队列和应用程序的扩展并减少数据丢失。

1. 所有请求都会超时，初始请求将在 60 秒后超时。

这取决于您如何管理代码库中的超时，使用上下文是一个好主意。

我还想知道如何用其他编程语言实现它。

使用消息队列是一个通用的想法，它适用于几乎任何编程语言，但根据语言的编程范例以及特定于语言的库和工具，可能还有其他一些方法来解决此问题。例如在 scala 中，如果您使用一些名为 akka 的特定工具（它提供了 actor 模型编程范例），您可以使用所谓的 akka-cluster-sharding 来处理这个问题。这个想法非常简单，我们知道必须有某种监督者，它知道自己的订阅者的确切位置和状态。因此，当它收到一些消息时，它只知道将请求转发到何处以及哪个参与者（我们正在讨论参与者模型编程）。换句话说，它可用于在集群上生成的参与者之间共享状态，无论是否在同一台机器上。但作为个人偏好，我不会选择特定语言的交流，而是会坚持一般的想法，因为这可能会在未来引起问题。

总结

足够长的解释:)。为了理解我所说的内容，让我们跟踪完全相同的场景，但通信模型有所不同：

1. 客户端向 server_app 服务发送请求“a”。
2. 服务选择其中一个 pod（例如 server_app_pod_b）来处理请求。
3. 然后，pod 尝试为请求定义一些密钥，并将其与请求一起传递到网关，并等待带有该密钥的消息在队列中发布。
4. 网关执行其应有的操作，并使用密钥发送消息到消息队列。
5. 完全相同的 pod serer_app_pod_b 接收带有密钥的消息，获取消息的数据，并继续处理客户端的请求。

可能还有其他方法可以解决这个问题，但这就是我想要的。希望对您有帮助！

以上就是《收到另一个请求后提供 HTTP 请求的响应》的详细内容，更多关于的资料请关注golang学习网公众号！