我使用"github.com/streadway/amqp"通过队列(RabbitMQ)异步处理请求。
我使用"github.com/gorilla/rpc"来注册我的服务而无需解决方法，但我必须使用丑陋的解决方案进行转换 amqp。交付到 http。请求(复用。服务器可以使用http。仅请求)。
我可以使用更优雅的解决方案来完成此任务吗？
我找不到适用于 AMQP 的 JSON RPC 路由器。
首先，RPC和pub-sub(例如AMQP)是两个非常不同的野兽;试图使用一个来实现另一个不一定是错误或坏的，但它绝对是可疑的，并暗示设计中的某个地方可能会出现故障。因此，我强烈建议您从业务目标开始重新考虑设计，并确保您尝试实现的内容实际上是实现所需功能的正确方法。
也就是说，你所描述的基本上是可能的，但你想把你的抽象提升一个层次。尝试通过AMQP发送http.Request是混合协议，只会导致更多问题。实现此行为的更简洁方法是使用一个处理http.Request的 HTTP 处理程序(正常处理)，以及一个处理amqp.Deliverys(正常)的 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 处理程序更易于单独测试，因为您将协议逻辑与业务逻辑分开，即使您不尝试处理多个协议，这也会很有帮助(即，即使您只执行 HTTP，也不是一个坏主意)
我希望至少能为您提供足够的信息，让您在实施中走上正确的轨道。祝你好运！