核心內容

• 架構設計的核心是分析複雜度
• 架構即是收益決策

首先要明白的是，架構就是一種設計，一種設計思想。

架構設計常見誤區

因為框架很重要，所以要做框架設計-》正確的廢話

• 不做框架設計系統就跑不起來麼？ 不然
• 做了框架設計就能提高開發效率麼？ 不盡然
• 設計良好的架構能促進業務發展麼？ 不好說

不是每個系統都要做框架設計嗎-》知其然不知其所以然
公司流程要求系統開發過程中必須有架構設計-》捨本逐末
為了高效能、高可用、可擴充套件，所以要做框架設計-》畫蛇添足

架構設計的真正目的

架構也是為了應對軟體系統複雜度而提出的一個解決方案，通過回顧架構產生的歷史背景和原因，我們可以基本推匯出答案：架構設計的主要目的是為了解決軟體系統複雜度帶來的問題

明確了“架構設計是為了解決軟體複雜度”原則後，很多架構上的困惑都可以很好回答。

“這麼多需求，從哪裡開始下手進行架構設計呢？”

• ——通過熟悉和理解需求，識別系統複雜性所在的地方，然後針對這些複雜點進行架構設計。

“架構設計要考慮高效能、高可用、高擴充套件……這麼多高 XX，全部設計完成估計要 1 個月，但老大隻給了 1 周時間”

• ——架構設計並不是要面面俱到，不需要每個架構都具備高效能、高可用、高擴充套件等特點，而是要識別出複雜點然後有針對性地解決問題。

“業界 A 公司的架構是 X，B 公司的方案是 Y，兩個差別比較大，該參考哪一個呢？”

• ——理解每個架構方案背後所需要解決的複雜點，然後才能對比自己的業務複雜點，參考複雜點相似的方案。

分析複雜度
分析複雜度
分析複雜度

當我們對任何一個系統無論是進行架構設計還是更改的時候，首先應識別其複雜度到底體現在哪裡

基於系統業務應用場景分析複雜度，分析複雜度是為了跟系統業務應用場景相貼合。

案例分析

比如要搭建一個“學生管理系統”，分析複雜度

• 效能：學校學生人數不多，訪問頻率不高，儲存用 MySQL 完全能夠勝任，快取都可以不用，Web 伺服器用 Nginx 綽綽有餘。
• 可擴充套件性：學生管理系統的功能比較穩定，可擴充套件的空間並不大，因此可擴充套件性也不復雜。
• 高可用：學生管理系統即使宕機 2 小時，對學生管理工作影響並不大，因此可以不做負載均衡，更不用考慮異地多活這類複雜的方案了。但是，如果學生的資料全部丟失，修復是非常麻煩的，只能靠人工逐條修復，這個很難接受，因此需要考慮儲存高可靠，這裡就有點複雜了。我們需要考慮多種異常情況：機器故障、機房故障，針對機器故障，我們需要設計
  MySQL 同機房主備方案；針對機房故障，我們需要設計 MySQL 跨機房同步方案。
• 安全性：學生管理系統儲存的資訊有一定的隱私性，例如學生的家庭情況，但並不是和金融相關的，也不包含強隱私（例如玉照、情感）的資訊，因此安全性方面只要做
  3 個事情就基本滿足要求了：Nginx 提供 ACL 控制、使用者賬號密碼管理、資料庫訪問許可權控制。
• 成本：由於系統很簡單，基本上幾臺伺服器就能夠搞定，對於一所大學來說完全不是問題，可以無需太多關注。

對應架構如下:

“複雜度”可以簡單理解成“成本”,“複雜度帶來的問題”就是“成本收益難度”，而“分析複雜度”就是“成本收益分析”，也就是說架構設計的目的是為了“收益最大化”

架構設計過程

架構即決策，收益決策
明確需求->分析複雜度->做出決策。

知識覆盤

架構設計核心是什麼？

分析複雜度（成本收益分析）

架構設計的目的是什麼？

解決複雜度的問題（成本收益難度）

小結

• 架構設計是為了解決軟體複雜度
• 優秀的架構設計能更好地收益最大化