远程过程调用（Remote Proceddure call【RPC】）

（本实例都是使用的Net的客户端，使用C#编写）

  在中，我们学习了如何使用工作队列在多个工作实例之间分配耗时的任务。

  但是，如果我们需要在远程计算机上运行功能并等待结果怎么办？ 那是一个不同的故事。 此模式通常称为远程过程调用或RPC。

  在本教程中，我们将使用RabbitMQ构建一个RPC系统：一个客户机和一个可扩展的RPC服务器。 由于我们没有任何值得分发的耗时任务，我们将创建一个返回斐波纳契数字的虚拟RPC服务。

1、客户端接口【Client Interface】

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

var rpcClient = new RPCClient();Console.WriteLine(" [x] Requesting fib(30)");var response = rpcClient.Call("30");Console.WriteLine(" [.] Got '{0}'", response);rpcClient.Close();

   关于RPC的注释

   虽然RPC是一个很常见的计算模式，但它经常被批评。 当系统出现问题的时候，程序员不知道函数调用是本地函数还是缓慢的RPC调用，这样的混乱导致了系统的不可预测性，并增加了调试的复杂性。 滥用RPC可能导致代码的可维护性很差，这样的设计不但没有简化软件，而且只会是系统更糟。

   铭记这一点，请考虑以下建议：

     确保显而易见哪个函数调用是本地的，哪个是远程的。

     记录您的系统。 使组件之间的依赖关系清除。

     处理错误情况。 当RPC服务器停机很长时间后，客户端应该如何反应？

    当有疑问避免RPC。 如果可以的话，您应该使用异步管道 - 而不是类似RPC的阻塞，将异步推送到下一个计算阶段。

2、回调队列【Callback queue】

 

   一般来说RPC对RabbitMQ来说很容易。 客户端发送请求消息，服务器回复一条响应消息。 为了收到一个响应，我们需要发送一个请求向'回调'的队列地址：

var corrId = Guid.NewGuid().ToString();var props = channel.CreateBasicProperties();props.ReplyTo = replyQueueName;props.CorrelationId = corrId;var messageBytes = Encoding.UTF8.GetBytes(message);channel.BasicPublish(exchange: "",                     routingKey: "rpc_queue",                     basicProperties: props,                     body: messageBytes);// ... then code to read a response message from the callback_queue ...

消息属性

  AMQP 0-9-1协议预先定义了一组14个随附消息的属性。 大多数属性很少使用，除了以下内容：

  deliveryMode：将消息标记为persistent（值为2）或transient（任何其他值）。 您可能会从第二个教程中记住此属性。

  contentType：用于描述mime类型的编码。 例如对于经常使用的JSON编码，将此属性设置为：application / json是一个很好的做法。

  replyTo：通常用来命名一个回调队列。

  correlationId：用于将RPC响应与请求相关联。

3、相关标识【Correlation Id】

  在上面所提出的方法中，我们建议为每个RPC请求创建一个回调队列。这是非常低效的，但幸运的是有一个更好的方法 - 让我们为每个客户端创建一个回调队列。

  这将引发了一个新问题，在该队列中收到响应，响应所属的请求是不知道的。此时正是使用correlationId属性的时候。我们将为每个请求设置一个唯一的值。稍后，当我们在回调队列中收到一条消息时，我们将查看此属性，并且基于此，我们将能够将响应与请求相匹配。如果我们看到一个未知的correlationId值，我们可以安全地丢弃该消息 - 它不属于我们的请求。

  您可能会问，为什么我们应该忽略回调队列中的未知消息，而不是出现错误？这是由于服务器端可能出现竞争情况。虽然不太可能，RPC服务器可能会在发送答复之后，但在发送请求的确认消息之前死亡。如果发生这种情况，重新启动的RPC服务器将再次处理该请求。这就是为什么在客户端上，我们必须优雅地处理这些重复的响应，并且RPC应该理想地是幂等的。

4、概要【Summary】

 

  我们的RPC将像这样工作：

     当客户端启动时，它创建一个匿名独占回调队列。

     对于RPC请求，客户端发送一个具有两个属性的消息：replyTo，它被设置为回调队列和correlationId，它被设置为每个请求的唯一值。

     请求被发送到rpc_queue队列。

     RPC worker（aka：server）正在等待队列上的请求。 当请求出现时，它将执行该作业，并使用replyTo字段中的队列将结果发送回客户端。

     客户端等待回呼队列中的数据。 当信息出现时，它检查correlationId属性。 如果它与请求中的值相匹配，则返回对应用程序的响应。

5、整合

  斐波纳契【Fibonacci】任务：

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

  我们声明斐波那契函数。 它只假设有效的正整数输入。 （不要指望这一个能为大数字工作，而且这可能是最慢的递归实现）

   我们的RPC服务器的代码如下所示：

