《從零開始學架構》讀後感

2019.9.9到9.10，花了兩天的時間通讀了《從零開始學架構》。

在網際網路的浪潮下，技術迭代如此之快，不免心生疑惑，有些迷茫。

大三下學完spring+springmvc以及mybatis的組合框架以為終於能歇一歇了，springboot和springcloud映入眼簾。了解完springcloud元件後對單體和微服務之間產生了極強的主觀偏見，分布式，集群，高效能，高可用這些名詞在大腦中留下了深深的烙印。

且不說業務開發的難度，docker和k8s的部署我只是有所耳聞，根本不能信手拈來，團隊裡的其他人也沒有了解過容器化部署的相關技術。

9.8晚由於白天的焦灼和問題難以解決，晚上10點就早早入睡了。第二天起了個大早，突發奇想去圖書館溜達溜達，暑假過去兩個多月，圖書館四樓最靠窗的新書架又更新了。挑幾本感興趣的，於是兩天的瘋狂閱讀開始了。

如果拿三國鼎立時代來做比喻的話，書裡沒有描繪子龍是如何習武，軍隊是如何訓練，而是講述孔明是如何行軍布陣，運籌帷幄的。

在書裡幾乎沒有一行關於**的闡述，而是著眼於整個系統的結構和設計，或者說是一種立足與軟體開發上的全域性觀。

合適，簡單，演化三個原則瞬間解決了我的困惑，聚焦於技術，就會為了使用技術而使用技術。

針對具體的業務和預算成本制定合適的開發計畫才是可取之道。

資料庫的選擇和快取的使用，搭建伺服器集群實現儲存和計算的高可用，高效能。

隨著業務的發展，初期的架構產生瓶頸。需要更高效能的服務提供。與此同時，會帶來成本上的劇增。所以在專案開始，對於初創專案，並不建議直接採用這種方式，當業務訪問量過小，高效能，高可用就是一場打水漂的遊戲，白白浪費了資源。

分層，soa和微服務。同樣，分層結構對比之下最為簡單，而soa是針對於大量異構的it系統的整合，微服務是業務發展後理想的樣子，但服務粒度劃分值得商榷。

開篇**的發展史令我為之震動。

其中，網際網路業務發展

使用者規模增大

非常具有參考價值，是在技術選擇盲目時的指南針。

技術是隨著業務發展而變化的，合適優於業界領先，簡單優於複雜，演化優於一步到位。