消息服务MNS和消息队列ONS产品对比
MNS已经进过严格测试，已达到商业化的稳定性要求，其主要特点和适用场景
1.数据高可靠（10个9），对于数据可靠性敏感（要求消息数据不丢）的应用场景建议选择。
2.所有API符合HTTP RESTFUL 标准，方便接入，对于由于有不同网络安全域之间数据交换要求的场景建议选择，只需要http80端口开放就可以（一般默认开放），不需要开放额外端口。
3.后端存储采用阿里云自主研发的飞天分布式系统（已广泛应用于阿里云各个云产品），单集群规模已达到5k台，消息堆积无上限，对于消息堆积有上亿级别要求的用户场景，建议选择。
4.由于使用HTTP Restful 接口，SDK客户端无状态，不会占用用户服务器过多CPU 资源。对于用户服务器CPU 占用有要求的场景建议选择。
5.保证用户消息至少被消费一次语义。对于消息处理有此类要求的场景建议选择。
6.保证消息写高可用（always writable）。对于写消息可用性要求较高的用户建议选择。
7.MNS API 已全部支持RAM主子账号访问，方便企业按账号角色对MNS访问权限进行管理。
历史
LinkedIn在发达后，急需一个消息系统，他们的业务主要基于JAVA，在考查了JMS等等后，认为现有的不能满足他们的要求，于是发展了自己的MQ系统，特点是大量利用了当时飞速发展的hadoop系统中的zookeeper，
2011年，LinkedIn将他们的MQ开源，命名为Kafka
在2012年淘宝的双11压力，促使淘宝也开发自己的MQ系统，但淘宝的业务和LinkedIn并不太相似，所以淘宝借用了Kafka的zookeeper思想，自己实现了自己的MQ，淘宝也将其开源，命名为metaQ，这大约发生淘宝在metaQ上发展了数年，一直发展到3.0版本，时间到了2014年，改名为RocketMQ，阿里云上线后，基于RocketMQ部署的就是ONS。
但RocketMQ是云时代之前的产物，云时代的阿里云基于飞天系统，天生的大规模计算能力
2014年，新的基于飞天系统开发的新的MQ系统，MQS
2015年，重新命名为 MNS
结论
如果你只想使用MQ，并且不打算迁移到别的平台，那么推荐使用MNS，它是新开发的系统，无论性能还是稳定性，都远超ONS
但你有时想要自己部署一套自己的MQ,或者以后有可能迁移到非阿里云的环境，那么使用ONS，你可以自己部署一套RocketMQ来平稳过渡
参考
