系列文章是博主對沈劍的《架構師訓練營》分享內容的個人筆記總結，原內容公衆號“成爲架構師”。
1 架構演進階段的新需求
原始的All in one 的單機系統無法滿足需求，將會主要暴露出以下兩個問題
- 訪問人多的時候，訪問能夠快一點 （性能問題）
- 部分出錯的時候不要全部掛掉 （耦合問題）
2 單機資源瓶頸產生時的環境
- 此時最大的成本，是時間成本
- 能用“錢”解決的系統問題，往往不是問題
- 老闆最不願意見到的，是解決一個系統問題，花很長時間（市場和投資人等不起）
解決思路：增加硬件資源（時間短），避免大規模代碼重構（時間長）
3 架構演進，僞分佈式，提升性能
三大分離結構（圖中僅兩種）
- 讀寫分離（會引發主從延時的問題）
- 動靜分離，圖中表現了文件服務器（第三方的OSS也是）與業務邏輯的服務器分離；現代前端，像vue就是動靜分離的，對比古典的jsp，就無法實現動靜分離
- 前後臺分離，客戶端訪問與後臺管理訪問分離
設計思路
用最快的速度，增加硬件資源，提升系統性能，增加訪問速度
什麼問題沒有解決
- 耦合問題：依舊是一個掛了全部就掛了
- 主從延時新問題
- 讀寫分離只能提升讀性能，無法解決數據庫量的問題
4 垂直拆分，解耦
五八同城早期的頁面結構，就像是BBS一樣
有四種主要結構：首頁、貼子發佈頁、帖子（分類）列表、帖子詳情
四種垂直拆分：
- 業務垂直拆分（拆分的基礎和依據，還是沈劍的那句話“脫離業務的架構，都是耍流氓”）
- 代碼垂直拆分（子系統解耦）
- 數據庫垂直拆分（數據量降低，延時緩解）
- 研發團隊垂直拆分（專業化，效率提升）
設計思路
用最快的速度，增加硬件資源，解耦
僞分佈式之所以稱之爲“僞”是因爲它在整體系統層面依舊是一個單體，垂直拆分只是子系統之間實現了部分解耦，子系統之間有了一定的隔離性，但它也依舊是一個整體。
下一篇將介紹反向代理，實現真正的多機集羣，並討論nginx的負載均衡問題。
上一篇回顧：【成爲架構師2-1】容量設計：流量高低，對架構究竟有什麼影響
下一篇更精彩：【成爲架構師2-3】反向代理：接入層擴容，負載均衡