1  using System; 2 using RabbitMQ.Client; 3 using RabbitMQ.Client.Events; 4 using System.Text; 5  6 class RPCServer 7 { 8     public static void Main() 9     {10         var factory = new ConnectionFactory() { HostName = "localhost" };11         using (var connection = factory.CreateConnection())12         using (var channel = connection.CreateModel())13         {14             channel.QueueDeclare(queue: "rpc_queue", durable: false,15               exclusive: false, autoDelete: false, arguments: null);16             channel.BasicQos(0, 1, false);17             var consumer = new EventingBasicConsumer(channel);18             channel.BasicConsume(queue: "rpc_queue",19               noAck: false, consumer: consumer);20             Console.WriteLine(" [x] Awaiting RPC requests");21 22             consumer.Received += (model, ea) =>23             {24                 string response = null;25 26                 var body = ea.Body;27                 var props = ea.BasicProperties;28                 var replyProps = channel.CreateBasicProperties();29                 replyProps.CorrelationId = props.CorrelationId;30 31                 try32                 {33                     var message = Encoding.UTF8.GetString(body);34                     int n = int.Parse(message);35                     Console.WriteLine(" [.] fib({0})", message);36                     response = fib(n).ToString();37                 }38                 catch (Exception e)39                 {40                     Console.WriteLine(" [.] " + e.Message);41                     response = "";42                 }43                 finally44                 {45                     var responseBytes = Encoding.UTF8.GetBytes(response);46                     channel.BasicPublish(exchange: "", routingKey: props.ReplyTo,47                       basicProperties: replyProps, body: responseBytes);48                     channel.BasicAck(deliveryTag: ea.DeliveryTag,49                       multiple: false);50                 }51             };52 53             Console.WriteLine(" Press [enter] to exit.");54             Console.ReadLine();55         }56     }57 58     ///59 60     /// Assumes only valid positive integer input.61     /// Don't expect this one to work for big numbers, and it's62     /// probably the slowest recursive implementation possible.63     ///64 65     private static int fib(int n)66     {67         if (n == 0 || n == 1)68         {69             return n;70         }71 72         return fib(n - 1) + fib(n - 2);73     }74 }

 服务器代码相当简单：

     像往常一样，我们开始建立连接，通道并声明队列。

     我们可能想要运行多个服务器进程。 为了在多个服务器上平均分配负载，我们需要在channel.basicQos中设置prefetchCount设置。

     我们使用basicConsume访问队列。 然后我们注册一个交付处理程序，我们在其中进行工作并发回响应。

我们的RPC客户端的代码：

1 using System; 2 using System.Collections.Generic; 3 using System.Linq; 4 using System.Text; 5 using System.Threading.Tasks; 6 using RabbitMQ.Client; 7 using RabbitMQ.Client.Events; 8  9 class RPCClient10 {11     private IConnection connection;12     private IModel channel;13     private string replyQueueName;14     private QueueingBasicConsumer consumer;15 16     public RPCClient()17     {18         var factory = new ConnectionFactory() { HostName = "localhost" };19         connection = factory.CreateConnection();20         channel = connection.CreateModel();21         replyQueueName = channel.QueueDeclare().QueueName;22         consumer = new QueueingBasicConsumer(channel);23         channel.BasicConsume(queue: replyQueueName,24                              noAck: true,25                              consumer: consumer);26     }27 28     public string Call(string message)29     {30         var corrId = Guid.NewGuid().ToString();31         var props = channel.CreateBasicProperties();32         props.ReplyTo = replyQueueName;33         props.CorrelationId = corrId;34 35         var messageBytes = Encoding.UTF8.GetBytes(message);36         channel.BasicPublish(exchange: "",37                              routingKey: "rpc_queue",38                              basicProperties: props,39                              body: messageBytes);40 41         while(true)42         {43             var ea = (BasicDeliverEventArgs)consumer.Queue.Dequeue();44             if(ea.BasicProperties.CorrelationId == corrId)45             {46                 return Encoding.UTF8.GetString(ea.Body);47             }48         }49     }50 51     public void Close()52     {53         connection.Close();54     }55 }56 57 class RPC58 {59     public static void Main()60     {61         var rpcClient = new RPCClient();62 63         Console.WriteLine(" [x] Requesting fib(30)");64         var response = rpcClient.Call("30");65         Console.WriteLine(" [.] Got '{0}'", response);66 67         rpcClient.Close();68     }69 }

客户端代码稍微复杂一些：

     我们建立一个连接和通道，并为回覆声明一个独占的'回调'队列。

     我们订阅'回调'队列，这样我们可以收到RPC响应。

     我们的调用方法使得实际的RPC请求。

     在这里，我们首先生成一个唯一的correlationId数字并保存它 - while循环将使用此值来捕获适当的响应。

     接下来，我们发布请求消息，此请求消息具有两个属性：replyTo和correlationId。

     在这一点上，我们可以坐下来等待适当的响应到达。

     while循环正在做一个非常简单的工作，对于每个响应消息，它检查correlationId是否是我们正在寻找的。 如果是这样，它会保存响应。

     最后，我们将响应返回给用户。

让客户端发送请求：

var rpcClient = new RPCClient();Console.WriteLine(" [x] Requesting fib(30)");var response = rpcClient.Call("30");Console.WriteLine(" [.] Got '{0}'", response);rpcClient.Close();

现在是看看我们的和的完整示例源代码（包括基本异常处理）的好时机。

照常设置（）：

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

cd RPCServerdotnet run# => [x] Awaiting RPC requests

要请求运行客户端的fibonacci号码：

cd RPCClientdotnet run# => [x] Requesting fib(30)

这里提出的设计不是RPC服务的唯一可能的实现，而是具有一些重要的优点：

     如果RPC服务器太慢，可以通过运行另一个RPC服务器进行扩展。 尝试在新的控制台中运行第二个RPCServer。

     在客户端，RPC需要发送和接收一条消息。 不需要像queueDeclare这样的同步调用。 因此，RPC客户端只需要一个网络往返单个RPC请求。

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

     如果没有服务器运行，客户端应该如何反应？

     客户端是否需要RPC的某种超时时间？

     如果服务器发生故障并引发异常，应该将其转发给客户端？

     在处理之前防止无效的传入消息（例如检查边界，类型）。

好了，这个系列也快结束了。

在把原地址贴出来，让大家了解更多。地址如下：