消息服務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
但RocketMQ是雲時代之前的產物，雲時代的阿里雲基於飛天系統，天生的大規模計算能力
2014年，新的基於飛天系統開發的新的MQ系統，MQS
2015年，重新命名為 MNS
結論
如果你只想使用MQ，並且不打算遷移到別的平台，那么推薦使用MNS，它是新開發的系統，無論性能還是穩定性，都遠超ONS
但你有時想要自己部署一套自己的MQ,或者以后有可能遷移到非阿里雲的環境，那么使用ONS，你可以自己部署一套RocketMQ來平穩過渡
參考