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

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

大三下學完Spring+SpringMVC以及MyBatis的組合框架以為終於能歇一歇了，SpringBoot和SpringCloud映入眼帘。瞭解完SpringCloud組件後對單體和微服務之間產生了極強的主觀偏見，分散式，集群，高性能，高可用這些名詞在大腦中留下了深深的烙印。

大四想跟朋友一起開發一個APP，卻在後端技術選型上面犯了難。剛剛學完SpringCloud的我自然是想用以至用。但理智讓我冷靜了下來，微服務真的適合我們嗎？

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

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

回顧一下

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

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

第一部分 架構設計原則和流程

合適，簡單，演化三個原則瞬間解決了我的困惑，聚焦於技術，就會為了使用技術而使用技術。
針對具體的業務和預算成本制定合適的開發計劃才是可取之道。

第二部分 高性能，高可用架構模式

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

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

第三部分 可擴展架構模式

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

第四部分 架構實戰

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

其中，
互聯網業務發展

• 業務複雜性
  • 初創期（創新，快）0-1w
  • 發展期（堆功能，優化期）1w-10w
  • 架構期（拆功能，拆資料庫，拆伺服器）10w到100w
  • 競爭期（平臺化，避免重覆造輪子；服務化，解決系統交互問題）1000w+
  • 成熟期（優化）1億+
• 用戶規模增大
  • 性能
  • 可用性

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

小結：

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