架構到底是什麼
系統
- 關聯：包含一組有關聯的個體
- 規則：系統內個體按照指定規則運作
- 能力：規則+關聯產生新的能力
子系統
- 另一個大系統的一部分
模塊
- 從邏輯角度拆分系統得到的單元
- 從業務維度的職責劃分
組件
- 從物理角度拆分系統得到的單元
- 從技術維度的複用
框架
- 規範或者約束
- 面向編程的半成品
架構
- 軟件系統的頂層結構
- 明確系統需要包含的個體
- 明確個體運作和協作的規則
軟件開發進化歷史
- 20世紀60年代第一次軟件危機引出“結構化編程”，創造了“模塊”
- 20世紀80年代第二次軟件危機引出“面向對象編程”，創造了“對象”
- 20世紀90年代“軟件架構”開始流行，創建了“組件”
模塊、對象、組件本質上是對達到一定規模的軟件進行拆分
成功軟件項目的最重要因素就是設計，架構師、設計師需要在業務和技術中尋找一個平衡點平衡點的把握，就是架構設計中的取捨問題
架構設計的目的是什麼
爲什麼要架構設計
誤區
- 因爲開發流程需要
- 因爲架構很重要
- 每個系統都要做設計
- 爲了高性能、高可以、可擴展
正解
- 爲了解決軟件系統複雜度帶來的問題
- 通過理解和熟悉需求，識別系統複雜性所在的地方
自查
- 高性能
- 高低要多高
- 高可用
- 具體達到什麼水平，分鐘、小時
- 低延遲
- 到底多低
複雜度之高性能
單機
- 進程、線程、IO
集羣
- 任務分配
- 負載均衡
- 任務分解
- 把大一統的業務系統，拆分爲小而簡單但需要多個系統配合的業務系統
- 簡單的系統更加容易做到高性能
- 可以針對單個任務進行擴展
複雜度之高可用
本質上都是通過數據和服務的“冗餘”實現高可用
高性能與高可用的區別
高性能增加機器目的在於“擴展”處理器性能
高可用增加機器目的在於“冗餘”處理單元
計算高可用
複雜度
- 需要增加任務分配器
- 任務分配器與業務服務器之間的連接交互管理
- 任務分配器需要增加分配算法
存儲高可用
複雜度
- 數據傳輸延遲或者中斷
- 減少或者規避數據不一致對業務的影響
狀態決策高可用
複雜度
- 獨裁者
- 簡單但存在單點問題
- 協商式
- 主備連接中斷後無法判斷對方狀態
- 民主式
- 協議複雜
- 腦裂問題
複雜度之可擴展
兩個基本條件：正確預測變化、完美封裝變化
預測變化
複雜度
- 不是每個擴展點都需要考慮
- 不能完全不考慮擴展點
- 所有預測都存在出錯的可能性
應對變化
複雜度
- 拆分“變化層”和“穩定層”
- 提煉“抽象層”和“實現層”
可擴展
What
- 軟件內部
- 在系統實現新功能時，對現有影響較少
- 軟件外部
- 系統之間松耦合，系統變化對其他系統無影響
Why
快速響應變化，最大程度降低對現有系統的影響
How
- 業務角度
- 對業務深入理解，對可預計的業務變化進行預測
- 技術角度
- 利用擴展性好的技術，對變化進行封裝
架構角度
- 應用層面
- 負載均衡+集羣
- 服務層面
- 微服務
- 存儲層面
- 主備
架構設計三原則
合適
結合資源、業務、場景等各種約束條件
簡單
複雜的表現
- 結構複雜
- 系統組件數量多
- 組件關係複雜
- 邏輯複雜
- 減少系統數量會導致邏輯複雜
演化
軟件架構需要根據業務發展不斷變化
誤區
- 試圖一步到位，應對所有變化
架構設計流程
識別複雜度
複雜度來源
- 高性能
- 高可用
- 可擴展
過度設計問題
- 系統複雜，運維效率低下
- 版本發佈需要多個系統配合
- 子系統太多，小問題不斷
正確做法
- 將主要複雜問題列出來，根據業務、技術、團隊情況綜合排序
性能計算
- 一天平均每秒寫入
- 峯值爲平均值的3倍
設計備選方案
- 根據對業務的理解，挑選合適的架構模式進行組合，再對組合後的方案進行修改和調整
- 關注技術選型，而不是技術細節
常見錯誤
- 設計最優的方案
- 只做一個方案
- 備選方案過於詳細
備選方案3-5個最佳，方案差異要明顯
評估備選方案
360度環評，根據質量屬性點並結合優先級進行評估
常見質量屬性點：
- 性能
- 可用性
- 硬件成本
- 項目投入
- 複雜度
- 安全性
- 可擴展性
詳細方案設計
避免推翻備選方案
- 對備選方案關鍵細節有較深入的理解
- 通過分步驟、分階段、分系統的方式，儘量降低系統複雜度