4.1消息队列服务
message 消息队列的管理机制
消息队列的管理机制1. 概述消息队列是一种常用的异步通信机制，通过将消息发送到队列中，实现不同组件之间的解耦和通信。
消息队列的管理机制是指在使用消息队列时，对消息进行管理的相关策略和规则。
2. 消息队列的组成消息队列通常由以下几个组件组成：1.消息生产者：负责产生消息并发送到队列中。
2.消息队列：负责存储消息，并提供操作接口供消息生产者和消息消费者使用。
3.消息消费者：负责从队列中获取消息并进行处理。
3. 消息队列的管理策略为了保证消息队列的高效运行和可靠性，需要制定一些管理策略。
以下是常用的消息队列管理策略：3.1 消息持久化消息持久化是指将消息存储到持久化存储介质中，以便在消息队列故障或重启后能够恢复消息。
常用的持久化方式包括将消息存储到数据库、文件系统或分布式存储中。
3.2 消息确认机制消息确认机制是指在消息被消费者处理后，向消息队列发送确认消息，以通知消息队列该消息已被成功处理。
消息队列收到确认消息后将删除该消息，确保消息仅被处理一次。
常用的消息确认机制有手动确认和自动确认两种方式。
3.3 消息重试机制消息重试机制是指在消息消费失败时，对消息进行重试。
重试策略可以根据消息的重要程度和失败原因来灵活设置，以保证消息的可靠性。
3.4 消息顺序性有些场景下，消息的顺序性非常重要。
消息队列可以通过按照消息的顺序进行存储和消费来保证消息的顺序性。
常用的实现方式有单线程消费和消息分区两种方式。
4. 消息队列的性能优化为了提高消息队列的性能，可以采取以下优化策略：4.1 批量处理消息批量处理消息是指一次性处理多个消息，减少网络开销和系统调用次数，提高系统的吞吐量。
通过调整批量处理大小，可以在吞吐量和延迟之间进行权衡。
4.2 异步处理消息异步处理消息是指在消息消费时采用异步的方式进行处理。
使用多线程或线程池等技术，可以提高消息处理的并发性和响应性。
4.3 分布式部署对于大规模的消息队列系统，可以将消息队列进行分布式部署，以提高系统的容量和可用性。
cloud alibaba 项目服务之间调用的方式
在阿里云的云计算平台中，项目服务之间的调用可以通过多种方式实现。以下是一些常见 的方式：
1. HTTP/HTTPS调用： 使用HTTP或HTTPS协议进行服务之间的通信。可以通过发送HTTP请求来调用其他服
务的API接口，获取返回结果。这是一种常见且简单易用的方式，适用于大多数场景。
发送到消息队列，其他服务可以订阅并接收这些消息，实现解耦和异步处理。
4. 服务网关： 使用API网关（如阿里云的API网关）作为服务之间的中间层，对外提供统一的API接口
。其他服务可以通过调用API网关来访问需要的服务，API网关可以进行请求转发、鉴权、限 流服务之间调用的方式
2. RPC调用： 使用远程过程调用（RPC）协议进行服务之间的通信。RPC框架可以提供更高效、更灵
活的服务调用方式，支持多种编程语言和传输协议。阿里云提供了Dubbo、gRPC等RPC框 架，可用于实现服务之间的远程调用。
cloud alibaba 项目服务之间调用的方式
3. 消息队列： 使用消息队列服务（如阿里云的消息队列RocketMQ）进行异步通信。服务可以将消息
5. 服务注册与发现： 使用服务注册与发现中心（如阿里云的服务注册中心Nacos）进行服务的注册和发现。
服务在启动时将自身注册到服务注册中心，其他服务可以通过查询服务注册中心来获取可用 的服务地址，实现服务之间的动态调用。
以上只是一些常见的方式，具体的选择取决于项目的需求和架构设计。在阿里云平台上， 可以根据具体的场景和业务需求选择适合的服务调用方式。
面向服务架构的微服务治理体系结构
面向服务架构的微服务治理体系结构一、面向服务架构与微服务概述面向服务架构（Service-Oriented Architecture，SOA）是一种设计模式，它将应用程序的不同功能模块化成的服务，这些服务可以被不同的客户端通过定义良好的接口和协议进行调用。
微服务（Microservices）是一种将应用程序作为一套小服务的设计方法，每个服务运行在其的进程中，并通常围绕特定业务能力进行构建，可以地进行部署、扩展和更新。
1.1 面向服务架构的核心概念面向服务架构的核心概念包括服务的发现、组合、编排和治理。
服务发现允许客户端找到可用的服务；服务组合是将多个服务组合成新的服务；服务编排则是定义服务之间的调用顺序和逻辑；服务治理则是确保服务的质量和性能。
1.2 微服务架构的特点微服务架构具有以下特点：去中心化治理、分布式数据管理、业务能力驱动、技术多样性、部署和扩展、持续交付和自动化运维。
二、微服务治理体系结构的设计原则微服务治理体系结构的设计原则是确保微服务架构的可维护性、可扩展性和可靠性。
这些原则包括服务的标准化、服务的发现与注册、服务的配置管理、服务的监控与日志、服务的安全性、服务的容错与弹性设计。
2.1 服务的标准化服务的标准化是确保服务之间能够无缝交互的基础。
它涉及到定义统一的服务接口规范、数据格式和通信协议。
2.2 服务的发现与注册服务发现机制允许服务消费者在运行时发现服务提供者。
服务注册中心是服务发现的关键组件，它维护着服务实例的列表和状态。
2.3 服务的配置管理服务配置管理是集中管理服务配置信息的过程，包括环境配置、服务依赖和参数设置等。
2.4 服务的监控与日志服务监控提供了对服务运行状态的实时洞察，而日志记录则为问题诊断和性能分析提供了必要的信息。
2.5 服务的安全性服务的安全性涉及到认证、授权、数据加密和安全通信等方面，确保服务交互的安全性。
2.6 服务的容错与弹性设计服务的容错与弹性设计确保了服务在面对异常和故障时能够保持稳定运行，包括服务降级、熔断和自动恢复等机制。
酒店预订系统操作与管理作业指导书
酒店预订系统操作与管理作业指导书第1章酒店预订系统概述 (3)1.1 酒店预订系统简介 (4)1.2 酒店预订系统的发展历程 (4)1.3 酒店预订系统的重要性 (4)第2章酒店预订系统架构 (5)2.1 系统架构设计 (5)2.2 系统功能模块划分 (5)2.3 技术选型与平台搭建 (5)第3章酒店信息管理 (6)3.1 酒店基本信息管理 (6)3.1.1 酒店名称与标识 (6)3.1.2 酒店地址与联系方式 (6)3.1.3 酒店简介 (6)3.1.4 星级与价格 (6)3.2 酒店设施信息管理 (6)3.2.1 房间设施 (6)3.2.2 公共区域设施 (6)3.2.3 酒店服务 (7)3.3 酒店政策信息管理 (7)3.3.1 预订政策 (7)3.3.2 入住与退房政策 (7)3.3.3 付款政策 (7)3.3.4 儿童与宠物政策 (7)3.3.5 禁烟政策 (7)3.3.6 其他政策 (7)第4章客房信息管理 (7)4.1 客房类型管理 (7)4.1.1 添加客房类型 (7)4.1.2 修改客房类型 (8)4.1.3 删除客房类型 (8)4.2 客房价格管理 (8)4.2.1 设置客房价格 (8)4.2.2 修改客房价格 (8)4.2.3 删除客房价格 (8)4.3 客房状态管理 (9)4.3.1 更改客房状态 (9)4.3.2 查询客房状态 (9)4.3.3 客房状态预警 (9)第5章预订管理 (9)5.1 客户预订流程 (9)5.1.1 查询空房 (9)5.1.3 填写客户信息 (9)5.1.4 确认预订 (9)5.1.5 支付定金 (9)5.1.6 预订成功 (10)5.2 预订信息录入与修改 (10)5.2.1 录入预订信息 (10)5.2.2 修改预订信息 (10)5.2.3 修改权限管理 (10)5.3 预订状态跟踪 (10)5.3.1 实时更新预订状态 (10)5.3.2 预订状态查询 (10)5.3.3 预订提醒功能 (10)5.3.4 预订异常处理 (10)第6章入住与离店管理 (10)6.1 入住流程管理 (10)6.1.1 客人到达接待台 (10)6.1.2 预订信息核对 (10)6.1.3 客人身份验证 (11)6.1.4 办理入住手续 (11)6.1.5 发放房卡 (11)6.1.6 客人满意度调查 (11)6.2 离店流程管理 (11)6.2.1 客人退房 (11)6.2.2 行李寄存 (11)6.2.3 结算房费 (11)6.2.4 收集意见 (11)6.2.5 送别客人 (11)6.3 跨夜房费计算 (12)6.3.1 跨夜房费计算规则 (12)6.3.2 跨夜房费计算方法 (12)6.3.3 跨夜房费优惠政策 (12)第7章账务管理 (12)7.1 账单与打印 (12)7.1.1 账单 (12)7.1.2 账单打印 (12)7.2 费用结算 (12)7.2.1 结算方式 (12)7.2.2 结算流程 (13)7.3 信用额度与预授权管理 (13)7.3.1 信用额度管理 (13)7.3.2 预授权管理 (13)第8章客户服务与关系管理 (13)8.1 客户信息管理 (13)8.1.2 客户信息存储与更新 (13)8.1.3 客户信息利用 (13)8.2 客户投诉处理 (14)8.2.1 投诉接收 (14)8.2.2 投诉分类与评估 (14)8.2.3 投诉处理 (14)8.2.4 投诉跟踪与回访 (14)8.3 客户满意度调查与分析 (14)8.3.1 调查方法 (14)8.3.2 调查内容 (14)8.3.3 数据分析 (14)8.3.4 改进措施 (14)第9章系统安全管理 (14)9.1 数据安全保护 (14)9.1.1 数据备份 (14)9.1.2 数据加密 (15)9.1.3 防止数据泄露 (15)9.2 用户权限管理 (15)9.2.1 用户角色划分 (15)9.2.2 权限分配 (15)9.2.3 权限审计 (15)9.3 系统日志与审计 (15)9.3.1 系统日志记录 (15)9.3.2 审计分析 (15)9.3.3 日志存储与保护 (15)第10章系统维护与优化 (15)10.1 系统备份与恢复 (16)10.1.1 备份策略 (16)10.1.2 备份操作流程 (16)10.1.3 恢复操作流程 (16)10.2 系统功能监控 (16)10.2.1 功能指标 (16)10.2.2 监控工具与方法 (16)10.2.3 功能分析 (16)10.3 系统升级与迭代建议 (16)10.3.1 系统升级策略 (16)10.3.2 系统迭代建议 (16)10.3.3 升级与迭代实施 (16)第1章酒店预订系统概述1.1 酒店预订系统简介酒店预订系统是一种基于计算机技术和网络通信技术的服务系统，旨在为用户提供便捷、高效的酒店预订服务。
消息队列介绍及原理
消息队列介绍及原理消息队列（Message Queue）是一种进程间通信的方式，通过消息的方式进行数据传输和交互。
它将消息按照一定的顺序存放在队列中，接收方可以按照一定的规则从队列中取出消息进行处理。
消息队列常用于分布式系统或异步处理的场景中，它能够实现异步解耦、削峰填谷、异步处理等功能。
同时，消息队列还具有高可用、可靠性强等特点，使得它成为了当前分布式系统中不可或缺的重要组件。
下面将介绍消息队列的原理及其基本特点。
一、消息队列的基本原理消息队列的基本原理可以归纳为三个关键组成部分：生产者、队列和消费者。
1. 生产者（Producer）：消息的生产者负责将需要传递的消息发送到队列中。
生产者只负责把消息发送到队列，不需要知道消息被谁接收。
2. 队列（Queue）：消息队列是消息传递的媒介，它负责存储所有发送过来的消息。
消息队列通常是基于先进先出（FIFO）原则进行消息的存储和处理。
3. 消费者（Consumer）：消费者从队列中获取消息并进行处理。
消费者需要从消息队列中主动获取消息，因此消费者和队列之间是解耦的。
消息队列的基本原理可以表示为：生产者将消息发送到队列，消费者从队列中获取消息进行处理。
生产者和消费者之间通过消息队列实现了解耦，生产者和消费者之间并不直接通信。
二、消息队列的基本特点消息队列具有以下的基本特点，使得它成为了一种重要的分布式系统通信方式。
1.异步解耦：生产者和消费者之间通过消息队列进行通信，生产者发送消息后即可继续其他逻辑处理，而不需要等待消费者的处理结果。
这样能够实现异步解耦，提高系统的响应速度和吞吐量。
2.削峰填谷：队列作为中间媒介，能够将消息暂时存储起来。
当消费者无法及时处理消息时，消息可以在队列中排队等待处理。
这样能够避免突发流量对系统的影响，平滑处理请求，达到平均请求速率。
3.可靠性：消息队列通常具备持久化机制，可以确保消息不会丢失。
即使在生产者发送消息后，但在消费者接收消息之前，如果发生系统故障，消息也不会丢失。
消息队列的使用方式流程 (2)
消息队列的使用方式流程1. 消息队列介绍消息队列（Message Queue）是一种在应用程序之间传递消息的软件组件。
它将消息发送到队列中，然后接收者从队列中接收消息，实现了不同应用程序之间的异步通信。
2. 消息队列的优势•异步通信：发送者可以将消息发送到队列中，然后继续执行其他任务，而不需要等待接收者的响应。
•解耦应用程序：消息队列将发送者和接收者解耦，使得它们可以独立开发和部署。
•峰值处理能力：如果接收者无法处理大量的请求，消息队列可以存储在队列中，等待接收者的处理。
•可靠性：消息队列通常具备消息持久化和消息重试等功能，可以确保消息被可靠地投递和处理。
3. 消息队列的使用方式流程消息队列的使用方式流程包括以下几个步骤：3.1. 定义消息格式在使用消息队列之前，需要定义消息的格式。
消息格式应包括必要的字段，以便发送者和接收者可以正确地处理消息。
3.2. 创建消息队列在使用消息队列之前，需要创建消息队列。
消息队列可以基于不同的技术来实现，比如RabbitMQ、Kafka等。
根据具体需求选择适合的消息队列产品。
3.3. 发送消息发送者通过消息队列将消息发送到队列中。
发送消息时，需要指定目标队列和消息内容。
发送者可以选择同步或异步方式发送消息。
3.4. 接收消息接收者从消息队列中接收消息。
接收消息时，需要指定源队列，并从队列中获取消息内容。
接收者可以选择阻塞或非阻塞方式接收消息。
3.5. 处理消息接收者根据消息的内容进行相应的处理。
处理方式可以是计算、存储、发送回复等。
3.6. 确认消息接收者在处理完消息后，需要向消息队列发送确认消息，以便消息队列可以删除已处理的消息。
3.7. 监控和管理使用消息队列时，可以监控和管理队列的状态和性能。
可以通过监控工具实时查看消息队列的吞吐量、延迟、未处理消息数等指标。
4. 总结消息队列是一种实现应用程序之间异步通信的重要组件。
通过使用消息队列，可以实现解耦应用程序、提高系统的可靠性和扩展性。
C#消息队列之RabbitMQ进阶篇
C#消息队列之RabbitMQ进阶篇Ø简介在之前的中介绍了 RabbitMQ 的基本⽤法，其实要更全⾯的掌握 RabbitMQ 这个消息队列服务，我们还需要掌握以下内容：1.轮询分发2.消息响应3.公平分发4.消息持久化1)轮询分发轮询分发。
话平均的，这种分发⽅式称之为轮询分发默认情况下，Ra b b it M Q 会按照消息的顺序依次分发给每个消费者顺序依次分发给每个消费者，也就是每个消费者接收到的消息基本是平均的不多说看⽰例：1)⽣产者代码（其他代码省略）//随机⼀个“⽣产者”名称string pname = $"[P{(new Random()).Next(1, 1000)}]";Console.WriteLine($"⽣产者{pname}已启动：");for (int i = 0; i < 6; i++){string message;if (i == 1) //第⼆条消息，需要耗时10秒message = $"{pname}, task{i + 1}, time of 10 seconds";elsemessage = $"{pname}, task{i + 1}, time of 1 seconds";byte[] body = Encoding.UTF8.GetBytes(message);channel.BasicPublish("", "myQueue1", properties, body);Console.WriteLine($"⽣产者{message}\t{DateTime.Now.ToString("HH:mm:ss fff")}");}2)消费者代码（其他代码省略）//随机⼀个“消费者”名称string cname = $"[C{(new Random()).Next(1, 1000)}]";Console.WriteLine($"消费者{cname}已开启");consumer.Received += (sender, e) =>{byte[] body = e.Body; //消息字节数组string message = Encoding.UTF8.GetString(body); //消息内容Console.WriteLine($"消费者{cname}接收到消息：{message}\t{DateTime.Now.ToString("HH:mm:ss fff")}，开始处理...");//模拟处理耗时操作string second = Regex.Replace(message, ".+time of ", "");second = Regex.Replace(second, " seconds", "");System.Threading.Thread.Sleep(1000 * int.Parse(second));};3)运⾏代码⾸先，开启两个消费者，再打开⼀个⽣产者发送6条消息，运⾏结果如下：从以上结果中可以得出以下结论：1.⼀共6条消息，2个消费者接收的消息数量是⼀致的（各3条）；2.尽管 Task2 消息处理时间较长，也会等待该消息处理完成之后，再处理被依次分发的消息，所以导致了 Task4 的处理时间在 Task5 之后；3.同⼀时间段⼀个消费者只会处理⼀条消息，只有当该消息处理完成之后，才会处理下⼀条消息（或者说接收下⼀条消息），并不会同时处理多条消息。
消息队列的使用方式流程
消息队列的使用方式流程引言消息队列是一种常用的进程间通信方式，可以实现应用程序之间的解耦、异步处理等功能。
本文将介绍消息队列的使用方式流程。
第一步：选择消息队列系统在开始使用消息队列之前，首先需要选择一种合适的消息队列系统。
常见的消息队列系统有 RabbitMQ、Apache Kafka、ActiveMQ 等。
根据实际需要，选择适合自身项目的消息队列系统。
第二步：安装和配置消息队列系统安装和配置消息队列系统需要根据选择的具体系统进行操作。
大部分消息队列系统都提供官方文档，按照文档的指导进行安装和配置。
第三步：定义消息队列和队列属性在消息队列系统中，需要定义具体的队列和队列的属性。
队列是存储消息的缓冲区，而队列的属性可以控制消息的优先级、持久性等。
根据实际需求，定义队列和队列的属性。
第四步：发送消息到队列在实际应用中，通常会有消息的发送方和接收方。
发送方将消息发送到队列中，接收方从队列中获取消息进行处理。
在发送消息时，需要指定消息的内容、目标队列等。
具体的消息发送代码会依据所使用的消息队列系统而有所不同。
以下是发送消息到队列的示例代码片段： - 发送方代码片段1： ```python # 创建消息队列连接 connection = get_mq_connection()# 创建消息通道channel = connection.create_channel()# 声明队列channel.queue_declare(queue='my_queue')# 发送消息channel.basic_publish(exchange='',routing_key='my_queue',body='Hello World!')# 关闭连接connection.close()```第五步：接收队列中的消息接收方需要从队列中获取消息并进行处理。
消息队列系统通常提供了监听队列的方式，当队列中有新的消息时会触发相应的回调函数。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
通过认证服务的学习，我们可以以不同的身份访问企业云平台，可以通过研发部的账户登录研发部，可以通过业务部访问业务部的资源，也可以通过IT 工程部的身份登录查看整个系统的运行状况；下面我们继续学习消息服务（RabbitMQ ）、镜像服务（Glance ）和计算控制服务（Nova ），了解这3个组件是如何为平台的正常运行提供支撑的。
了解RabbitMQ 、Glance 和Nova 的基本概念。
理解3种服务的服务流程和工作机制。
掌握3种服务的基本操作及常见运维。
消息队列服务
在日常的工作生活中，消息传递是一个必不可少的需求。
在大型软件的内部信息交换和外部信息传递中，消息传递都是不可或缺的。
在系统间通信窗体的最基本方法是socket ，但是这是一个最底层的协议，所以在使用时需要程序来调用。
在进行后序的学习过程之前，小李首先要了解消息服务的基本状况和使用的情景，以及OpenStack 的RPC （远程呼叫机制）的运行机制。
1．消息队列
AMQP 是一种标准化的消息中间件协议，全称为高级消息队列协议（advanced message queuing protocol ）。
可以让不同语言、不同系统的应用互相通信，并提供一个简单统一的模型和编程接口。
这样，就可以采用各种语言和平台来实现自身的应用，当需要和其他系统通信时，只要承认AMQP 协议即可。
2．Rabbitmq 消息服务
RabbitMQ 是一个基于AMQP 协议的高级消息中间件，它主要的技术特点是可用性，
学习目标 项目 基础控制服务 四
OpenStack 云计算基础架构平台技术与应用
52
提示
available ）高可用性集群。
1．了解消息队列AMQP
消息队列AMQP 服务架构，如图4-1所示。
AMQP 中有3个重要的角色，如图4-2所
示。
Publisher ：消息的发出者。
Exchange ：消息的传递者。
Consumer ：消息的接收者。
用户可以模拟写信作为其工作的方式来说
明。
为了传递给收件人，首先需要用信封把信
的内容装起来，然后在信封上写好收件人的信
息，再把信放到邮筒里；后面邮局会拿到信然
后根据信封上的收件人信息来看最终把信给
谁。
写信的人就是那个Publisher ，邮局就是
Exchange ，收件人就是Consumer 。
不同的Consumer 会创建不同的Queue （消息队列），然后将对应的Exchange 绑定到Queue 上。
在消息的传递过程中，Publisher 不会直接的把Message 放到Queue 中，也不管Message 如何分发。
Publisher 只管准备好消息，然后交给
Exchange ，而Exchange 做的事情也很简单，一手从Publisher 拿到消息，然后就把消息放入Queue 中。
对于Exchange ，是放到某一个Queue 中，还是放到多个Queue ？实际上，在Publisher 发出消息的时候会附加一个条件，Exchange 会根据这个条件来决定发送的方法，这个条件就是
routingkey 。
图4-2 AMQP 消息传递示意图 2．了解Rabbitmq 消息服务
Rabbitmq 架构图，如图4-3所示。
通过上面这张应用相结合的结构图既能够清晰的看清楚整体的send Message 到 图4-1 AMQP 架构图
项目四基础控制服务Receive Message的一个大致的流程。
图4-3 RabbitMQ架构图
首先Rabbitmq有如下几种命令行工具。
①rabbitmqctl：用来管理RabbitMQ中间件的命令行工具.它通过连接中间件节点来执
行所有操作。
②rabbitmq-plugins：rabbitmq-plugins 是管理RabbitMQ broker插件的命令行。
3．OpenStack的消息服务
OpenStack采用AMQP作为它的消息传递技术。
AMQP的控制端（Broker），不管是RabbitMQ或者Qpid，它的作用是允许任何两个相同组件以松散耦合的方式进行交流。
更准确地说，OpenStack的组件均可以使用远程呼叫机制（RPC）进行彼此沟通。
然而，这种范式是建立在“publish/subscribe模式”（订阅/发布模式，订阅发布模式定义了一种一对多的依赖关系，让多个订阅者对象同时监听某一个主题对象。
这个主题对象在自身状态变化时，会通知所有订阅者对象，使它们能够自动更新自己的状态）。
如图4-4所示。
这样做的好处如下。
（1）客户端和服务端之间的解耦（如客户端不需要知道服务引用）。
（2）客户机和服务之间不需要同时使用消息调用，只需要其中一端发送消息调用指令。
（3）随机平衡的远程调用会随机将运行的指令发送到一个节点。
53
OpenStack云计算基础架构平台技术与应用
54
图4-4 OpenStack中的消息服务
下面以计算服务Nova为例，讲解OpenStack组件使用消息服务的原理和机制。
Nova
中的每个组件都会连接消息服务器，一个组件可能是一个消息发送者（如API、Scheduler），也可能是一个消息接收者（如compute、volume、network）。
发送消息有2种方式：同步调用rpc.call和异步调用rpc.cast。
Nova实现了RPC（包括请求+响应的rpc.call和只有请求的rpc.cast），Nova通过AMQP提供一个代理类，这个类提供了函数调用的消息数据编码和数据解码，每个Nova服务（如计算）在初始化时创建两个队列，一个接受消息路由的关键节点类型产生对应的节点编号”（例如compute.hostname），另一个接受消息路由键返回的节点类型编号生成通用的“节点类型”（例如计算）。
前者是专门用来当Nova-API需要重定向命令像terminate（终止）一个实例的在特定的节点，在这种情况下，只有主机的计算节点的虚拟机监控程才能杀死序正在运行的虚拟机实例。
API作为消费者当RPC调用请求/响应，否则只是充当发布，如图4-5所示。
4．Nova RPC映射
当一个实例在OpenStack云部署和共享，每个组件在Nova连接到messagebroker，根据其个性，如计算节点或网络节点，可以使用队列作为调用者（如API或调度器）或一个运行组件（如计算或网络）。
调用器和组件不实际存在于Nova对象模型，但是在这个例
项目四基础控制服务
子中使用它们作为一个抽象对象。
一个调用程序是一个组件，使用rpc发送消息队列系统，接收消息的队列系统，并相应地回复rpc调用操作，如图4-6所示。
图4-5 Nova消息传递
图4-6 OpenStack rpc调用机制
下面介绍几个OpenStack在消息传递过程中常用的对象。
（1）Topic Publisher：该对象在进行rpc.call或rpc.cast调用时创建，每个对象都会连接同一个topic类型的交换器，消息发送完毕后对象被回收。
（2）Direct Publisher：该对象在进行rpc.call调用时创建，用于向消息发送者返回响应。
该对象会根据接收到的消息属性连接一个direct类型的交换器。
55
OpenStack云计算基础架构平台技术与应用
56 （3）Direct Consumer：该对象在进行rpc.call调用时创建，用于接收响应消息。
每一个
对象都会通过一个队列连接一个direct类型的交换器（队列和交换器以UUID命名）。
（4）Topic Consumer：该对象在内部服务初始化时创建，在服务过程中一直存在。
用于从队列中接收消息，调用消息属性中指定的函数。
该对象通过一个共享队列或一个私有队列连接一个topic类型的交换器。
每一个内部服务都有两个topic consumer，一个用于rpc.cast 调用（此时连接的是binding-key为“topic”的共享队列）。
另一个用于rpc.call调用（此时连接的是binding-key为“topic.host”的私有队列）
（5）Topic Exchange：topic类型交换器，每一个消息代理节点只有一个topic类型的交换器。
（6）Direct Exchange：direct类型的交换器，存在于rpc.call调用过程中，对于每一个rpc.call的调用，都会产生该对象的一个实例。
（7）Queue Element：消息队列。
可以共享也可以私有。
routing-key为“topic”的队列会在相同类型的服务中共享（如多个compute节点共享一个routing-key为“topic”的队列）。