RabbitMQ文档翻译六(JAVA).远程过程调用（RPC）

骑猪看日落 2023-02-17 01:15 40阅读 0赞

在[第二个教程][Link 1]中，我们学习了如何使用工作队列在多个工作人员之间分配耗时的任务。  
但是如果我们需要在远程计算机上运行一个函数并等待结果呢？好吧，那是另一回事了。这种模式通常称为远程过程调用或RPC。

在本教程中，我们将使用RabbitMQ构建一个RPC系统：一个客户端和一个可伸缩的RPC服务器。由于我们没有任何值得分发的耗时任务，我们将创建一个返回Fibonacci数的虚拟RPC服务。

### 客户端接口 ###

为了说明如何使用RPC服务，我们将创建一个简单的客户端类。它将暴露一个名为call的方法，该方法发送一个RPC请求并阻塞，直到收到响应：

FibonacciRpcClient fibonacciRpc = new FibonacciRpcClient();
    String result = fibonacciRpc.call("4");
    System.out.println( "fib(4) is " + result);

> **关于RPC的一点注记**  
> 虽然RPC在计算中是一种非常常见的模式，但它经常受到批评。当程序员不知道一个函数调用是本地调用还是一个缓慢的RPC时，问题就出现了。这样的混乱会导致系统不可预测，并为调试增加不必要的复杂性。误用RPC不但不能简化软件，反而会导致无法维护的意大利面代码。
> 
> **牢记这一点，请考虑以下建议：**
> 
>  *  确定哪个函数调用是本地的，哪个是远程的。
>  *  记录好系统文档。明确组件之间的依赖关系。
>  *  容错。当RPC服务器长时间关闭时，客户端应该如何反应？
> 
> 有疑问时避免RPC。如果可以，您应该使用异步管道，而不是像RPC那样的阻塞，结果被异步地推送到下一个计算阶段。

### 回调队列 ###

一般来说，在RabbitMQ上执行RPC是很容易的。客户端发送请求消息，服务器用响应消息进行响应。为了接收响应，我们需要将“回调”队列地址与请求一起发送。我们可以使用默认队列（在Java客户端中是独占的）。让我们试试：

callbackQueueName = channel.queueDeclare().getQueue();
    
    BasicProperties props = new BasicProperties
                                .Builder()
                                .replyTo(callbackQueueName)
                                .build();
    
    channel.basicPublish("", "rpc_queue", props, message.getBytes());
    
    // ... then code to read a response message from the callback_queue ...

> 消息属性  
> AMQP 0-9-1协议预先定义了一组14个属性，这些属性与消息一起使用。除以下情况外，大多数属性很少使用：
> 
>  *  deliveryMode：将消息标记为持久（值为2）或临时（任何其他值）。您可能记得第二个教程中的这个属性。
>  *  contentType：用于描述编码的mime-type. 例如，对于经常使用的JSON编码，最好将此属性设置为：application/JSON。
>  *  replyTo：通常用于命名回调队列。
>  *  correlationId：用于将RPC响应与请求关联起来。

我们需要新的导入：

import com.rabbitmq.client.AMQP.BasicProperties;

### 关联Id ###

在上面介绍的方法中，我们建议为每个RPC请求创建一个回调队列。这相当低效，但幸运的是有一个更好的方法-让我们为每个客户端创建一个回调队列。  
这引发了一个新问题，在该队列中接收到响应后，不清楚该响应属于哪个请求。此时将使用correlationId属性。我们将为每个请求设置一个唯一的值。稍后，当我们在回调队列中收到消息时，我们将查看此属性，并基于该属性，我们将能够将响应与请求相匹配。如果我们看到一个未知的correlationId值，我们可以安全地丢弃该消息-它不属于我们的请求。  
您可能会问，为什么我们应该忽略回调队列中的未知消息，而不是因为错误而失败？这是由于服务器端可能存在争用情况。虽然不太可能，但是RPC服务器有可能在向我们发送应答之后，但在发送请求的确认消息之前死亡。如果发生这种情况，重新启动的RPC服务器将再次处理该请求。这就是为什么在客户机上我们必须优雅地处理重复的响应，RPC在理想情况下应该是幂等的。

### 总结 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMwNDE2NDI_size_16_color_FFFFFF_t_70]

我们的RPC将这样工作：

