[OpenStack Icehouse] 消息处理架构Oslo/Messaging

最新推荐文章于 2023-12-18 17:24:10 发布

五个字

最新推荐文章于 2023-12-18 17:24:10 发布

阅读量8.8k

点赞数

分类专栏： Oslo 文章标签： rpc openstack Oslo.Messaging 消息队列

本文链接：https://blog.csdn.net/juvxiao/article/details/23532617

版权

本文介绍了OpenStack Icehouse版本中，Oslo/Messaging作为消息处理架构的使用，包括基本概念如Server、Client、Exchange、Topic等。重点讲述了在OpenStack中的三个使用场景：随机选择、特定Server处理和广播式调用。同时提到了Transport（如RabbitMQ、Qpid、ZeroMQ）的角色和Target的概念，以及Server端的MessageHandlingServer和Client端的RPCClient的工作原理。

摘要由CSDN通过智能技术生成

在Icehouse中, rpc消息队列相关处理从openstack.common.rpc慢慢的都转移到oslo.messaging上, 现在仅有几个项目没有转移, 将来也会转, 这个架构更合理, 代码结构清晰, 且弱耦合.

本文章主要针对rpc， notify基本没涉及, 有时间总结总结.

基本概念

Server: 为各个Client提供RPC接口,它是消息的最终处理者;
Client: RPC接口的调用端, 我们常见的cast和call方法就是在这端调用;
Exchange: 理解为一个消息交换机，把消息分类，告诉何种路由到何种queue;
Topic: 是一个RPC消息的唯一标识; servers监听这个topic的消息; client负责发出这个topic的消息;
Namespace: servers可以在一个topic上，提供多种方法集合，这些方法集合通过namespace来分开管理;
Method: 这个慨念很简单，就是函数, 即远程方法调用中的方法;
API version: 也就是server上提供的RPC api接口集合的版本号，openstack中1.0起步, servers可以一次提供多种api version，client每次请求时只需描述它所需要的最低version就ok;
Transport: 可以理解为传输载体，这个很好理解, 就是我们使用的消息队列中间件RabbitMQ, Qpid, ZeroMQ等等, 是负责整个消息处理的系统，它负责消息传输直到提供给clients返回，使用此系统者，不用了解细节, Openstack中实现的主要有这三种， AMQP标准下的rabbitMQ和Qpid，和非AMQP的ZeroMQ， ZeroMQ更底层，速度更快, 据说快10倍。
Target这是个很重要的概念，它描述了信息的处理方式，该发哪里去(server属性)和消息处理端(server)监听什么信息(topic 属性)。以下是Target的属性