回想一下，我們上學歷程，從加減乘除指數，再到高斯函式，從佇列棧再到圖，而回首間卻發現，我們80%的時間打交道的不是高斯函式和圖，而只是加減乘除和佇列棧。我們為了展示我們的與眾不同，追求極致，把簡單的問題複雜化來解決，把需求變動很小的問題無限的設計模式化，最後導致產品失敗的血案瀝瀝在目。
當你有一天做在電腦旁邊敲**，突然一位美麗的策劃跟你說，現在這個**不用再改了，老闆說，改起太麻煩，變動成本太高，讓我們重新開發。業務不可能不變動導致開發周期無限拉長，而很多專案因為考慮極制效能，導致效能擴充套件極其繁瑣，最後使用者量一增，往往全面返工。
為什麼用快取策略？只是為了提高效能？
再極致的技術和完善的業務只是磚，產品才是目的，可磚難道不是產品？
架構設計經驗分享
不是的，以上所說的架構演變順序只是針對某個側面進行單獨的改進在實際場景中，可能同一時間會有幾個問題需要解決，或者可能先達到瓶頸的是另外的方面，這時候就應該按照實際問題實際解決。如在 類的併發量可能不大，但業務可能很豐富的場景，高併發就不是重點解決的問題，此時優先需要的可能會是豐富需求的解決方案。對於...
web架構設計經驗分享
架構設計的幾個心得 一，不要過設計 never over design 這是乙個常常被提及的話題，但是只要想想你的架構裡有多少功能是根本沒有用到，或者最後廢棄的，就能明白其重要性了，初涉架構設計，往往傾向於設計大而化一的架構，希望設計出具有無比擴充套件性，能適應一切需求的增加架構，web開發領域是個...
阿里雲構建千萬級架構演變之路
2017 11 07 乙個好的架構是靠演變而來，而不是單純的靠設計。剛開始做架構設計，我們不可能全方位的考慮到架構的高效能 高擴充套件性 高安全等各方面的因素。隨著業務需求越來越多 業務訪問壓力越來越大，架構不斷的演變及進化，因而造就了乙個成熟穩定的大型架構。如 網 facebook等大型 的架構，...