架構設計的誤區
關於架構設計的目的，常見的誤區有：
•因為架構很重要，所以要做架構設計
這是一句正確的廢話，架構是很重要，但架構為何重要呢？
例如：不做架構設計系統就跑不起來麼？
其實不然，很多朋友尤其是經歷了創業公司的朋友可能會發現，公司的初始產品可能沒有架構設計，大夥擼起袖子簡單討論一下就開始編碼了，根本沒有正規的架構設計過程，而且也許產品開發速度還更快，上線後執行也還不錯。
例如：做了架構設計就能提公升開發效率麼？
也不盡然，實際上有時候最簡單的設計開發效率反而是最高的，架構設計畢竟需要投入時間和人力，這部分投入如果用來盡早編碼，專案也許會更快。
例如：設計良好的架構能促進業務發展麼？
這其實是知其然不知其所以然，系統確實要做架構設計，但還是不知道為何要做架構設計，反正大家都要做架構設計，所以做架構設計肯定沒錯。
這樣的架構師或者設計師很容易走入生搬硬套業界其他公司已有架構的歧路，美其名曰「參考」「微改進」。一旦強行引入其他公司架構後，很可能會發現架構水土不服，或者執行起來很彆扭等各種情況，最後往往不得不削足適履，或者不斷重構，甚至無奈推倒重來。
•公司流程要求系統開發過程中必須有架構設計
與此答案類似還有因為「架構師總要做點事情」，所以要做架構設計，其實都是捨本逐末。因為流程有規定，所以要做架構設計；因為架構師要做事，所以要做架構設計，這都是很表面地看問題，並沒有真正理解為何要做架構設計，而且很多需求並不一定要進行架構設計。如果認為架構師一定要找點事做，流程一定要進行架構設計，就會出現事實上不需要架構設計但形式上卻繼續去做架構設計，不但浪費時間和人力，還會拖慢整體的開發進度。
•為了高效能、高可用、可擴充套件，所以要做架構設計
能夠給出這個答案，說明已經有了一定的架構經歷或者基礎，畢竟確實很多架構設計都是衝著高效能、高可用……等「高 xx」的目標去的。
但往往持有這類觀點的架構師和設計師會給專案帶來巨大的災難，這絕不是危言聳聽，而是很多實際發生的事情，為什麼會這樣呢？因為這類架構師或者設計師不管三七二十一，不管什麼系統，也不管什麼業務，上來就要求「高效能、高可用、高擴充套件」，結果就會出現架構設計複雜無比，專案落地遙遙無期，團隊天天吵翻天……等各種讓人抓狂的現象，費盡九牛二虎之力將系統整上線，卻發現執行不夠穩定，經常出問題，出了問題很難解決，加個功能要改 1 個月……等各種繼續讓人抓狂的事件。
架構設計的真正目的
那架構設計的真正目的究竟是什麼？
從周二與你分享的架構設計的歷史背景，可以看到，整個軟體技術發展的歷史，其實就是一部與「複雜度」鬥爭的歷史，架構的出現也不例外。簡而言之，架構也是為了應對軟體系統複雜度而提出的乙個解決方案，通過回顧架構產生的歷史背景和原因，我們可以基本推導出答案：架構設計的主要目的是為了解決軟體系統複雜度帶來的問題。
這個結論雖然很簡潔，但卻是架構設計過程中需要時刻銘記在心的一條準則，為什麼這樣說呢？
首先，遵循這條準則能夠讓「新手」架構師心中有數，而不是一頭霧水。
新手架構師開始做架構設計的時候，心情都很激動，希望大顯身手，甚至恨不得一出手就設計出世界上最牛的 xx 架構，從此走上人生巔峰，但真的面對具體的需求時，往往都會陷入一頭霧水的狀態：
「這麼多需求，從**開始下手進行架構設計呢？」。
「架構設計要考慮高效能、高可用、高擴充套件……這麼多高 xx，全部設計完成估計要 1 個月，但老大只給了 1 周時間」。
「業界 a 公司的架構是 x，b 公司的方案是 y，兩個差別比較大，該參考哪乙個呢？」。
以上類似問題，如果明確了「架構設計是為了解決軟體複雜度」原則後，就很好回答。
•「這麼多需求，從**開始下手進行架構設計呢？」
——通過熟悉和理解需求，識別系統複雜性所在的地方，然後針對這些複雜點進行架構設計。
•「架構設計要考慮高效能、高可用、高擴充套件……這麼多高 xx，全部設計完成估計要 1 個月，但老大只給了 1 周時間」
——架構設計並不是要面面俱到，不需要每個架構都具備高效能、高可用、高擴充套件等特點，而是要識別出複雜點然後有針對性地解決問題。
•「業界 a 公司的架構是 x，b 公司的方案是 y，兩個差別比較大，該參考哪乙個呢？」
——理解每個架構方案背後所需要解決的複雜點，然後才能對比自己的業務複雜點，參考複雜點相似的方案。
其次，遵循這條準則能夠讓「老鳥」架構師有的放矢，而不是貪大求全。
技術人員往往都希望自己能夠做出最牛的東西，架構師也不例外，尤其是一些「老鳥」架構師，為了證明自己的技術牛，可能會陷入貪大求全的焦油坑而無法自拔。例如：
「我們的系統一定要做到每秒 tps 10 萬」。
「**的架構是這麼做的，我們也要這麼做」。
「docker 現在很流行，我們的架構應該將 docker 應用進來」。
以上這些想法，如果拿「架構設計是為了解決軟體複雜度」這個原則來衡量，就很容易判斷。
•「我們的系統一定要做到每秒 tps 10 萬」
——如果系統的複雜度不是在效能這部分，tps 做到 10 萬並沒有什麼用。
•「**的架構是這麼做的，我們也要這麼做」
——**的架構是為了解決**業務的複雜度而設計的，**的業務複雜度並不就是我們的業務複雜度，絕大多數業務的使用者量都不可能有**那麼大。
•「docker 現在很流行，我們的架構應該將 docker 應用進來」
——docker 不是萬能的，只是為了解決資源重用和動態分配而設計的，如果我們的系統複雜度根本不是在這方面，引入 docker 沒有什麼意義。
簡單的複雜度分析案例
假設我們需要設計乙個大學的學生管理系統，其基本功能包括登入、註冊、成績管理、課程管理等。當我們對這樣乙個系統進行架構設計的時候，首先應識別其複雜度到底體現在**。
效能：乙個學校的學生大約 1 ~ 2 萬人，學生管理系統的訪問頻率並不高，平均每天單個學生的訪問次數平均不到 1 次，因此效能這部分並不複雜，儲存用 mysql 完全能夠勝任，快取都可以不用，web 伺服器用 nginx 綽綽有餘。
可擴充套件性：學生管理系統的功能比較穩定，可擴充套件的空間並不大，因此可擴充套件性也不複雜。
高可用：學生管理系統即使宕機 2 小時，對學生管理工作影響並不大，因此可以不做負載均衡，更不用考慮異地多活這類複雜的方案了。但是，如果學生的資料全部丟失，修復是非常麻煩的，只能靠人工逐條修復，這個很難接受，因此需要考慮儲存高可靠，這裡就有點複雜了。我們需要考慮多種異常情況：機器故障、機房故障，針對機器故障，我們需要設計 mysql 同機房主備方案；針對機房故障，我們需要設計 mysql 跨機房同步方案。
安全性：學生管理系統儲存的資訊有一定的私隱性，例如學生的家庭情況，但並不是和金融相關的，也不包含強隱私（例如玉照、情感）的資訊，因此安全性方面只要做 3 個事情就基本滿足要求了：nginx 提供 acl 控制、使用者賬號密碼管理、資料庫訪問許可權控制。
成本：由於系統很簡單，基本上幾台伺服器就能夠搞定，對於一所大學來說完全不是問題，可以無需太多關注。
還有其他方面，如果有興趣，你可以自行嘗試去分析。通過我上面的分析，可以看到這個方案的主要複雜性體現在儲存可靠性上，需要保證異常的時候，不要丟失所有資料即可（丟失幾個或者幾十個學生的資訊問題不大），對應的架構如下：
學生管理系統雖然簡單，但麻雀雖小五臟俱全，基本上能涵蓋軟體系統複雜度分析的各個方面，而且絕大部分技術人員都曾經自己設計或者接觸過類似的系統，如果將這個案例和自己的經驗對比，相信會有更多的收穫。
架構 筆記二 架構設計的目的
首先要明白的是，架構就是一種設計，一種設計思想。因為框架很重要，所以要做框架設計 正確的廢話 不是每個系統都要做框架設計嗎 知其然不知其所以然 公司流程要求系統開發過程中必須有架構設計 捨本逐末 為了高效能 高可用 可擴充套件，所以要做框架設計 畫蛇添足 架構也是為了應對軟體系統複雜度而提出的乙個解...
salesforce 架構設計 從架構設計到架構師
因為碎片化的時間多了，所以開始刷起某乎了，關注了架構相關的板塊，也順手回答了一些問題。發現有很多同道中人正在經歷著我前兩年經歷的階段，對於做架構沒有相對具象的一些理解，更沒有系統化的認識。所以把最近回答的一些內容整理一下，權當記錄，留給3年後的自己 按慣例，容許我裝x開頭 一 架構的定義 在軟體開發...
mysql架構設計 初識mysql架構設計
一 應用系統如何與mysql進行一次互動？最開始接觸jdbc的時候，我們系統如何完成一次sql操作呢？第一步，建立資料庫連線 第二步，操作sql 第三步，釋放連線。但是每次建立與資料庫的連線非常耗時和資源，所以我們加入了連線池的概念。第一步的獲取連線是從連線池中獲取乙個可用的連線，第三步的釋放連線不...