不是的，以上所說的架構演變順序只是針對某個側面進行單獨的改進在實際場景中，可能同一時間會有幾個問題需要解決，或者可能先達到瓶頸的是另外的方面，這時候就應該按照實際問題實際解決。如在**類的併發量可能不大，但業務可能很豐富的場景，高併發就不是重點解決的問題，此時優先需要的可能會是豐富需求的解決方案。
對於單次實施並且效能指標明確的系統，架構設計到能夠支援系統的效能指標要求就足夠了，但要留有擴充套件架構的介面以便不備之需。對於不斷發展的系統，如電商平台，應設計到能滿足下一階段使用者量和效能指標要求的程度，並根據業務的增長不斷的迭代公升級架構，以支援更高的併發和更豐富的業務。
所謂的「大資料」其實是海量資料採集清洗轉換、資料儲存、資料分析、資料服務等場景解決方案的乙個統稱，在每乙個場景都包含了多種可選的技術如資料採集有flume、sqoop、kettle等，資料儲存有分布式檔案系統hdfs、fastdfs，nosql資料庫hbase、mongodb等，資料分析有spark技術棧、機器學習演算法等。總的來說大資料架構就是根據業務的需求，整合各種大資料元件組合而成的架構，一般會提供分布式儲存、分布式計算、多維分析、資料倉儲、機器學習演算法等能力。而服務端架構更多指的是應用組織層面的架構，底層能力往往是由大資料架構來提供。
web架構設計經驗分享
架構設計的幾個心得 一，不要過設計 never over design 這是乙個常常被提及的話題，但是只要想想你的架構裡有多少功能是根本沒有用到，或者最後廢棄的，就能明白其重要性了，初涉架構設計，往往傾向於設計大而化一的架構，希望設計出具有無比擴充套件性，能適應一切需求的增加架構，web開發領域是個...
Web架構設計的經驗分享
一 不要過設計 never over design 這是乙個常常被提及的話題，但是只要想想你的架構裡有多少功能是根本沒有用到，或者最後廢棄的，就能明白其重要性了，初涉架構設計，往往傾向於設計 大而化一的架構，希望設計出具有無比擴充套件性，能適應一切需求的增加架構web開發領域是個非常動態的過程，我們...
架構筆錄 別人架構設計經驗
1 流量影響整個 架構的設計 2 架構的設計是一種平衡的設計，沒有完美的架構，架構的設計要簡單靈活，便於擴充，因此找出平衡點是關鍵 3 架構的設計不要過渡，考慮到1 2年內的使用者需求即可 4 小 與大 的區別在於，當資料量達到一定級別，小問題會變成大問題 5 大的 架構不適合做小事情，小架構也做不...