1. 解耦：如左圖, 系統a因為業務需求需要調用系統b，后續因為業務需求可能需要改代碼調用系統c，甚至還要考慮被調用的系統掛了訪問超時的問題。耦合性太高！ 如右圖, 系統a產生一條數據發送到消息隊列里面去， 需要數據的系統就去監控消息隊列就好了。
2. 異步：如左圖，一個請求過來，3個服務走完需要花450ms； 右圖，系統a處理完請求后直接丟給消息隊列，然后響應用戶，不需要等待。只花了150ms這樣就節約了不少時間！一般互聯網項目用戶請求不超過200ms體驗是最好的。
3. 削峰：
消息中間件的選擇
activemq：萬級吞吐量，老牌產品 mq領域的功能比較完善，(社區不活躍, 不建議用)
rabbitmq：吞吐量比activemq高一點點，基於erlang開發 並發性能好。(社區活躍，適合中小公司)
rocketmq：十萬級吞吐量，阿里產品java開發，經過雙十一考驗。topic可以達到幾百，幾千個的級別，吞吐量會有較小幅度的下降(怕像dubbo一樣后期黃了，自己團隊沒人能改造源碼。適合中大公司)
kafka ：十萬級吞吐量，topic從幾十個到幾百個的時候，吞吐量會大幅度下降。天然適合大數據實時計算以及日志收集。
MQ架構設計思路
1. 可伸縮性：
設計為分布式的，例如分為nameBervice和broker；broker負責Topic消息存儲、管理和分發等功能；bs就是一個注冊中心、維護所有Brokers信息。這樣通過水平擴展就提升了吞吐量和容量了。
2. 可靠性：
數據要磁盤落地，來做到可恢復、持久化。然后順序寫隨機讀來提高性能。
3. 容錯性：
多個機器中有的宕機后,要有類似zookeeper的的投票選舉功能，確保集群穩定運行。