*  对于一个RPC请求，客户机发送一个包含两个属性的消息：replyTo，它被设置为只为请求创建的匿名独占队列，correlationId为每个请求设置了一个唯一的值。
 *  请求被发送到rpc\_queue队列。
 *  RPC工作线程（又名：服务器）正在等待该队列上的请求。当一个请求出现时，它执行该任务，并使用replyTo字段中的队列将结果发送回客户机。
 *  客户机等待应答队列上的数据。当消息出现时，它检查correlationId属性。如果它与请求中的值匹配，则将响应返回给应用程序。

### 把他们放在一起 ###

斐波纳契任务：

private static int fib(int n) { 
        if (n == 0) return 0;
        if (n == 1) return 1;
        return fib(n-1) + fib(n-2);
    }

我们声明了fibonacci函数。它假设只有有效的正整数输入。（不要指望这个方法能处理大数据，而且它可能是最慢的递归实现）。  
我们的RPC服务器的代码可以在这里找到：[RPCServer.java.][]

服务器代码相当简单：

*  像往常一样，我们从建立连接、通道和声明队列开始。
 *  我们可能需要运行多个服务器进程。为了在多个服务器上平均分配负载，我们需要在channel.basicQos中设置prefetchCount.
 *  我们使用basicConsume来访问队列，在basicConsume方法的参数中中我们以一个对象（DeliverCallback）的形式提供一个回调，该对象将执行工作并将响应发回。

我们的RPC客户端的代码可以在这里找到：[RPCClient.java][].  
客户端代码稍微更复杂一些：

*  我们建立了连接和通道。
 *  我们的call方法产生实际的RPC请求。
 *  在这里，我们首先生成一个唯一的correlationId号并保存它-我们的消费者回调将使用这个值来匹配适当的响应。
 *  然后，我们为应答创建一个专用的独占队列并订阅它。
 *  接下来，我们发布请求消息，包含两个属性：replyTo和correlationId。
 *  在这一点上，我们可以坐下来，等待正确的响应到来。
 *  因为我们的消费者交付处理是在一个单独的线程中进行的，所以在响应到达之前，我们需要一些东西来挂起主线程。使用BlockingQueue是一种可能的解决方案。这里我们创建的ArrayBlockingQueue的容量设置为1，因为我们只需要等待一个响应。
 *  消费者正在做一个非常简单的工作，对于每个被消费的响应消息，它都会检查correlationId是否就是我们要查找的那个。如果是这样，它将响应放入BlockingQueue。
 *  同时，主线程正在等待从BlockingQueue获取响应。
 *  最后，我们将响应返回给用户。

向客户发出请求：

RPCClient fibonacciRpc = new RPCClient();
    
    System.out.println(" [x] Requesting fib(30)");
    String response = fibonacciRpc.call("30");
    System.out.println(" [.] Got '" + response + "'");
    
    fibonacciRpc.close();

像往常一样编译并设置类路径（参见教程一）：

javac -cp $CP RPCClient.java RPCServer.java

我们的RPC服务现在准备好了。我们可以启动服务器：

java -cp $CP RPCServer
    # => [x] Awaiting RPC requests

要请求fibonacci数列，请运行客户端：

java -cp $CP RPCClient
    # => [x] Requesting fib(30)

这里介绍的设计并不是RPC服务的唯一可能实现，但它有一些重要的优点：

*  如果RPC服务器太慢，您可以通过运行另一个服务器来扩展。尝试在新控制台中运行第二个RPCServer。
 *  在客户端，RPC只需要发送和接收一条消息。不需要像queueDeclare这样的同步调用。因此，RPC客户机只需要为单个RPC请求进行一次网络往返。

我们的代码仍然非常简单，不试图解决更复杂（但很重要）的问题，例如：

*  如果没有服务器在运行，客户机应该如何反应？
 *  客户端应该为RPC设置某种超时吗？
 *  如果服务器发生故障并引发异常，是否应将其转发给客户端？
 *  在处理之前防止无效的传入消息（如检查边界、类型）。

[Link 1]: https://blog.csdn.net/u013041642/article/details/107050332
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMwNDE2NDI_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/2020070120414950.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMwNDE2NDI=,size_16,color_FFFFFF,t_70
[RPCServer.java.]: https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCServer.java
[RPCClient.java]: https://github.com/rabbitmq/rabbitmq-tutorials/blob/master/java/RPCClient.java