我使用“github.com/streadway/amqp”通过队列 (RabbitMQ) 进行异步处理请求。
我使用“github.com/gorilla/rpc”注册我的服务，没有解决方法，但我必须使用丑陋的解决方案将 amqp.Delivery 转换为 http.Request(mux.Server 只能与 http.Request 一起使用) .
我可以为这个任务使用更优雅的解决方案吗？
我找不到 AMQP 的 JSON RPC 路由器。
最佳答案
首先，RPC 和发布-订阅(例如 AMQP)是两种非常不同的野兽；试图用一个来实现另一个不一定是错的或坏的，但它肯定是可疑的，并且暗示设计中的某个地方可能存在故障。因此，我强烈建议从您的业务目标开始重新考虑设计，并确保您尝试实现的实际上是实现所需功能的正确方法。
也就是说，您所描述的基本上是可能的，但您想将抽象提升一个层次。尝试通过 AMQP 发送 http.Request 是以一种只会导致更多问题的方式混合协议(protocol)。实现此行为的更简洁的方法是拥有一个处理 http.Request 的 HTTP 处理程序(正常情况下)，以及一个处理 amqp.Delivery 的 AMQP 处理程序(像往常一样)，并让每个处理程序调用一个共享的业务逻辑处理程序，该处理程序仅处理您的域模型。
因此，您的 HTTP 处理程序将解析 HTTP 请求并将其转换为域对象 - 您没有在问题中提供任何具体细节，所以我可能会发明类似 myapp.UserRegistration 的东西.您的 HTTP 处理程序会将其传递给 myapp.UserService，它会处理注册用户的实际业务逻辑，它会返回一个结果，然后您会将其转换为适当的类型，编码为 JSON，并在 http.Response 中发送回客户端。 myapp.UserService 对 HTTP 或 AMQP 一无所知；它仅在您自己的域类型上运行。
您的 AMQP 处理程序将获取一条消息，将其解析为相同的 myapp.UserRegistration 类型，将其传递给相同的 myapp.UserService 处理程序，并获得相同的响应 - 确保 AMQP 和 HTTP 的业务逻辑以相同的方式运行。然后你会得到你的回应，而且......好吧，这是 AMQP，所以你不必向客户端发送回应。我不知道你的设置，也许你有另一个队列可以发送回响应，也许你不关心响应并可以丢弃它。这是 RPC 和 AMQP 之间最明显的区别。
这也使您的业务逻辑、HTTP 处理程序和 AMQP 处理程序更易于单独测试，因为您将协议(protocol)逻辑与业务逻辑分开，即使您不尝试处理多个协议(protocol)(也就是说，即使您只使用 HTTP，这也不是一个坏主意)
我希望至少能为您提供足够的信息，让您在实现过程中走上正轨。祝你好运!
关于go - 带有 AMQP 的 Golang 中的 JSON RPC，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/55330441/