一, 产品背景
消息队列是阿里巴巴集团自主研发的专业消息中间件. 产品基于高可用分布式集群技术, 提供消息订阅和发布, 消息轨迹查询, 定时 (延时) 消息, 资源统计, 监控报警等一系列消息云服务, 是企业级互联网架构的核心产品. MQ 目前提供 TCP ,MQTT 两种协议层面的接入方式, 支持 Java,C++ 以及 .NET 不同语言, 方便不同编程语言开发的应用快速接入 MQ 消息云服务. 用户可以将应用部署在阿里云 ECS, 企业自建云, 或者嵌入到移动端, 物联网设备中与 MQ 建立连接进行消息收发, 同时本地开发者也可以通过公网接入 MQ 服务进行消息收发.
从官方文档中看到 MQ 消息队列的产品为一个提供消息服务的中间件, 可以提供端到云的消息服务, 这个端的覆盖面包括了移动端和 IOT 物联网设备, 并且为了支持 IOT 的需要除 TCP 协议外提供了 MQTT 来支持物联网设备的消息服务, 在云上的支持不止包括阿里云, 可以支持用户将服务部署在企业自建云上. 作为 PAAS 层的服务支持用户通过 API 的方式将消息队列服务集成在自己的平台上, 目前在产品的结构上分成两部分, 移动端和物联网的消息队列服务单独作为一个子产品 MQ FOR IOT 提供服务, 这项服务和 MQ 主服务比主要的区别就是增加了对 MQTT 通讯协议的支持.
从编程语言来看, 因为 MQ FOR IOT 是面向移动端和物联网, 所以需要支持的编程语言更多, 包括 Android,iOS 和 PYTHON 环境在消息队列服务中都已经支持.
二, 消息队列 MQ 产品测试
开通服务进入控制台后看到菜单将消息队列服务清晰的分成两部分, 支持 MQTT 的微消息服务单独列出子菜单, 菜单选项按照功能分成三大部分, 生产管理类子菜单, 消息查询追踪类子菜单和监控报警类子菜单.
TOPIC 是消息队列服务中一个重要概念, 用于区分消息的不同类型, 比如在一次交易中, 用户对于商品所下的订单和支付的订单虽然针对的是同一件事情, 但是对于消息队列来说, 这两种消息的功能和类型有明显的不同, 可以用不同的 TOPIC 来区分, 在 TOPIC 下还有个标签 TAG 用于二级分类, 如一个用户对不同商品的购买订单可以作为不同的 TAG. 针对消息的配置来讲, 需要定义消息的名字和消息的类型. 在类型上普通消息, 事务消息, 定时消息, 分区消息等都可以将不同类型的 TOPIC 根据类型区分. 将 TOPIC 按什么类型进行分类及归入哪个分类需要用户根据实际情况进行确定.
除了 TOPIC 外, 对于一条消息, 还有三个独特的属性可以为查询提供方便, 生产者的编号 (PRODUCT ID), 消费者的编号(CONSUMER ID) 和消息编号(MESSAGE ID), 加上 TOPIC 的配置, 可以准确定义海量消息中的每一条, 方便查询和监控等功能的支持.
消息路由是指的在不同地域间的消息同步, 需要配置源地域和 TOPIC, 目标地域和 TOPIC, 从最新写入源的消息开始进行同步.
资源报表分成两个子项, 生产者和消费者, 可以对于消息的两个源头的情况进行查看, 如果需要对于消息服务的可以在监控报警设置中进行配置, 对于消息的报警项, 有两个重要指标堆积量和消息延迟, 分别从数量和时间对于消息服务的异常情况进行报警, 通过短信方式通知用户.
三, 微消息队列 MQ FOR IOT 产品测试
从微消息队列的按量付费的计费项目就可以看出物联网在消息通讯上的几个主要特征, 即时连接数, 订阅消息数和消息收发量. 万物互联后物联网设备的消息数在这三个维度都会到达海量的程度, 特别是即时连接这个特点和一般的 MQ 服务有很大不同, 可以代表物联网中消息传递的特征.
此外, 微消息队列服务对于消息的分类同一般 MQ 服务不同的是, 将 TOPIC 分成父 TOPIC 和子 TOPIC 的方式而不是 TOPIC 和 TAG 的分类方式, 子 TOPIC 从属于父 TOPIC, 这个特点我想也是因为需要支持物联网的关系, 因为传统下的消息都是针对应用比较多, 但是物联网情况下, 消息的类型如设备的状态, 工业监测数据等会比一般情况多的多, 并且消息服务的实时性要求更高, 所以将 TOPIC 设置成父子从属关系更有利于对海量不同类型的消息进行区分.
来源: https://yq.aliyun.com/articles/675069