RabbitMQ系列教程之六:远程过程调用(RPC)
Posted 程序人家
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了RabbitMQ系列教程之六:远程过程调用(RPC)相关的知识,希望对你有一定的参考价值。
远程过程调用(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服务器RPCServer.cs的代码如下所示:
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 try 32 { 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 finally 44 { 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\'s 62 /// 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客户端的代码RPCClient.cs:
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 RPCClient 10 { 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 RPC 58 { 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();
现在是看看我们的RPCClient.cs和RPCServer.cs的完整示例源代码(包括基本异常处理)的好时机。
照常设置(参见教程一):
我们的RPC服务现在已经准备好了。 我们可以启动服务器:
cd RPCServer
dotnet run
# => [x] Awaiting RPC requests
要请求运行客户端的fibonacci号码:
cd RPCClient dotnet run # => [x] Requesting fib(30)
这里提出的设计不是RPC服务的唯一可能的实现,而是具有一些重要的优点:
如果RPC服务器太慢,可以通过运行另一个RPC服务器进行扩展。 尝试在新的控制台中运行第二个RPCServer。
在客户端,RPC需要发送和接收一条消息。 不需要像queueDeclare这样的同步调用。 因此,RPC客户端只需要一个网络往返单个RPC请求。
我们的代码仍然非常简单,没有尝试解决更复杂(但重要的)问题,例如:
如果没有服务器运行,客户端应该如何反应?
客户端是否需要RPC的某种超时时间?
如果服务器发生故障并引发异常,应该将其转发给客户端?
在处理之前防止无效的传入消息(例如检查边界,类型)。
好了,这个系列也快结束了。
在把原地址贴出来,让大家了解更多。地址如下:http://www.rabbitmq.com/tutorials/tutorial-six-dotnet.html
以上是关于RabbitMQ系列教程之六:远程过程调用(RPC)的主要内容,如果未能解决你的问题,请参考以下文章