我使用“github.com/streadway/amqp”通过队列（RabbitMQ）进行异步处理请求。
我使用“github.com/gorilla/rpc”注册我的服务没有解决方法，但我必须使用丑陋的解决方案将amqp.Delivery转换为http.Request（mux.Server只能与http.Request一起使用）。
我可以为这项任务使用更优雅的解决方案吗？
我找不到AMQP的JSON RPC路由器。
首先，RPC和pub-sub（例如AMQP）是两个非常不同的野兽;试图用一个来实现另一个并不一定是错误或坏的，但它肯定是可疑的，并暗示在设计的某个地方可能会出现故障。所以我强烈建议从业务目标开始重新考虑设计，并确保您尝试实现的内容实际上是实现所需功能的正确方法。
也就是说，你所描述的基本上是可能的，但是你想把你的抽象提升到一个水平。试图通过AMQP发送http.Request是以一种只会导致更多问题的方式混合协议。实现此行为的更简洁方法是拥有一个处理http.Requests（正常）的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）
我希望至少能为您提供足够的信息，让您在实施中走上正轨。祝好运！