阿里云消息服务
发布时间:| 对比项 | 消息服务MNS | 消息队列MQ | 补充说明 |
|---|---|---|---|
| 别名 | MQS | ONS | |
| RESTful API 支持 | True | True | |
| 官方提供Node SDK | False | False | 均有私人提供Node SDK基于C++ SDK开发 |
| 稳定性 | MNS数据三重备份，有多层次的安全防护和防DDoS攻击机制，支持https/VPC访问。 | 一份消息多份落盘存储，经过严格断电测试，消息依然保证不丢失。海量消息堆积。 | |
| 可堆积 | 不限量堆积但是过量收费 | 单个Topic可堆积100亿+条消息，防止系统高流量崩溃，默认情况下消息落盘保留3天 | |
| 客户端消费流量 | MNS对用户不限制公网出口带宽，但是外网下行流量计费 | 没有下行流量费，公网环境仅供测试 | |
| 计费模式 | 请求次数费用 + 堆积消息费用 + 外网下行流量费用 | API调用费用+Topic资源占用费用 | |
| 可监控 | 提供Web控制台 | 提供Web控制台 | MQ控制台功能稍强 |
| 公网环境可用于生产 | True | False | MQ目前仅提供测试 |
| 目前量级消费预估 | 630元/月 | 585元/月 | 粗略计算，加入冗余 |
| 多协议支持 | 仅HTTP | http/tcp/mqtt | 跨语言支持均使用http |
| 消息模型 | 订阅、队列 | 订阅 | |
| Node SDK | ali-mns | aliyun-ons | |
| 文档友好 | 一般 | 一般 | |
| 线下接入速度 | 快 | 3~5分钟 | MQ在ECS响应时间0.16s |
| 业务场景 | 如果你需要有阿里云线上到线下的消息传输，那么MNS更适合你。 | 如果你需要在线上做消息传输，在阿里云内网环境里不同ECS主机之间交换消息，业务像是“中间件”,那么MQ更适合你。 | |
| 结论 | 适合涉及线下业务的需求 | 适合同区ECS内中间件业务的需求，消费端应该部署在ECS | MQ与MNS极为相似但其实不同，两款产品的产品定位就不太一样。 |
本文余下为调研期间的资料，可供参考
阿里云消息服务MNS（Message Service，原MQS）是阿里云商用的消息中间件服务。与传统的消息中间件不同，消息服务一开始就是基于阿里云自主研发的飞天分布式系统来设计和实现，具有大规模，高可靠、高并发访问和超强消息堆积能力的特点。消息服务API采用HTTP RESTful标准，接入方便，跨网络能力强；已全面接入资源访问控制服务（RAM）、专有网络（VPC），支持各种安全访问控制；接入云监控，提供完善的监控及报警机制。消息服务提供丰富的SDK、解决方案、最佳实践和7x24小时的技术支持，帮助应用开发者在应用组件之间自由地传递数据和构建松耦合、分布式、高可用系统。
阿里云消息服务确切的应该叫消息队列服务。阿里云消息服务是由阿里云提供的一种消息队列服务中间件. 淘宝网www.taobao.com本身也使用了这种技术。非阿里官方提供Node SDK ali-mns。
- 易用不失扩展性: 提供restful的访问接口，可以与阿里云生态圈结合使用。
- 支持普通、延时、优先级队列等多种队列模式
- 支持并发访问，生产者和消费并发访问同一队列
- 消息投递保障，确保消息至少被消费1次
- 支持通知消息：服务端主动将消息发送给用户指定的回调地址（Endpoint），消除用户端程序不必要的轮询和资源消耗
- 一条通知消息可以同时被多个订阅者订阅和消费
- 支持 http/https, 邮件，SMS，移动端等多种推送方式
- 在消息有效期内，保证发布到 Topic 中的消息会按照指定的策略和格式推送给用户程序
稳定性考量
MNS数据三重备份，官网承诺可靠性99.9999%，意为 MNS 上100亿条消息，每月最多只有1条消息发生数据丢失的可能性。 有多层次的安全防护和防DDoS攻击机制，支持https/VPC访问。 阿里云为付费用户的云服务提供7×24小时的运行维护，并以在线工单和电话报障等方式提供技术支持，具备完善的故障监控、自动告警、快速定位、快速恢复等一系列故障应急响应机制。
数据是否可以堆积
数据持久性按服务周期统计，一个服务周期为一个自然月，如不满一个月不计算为一个服务周期。 MNS 对用户队列数量不做限制，系统根据用户需求实时动态扩展资源；单个队列中积压的消息数量不得超过10亿条；单个队列的QPS上限为4000。
如果所有队列中的消息数量超过100万个，MNS 将对超出部分计费:
堆积消息费用计算公式如下： 堆积消息费用＝超出100万部分的消息总数 X 堆积消息单价(消息单价0.010元/百万条·小时)
客户端线下抽取问题
MNS对用户不限制公网出口带宽。阿里云采用BGP多线接入，保障用户的网络接入质量。
费用构成
总计费 = 请求次数费用 + 堆积消息费用 + 外网下行流量费用
- 请求次数费用：对所有API请求次数进行计费，目前有两种付费方式：按量付费、包年包月。
如果选择按量计费API调用 2元/百万次。 如果选择包年包月，按请求规模分段计费 1亿次包半年170。
每个用户每月有100万次请求的免费额度，包年包月优惠包另算。
- 欠费24时自动停止消息API访问。
可监控性
MNS日志管理功能非常强大，以分钟为单位记录日志，详细记录每条消息的各种属性。日志文件以json格式保存，可以自行下载。同事阿里云官方也提供了命令行下的日志分析工具。
消息队列（Message Queue，简称MQ）是阿里云商用的专业消息中间件，是企业级互联网架构的核心产品，基于高可用分布式集群技术，搭建了包括发布订阅、轨迹查询、资源统计、定时（延时）、监控报警等一套完整的消息云服务。MQ历史超过7年，帮您实现分布式计算场景中所有异步解耦功能，是阿里双11使用的核心产品。MQ由阿里巴巴集团中间件技术部自主研发，是原汁原味的阿里集团中间件技术精华之沉淀，是性价比最高、最可靠的企业级消息中间件产品。
消息队列就是传说的RocketMQ，相比阿里云消息服务似乎更适合流计算的应用场景。MQ发送消息支持TCP、HTTP、MQTT三种协议。其中http发送方式和目前埋点发送方式很相似。
MQ 是否可以在公网访问？
支持。MQ 专门开辟了公网专用集群，供用户测试使用，在MQ Console 创建 Topic 时， Region 请选择“公网测试”，此 Topic 即可通过公网访问，但可用性较低。 在生产环境部署，推荐使用 ECS 来收发消息。
数据是否可以堆积
数据保存 3 天，超过 3 天未消费的消息会被删除掉。如果您消费落后比较厉害， 会有报警短信通知，这时请您人工介入处理。 消息队列一份消息多份落盘存储，经过严格断电测试，消息依然保证不丢失。支持消息轨迹，消息从生产到消费轨迹，可清晰排查。海量消息堆积，单个Topic可堆积100亿+条消息，防止系统高流量崩溃。
数据总线
线上有一个稳定的数据总线才可，保证数据不会丢失及稳定 MNS 数据可以从线上抽取到线下（流量收费么？及成本） 数据可以堆积 MNS 数据可以回滚重发 数据可以监控 客户端线下抽取问题
消息服务价位预估
- MQ计费方式:
MQ总费用 = API调用费用+Topic资源占用费用(调用次数决定费用,越多越便宜) - MNS计费方式:
请求次数费用 + 堆积消息费用 + 外网下行流量费用
| 服务 | 日均消息数(3.5+3.3+httplogs全量) | 天 | 月 |
|---|---|---|---|
| 消息队列MQ | 950,0000 | X | 585元 |
| 消息服务MNS | 950,0000 | 21元 | 630元 |
| 服务 | 日均消息数(3.5+3.3+httplogs筛选后) | 天 | 月 |
|---|---|---|---|
| 消息队列MQ | 450,0000 | X | 315元 |
| 消息服务MNS | 450,0000 | 11元 | 330元 |
| 服务 | 日均消息数(仅3.5埋点) | 天 | 月 |
|---|---|---|---|
| 消息队列MQ | 350,0000 | X | 255元 |
| 消息服务MNS | 350,0000 | 9元 | 270元 |
- queue:
- 队列，发送，接收的概念。
- poll模式，用户需要自行轮询拉取消息。
- 一对一，如果启动多个消费端，那么他们共同分担消费消息，比如，1000条消息，消费端A消费300条，消费端B消费400条，消费端C消费300条。
- topic:
- 主题，发布，订阅的概念。
- push模式，用户需要在本地维护一个socket监听，一旦有消息，服务器会主动推送消息到监听端。
- 一对多，如果启动多个消费端，那么他们各自消费消息，比如，1000条消息，消费端A消费1000条，消费端B消费1000条，消费端C消费1000条。
MQ响应速度测试
| 测试环境 | 首次启动服务响应时间 | 消息生产响应时间 | 消息消费响应时间 |
|---|---|---|---|
| 公网测试 | 3min | N/A | N/A |
| 杭州ECS | 0.16s | N/A | N/A |
结论：MQ更适合线上ECS内做消费端，官方文档也多次强调在ECS做消息消费。
MNS响应速度测试
| 测试环境 | 首次启动服务响应时间 | 消息生产响应时间 | 消息消费响应时间 |
|---|---|---|---|
| 公网测试 | 3min | N/A | N/A |
| 杭州ECS | 0.16s | N/A | N/A |
结论：MQ更适合线上ECS内做消费端，官方文档也多次强调在ECS做消息消费。