不廢話先說結論：要先拋出問題！
爲什麼拋出問題如此重要？我來說一下我的感悟
有開發經驗的同學都知道，每一個優秀的開源項目或者商業性框架。都不是一蹴而就的。迭代升級一直是每個優秀系統的自我修養。反過來說，在項目啓動之初，就考慮的大而全。往往會把問題複雜化。考慮不全不說，反而會大幅增加問題拆解和項目落地的難度，而且大部分問題，都會在系統的使用中陸續暴露，所以這又給迭代升級添加了一定的宿命感。
別說系統怎麼怎麼好，怎麼優秀。 瞭解系統面對的問題，和其解決的方案，就是了解這個系統的歷史背景和迭代過程，最好的方式。
現在舉個優秀的栗子：大家先來看看淘寶關於RocketMq的一篇介紹文章。
http://jm.taobao.org/2017/01/12/rocketmq-quick-start-in-10-minutes/
本文首先引出消息中間件通常需要解決哪些問題，在解決這些問題當中會遇到什麼困難，Apache RocketMQ作爲阿里開源的一款高性能、高吞吐量的分佈式消息中間件否可以解決，規範中如何定義這些問題。然後本文將介紹RocketMQ的架構設計，以期讓讀者快速瞭解RocketMQ。
爲什麼我會喜歡這篇文章呢？或者說他和其他文章有什麼優勢呢？
對比其他文章，作者會大量的着墨於系統的特性，比如靈活可拓展，可以處理海量消息堆集，可以主從雙寫等。讀着看到，覺得牛逼啊，然後沒有什麼共鳴，除了有個模糊的記憶和覺得自己很菜外，可以說是食之無味。
而其實上述的種種優秀的系統的特性，真是都來源於用戶遇到的實際問題，經過開發的設計實現，纔有rocketmq現在的模樣。
我羅列了文中提到12個問題。
瞭解了這12問題，其實就大致瞭解了整個MQ，回頭再看項目，能更好的理解這些特性，看到物理集羣配置方式。纔會大呼妙哉。
我之後如果有機會推動消息中間件的迭代升級，大可以按rocketedMq遇到的12個問題，來進行分析，這可以大大的提高效率。
總而言之，所有工具架構的出現，都是有自己的歷史背景，都有特定的業務場景，瞭解他們面對的問題，結合自己沉澱的認知，才能最全面的去理解他們。
所以之後如果自己編寫介紹某些系統的文章，也希望能以解釋系統遇到的問題，作爲主要的切入點。