極客時間：《從 0 開始學架構》:架構設計流程:設計備選方案
1、引言
經過上一章節關於識別復雜度，從而確定了當前系統面臨的主要復雜問題后，方案設計就有了明確的目標，便可以進行架構方案的設計。
2、架構設計第 2 步：設計備選方案
成熟的架構師需要對已經存在的技術非常熟悉，對已經經過驗證的架構模式爛熟於心，然后根據自己對業務的理解，挑選合適的架構模式進行組合，再對組合后的方案進行修改和調整。
只有當這種方式完全無法滿足需求的時候，才會考慮進行方案的創新，而事實上方案的創新絕大部分情況下也都是基於已有的成熟技術。
NoSQL：Key-Value 的存儲和數據庫的索引其實是類似的，Memcache 只是把數據庫的索引獨立出來做成了一個緩存系統。
Hadoop 大文件存儲方案，基礎其實是集群方案 + 數據復制方案。
Docker 虛擬化，基礎是 LXC（Linux Containers）。
LevelDB 的文件存儲結構是 Skip List。
雖說是基於已有的技術或架構模式進行組合，然后調整，大部分情況下就能得到我們需要的方案，但由於可選的模式有很多，組合的方案也就很多，在進行些小創新，解決方案就會更多，因此，架構設計並不簡單。這個階段也是很多架構師容易犯錯的地方。
- 第一種常見的錯誤：設計最優秀的方案。
根據架構設計原則中“合適原則”和“簡單原則“的要求，挑選合適自己業務、團隊、技術能力的方案才是好方案；否則要么浪費大量資源開發了無用的系統。 - 第二種常見的錯誤：只做一個方案。
PS:弊端
- 心里評估過於簡單，可能沒有想得全面，只是因為某一個缺點就把某個方案給否決了，而實際上沒有哪個方案是完美的，某個地方有缺點的方案可能是綜合來看最好的方案。
- 單一方案設計會出現過度辯護的情況，即架構評審時，針對方案存在的問題和疑問，架構師會竭盡全力去為自己的設計進行辯護，經驗不足的設計人員可能會強詞奪理。
因此，架構師需要設計多個備選方案，合理的做法如下：
- 備選方案的數量以 3 ~ 5 個為最佳
- 備選方案的差異要比較明顯
- 備選方案的技術不要只局限於已經熟悉的技術
- 第三種常見的錯誤：備選方案過於詳細
浪費時間精力，還得不到好的結果
正確的做法是備選階段關注的是技術選型，而不是技術細節，技術選型的差異要比較明顯。
3、小結
針對當前系統面臨的主要復雜問題，對症下葯，無論是采用常見的熟悉方案，還是基於已有方案進行創新，盡量作出3～5套的備選方案，專注於技術選型，有理有據