第1章 架構(gòu)基礎(chǔ)

1.1 架構(gòu)到底是什么

軟件架構(gòu)指軟件系統(tǒng)的頂層結(jié)構(gòu)

1.2 架構(gòu)設(shè)計的真正目的

整個軟件技術(shù)發(fā)展的歷史，其實就是一部與“復雜度”斗爭的歷史，架構(gòu)的出現(xiàn)也不例外

架構(gòu)設(shè)計的主要目的是為了解決復雜度帶來的問題。

1.3 復雜度來源

1.3.1 高性能

高性能帶來的復雜度主要體現(xiàn)在2方面

1. 單臺計算機內(nèi)部為了高性能帶來的復雜度
2. 多臺計算機集群為了高性能帶來的復雜度

1.3.2 高可用

高可用指系統(tǒng)無中斷地執(zhí)行其功能的能力，代表系統(tǒng)的可用性程度，時進行系統(tǒng)設(shè)計的準則之一

系統(tǒng)高可用方案本質(zhì)上都是通過“冗余”來實現(xiàn)高可用

一. 計算高可用

二. 存儲高可用

存儲與計算相比，有一個本質(zhì)上的區(qū)別：將數(shù)據(jù)從一臺機器搬到另一臺機器，需要經(jīng)過線路進行傳輸。

同一機房內(nèi)部能夠做到幾毫秒，分布在不同地方的機房傳輸耗時需要幾十甚至上百毫秒。

存儲高可用的難點不在于如何備份數(shù)據(jù)，而在于如何減少或規(guī)避數(shù)據(jù)不一致對業(yè)務(wù)造成的影響。

數(shù)據(jù)延遲導致的問題

file

三. 高可用狀態(tài)決策

a. 獨裁式

獨裁式?jīng)Q策指的是存在一個獨立的決策主體，負責收集信息然后進行決策，所有冗余的個體
都將狀態(tài)信息發(fā)送給決策者。

優(yōu)點：不會出現(xiàn)決策混亂問題

缺點：當決策者本身故障時，振哥系統(tǒng)就無法實現(xiàn)準確的狀態(tài)決策

b. 協(xié)商式

協(xié)商式?jīng)Q策指的是兩個獨立的個體通過交流信息，然后根據(jù)規(guī)則進行決策，最常用的是主備決策

決策步驟

1. 2臺服務(wù)器啟動時都是備機
2. 2臺服務(wù)器建立連接
3. 2臺服務(wù)器交換狀態(tài)信息
4. 某1臺服務(wù)器做出決策，成為主機；另一臺繼續(xù)保持備機身份

難點在于如果兩臺服務(wù)器建信息交換出現(xiàn)問題，如何做出正確決策

1. 如果備機在連接中斷情況下任務(wù)主機故障，備機升級為主機，但如果主機并沒有故障，則系統(tǒng)會出現(xiàn)2個主機
2. 如果備機在連接中斷情況下不升級為主機，如果主機真的故障，那就沒有主機了
3. 如果為了降低連接中斷對狀態(tài)決策帶來的影響，可以增加更多連接，例如雙連接、三連接但不能徹底解決

c. 民主式

民主式?jīng)Q策指的是多個獨立的個體通過投票方式進行決策。例如zookeeper的選舉。

缺點：算法復雜，可能會形成腦裂。

腦裂的根本原因是原來統(tǒng)一的集群因為連接中斷，造成了2個獨立分離的子集群，每個子集群單獨進行選舉，
于是選出了2個主機。為了解決腦裂問題，民主式?jīng)Q策的系統(tǒng)一般采用“投票節(jié)點數(shù)必須超過系統(tǒng)總節(jié)點數(shù)
一半”規(guī)則來處理，但會降低系統(tǒng)整體的可用性。

file

1.3.3 可擴展性

可擴展性指系統(tǒng)為了應(yīng)對將來需求變化而提供的一種擴展能力，當有新的需求出現(xiàn)時，系統(tǒng)不需要
或僅需要少量修改就可以支持，無須整個系統(tǒng)重構(gòu)或重建

一. 預測變化

預測變化的復雜性在于

1. 不能為每個設(shè)計點都考慮可擴展性
2. 不能完全不考慮可擴展性
3. 所有的預測都存在出錯的可能性

二. 應(yīng)對變化

方案一.

將“變化”封窗在一個變化層，將不變的部分封裝在一個獨立的穩(wěn)定層。

file

該方案帶來復雜性

1. 系統(tǒng)需要拆分出變化層和穩(wěn)定層
2. 需要設(shè)計變化層和穩(wěn)定層之間的接口

方案二.

提煉出一個抽象層和一個實現(xiàn)層，抽象層是穩(wěn)定的，實現(xiàn)層可以根據(jù)業(yè)務(wù)需要定制開發(fā)，當引入新功能
時，只需要增加新的實現(xiàn)，無需修改抽象層。如策略模式。

1.3.4 低成本

低成本很多時候不會是架構(gòu)設(shè)計的首要目標，而是附加約束，需要在一定成本內(nèi)進行高性能、高可用的架構(gòu)設(shè)計。

低成本給架構(gòu)設(shè)計帶來的主要復雜度體現(xiàn)在：往往只有創(chuàng)新才能達到低成本目標。包括開創(chuàng)一個全新的
技術(shù)領(lǐng)域，還有引入新技術(shù)。

1.3.5 安全

1. 功能安全

例如XSS攻擊、SQL注入等。形象的說，功能安全更多的和具體的編碼相關(guān)，其實是“防小偷”。

2. 架構(gòu)安全

架構(gòu)安全是防強盜。防止強行破壞，如DDOS攻擊等。

可以通過防火墻控制不同區(qū)域間傳送的數(shù)據(jù)流。依靠運營商和云服務(wù)商的安全能力。

1.3.6 規(guī)模

規(guī)模帶來復雜度的主要原因就是“量變引起質(zhì)變”，當數(shù)量超過一定閾值后，復雜度會發(fā)生質(zhì)變

1. 功能越來越多，導致系統(tǒng)復雜度指數(shù)級上升
2. 數(shù)據(jù)越來越多，系統(tǒng)復雜度質(zhì)變

第2章 架構(gòu)設(shè)計原則

相比編程來說，架構(gòu)設(shè)計并沒有像編程語言那樣的語法來進行約束，更多的是面對多種可能性時進行選擇。

架構(gòu)設(shè)計的原則

1. 合適
2. 簡單
3. 演化

2.1 合適原則

合適優(yōu)于業(yè)界領(lǐng)先。

1. 將軍難打無兵之仗。 團隊規(guī)模較小，不要挑戰(zhàn)太高難度。
2. 羅馬不是一天建成的。 要有一定的積累，無法一步登天
3. 冰山下面才是關(guān)鍵。 沒有天才方案，要符合業(yè)務(wù)場景

2.2 簡單原則

簡單優(yōu)于復雜。

軟件領(lǐng)域的復雜性體現(xiàn)在

1. 結(jié)構(gòu)的復雜性
   1. 系統(tǒng)組件越多，出現(xiàn)故障概率越高
   2. 某個組件改動，會影響關(guān)聯(lián)的所有組件。
2. 邏輯復雜性

2.3 演化原則

演化優(yōu)于一步到位。

對于建筑來說，永恒是主題；對于軟件來說，變化才是主題。軟件架構(gòu)需要根據(jù)業(yè)務(wù)發(fā)展不斷變化。

第3章 架構(gòu)設(shè)計流程

3.1 有的放矢--識別復雜度

架構(gòu)設(shè)計的本質(zhì)目的是為了解決軟件系統(tǒng)的復雜性，所以首先要分析系統(tǒng)的復雜性。

正確的做法是將主要的復雜度問題列出來，然后根據(jù)業(yè)務(wù)、技術(shù)、團隊等綜合情況進行排序，優(yōu)先解決
當前面臨的最主要的復雜度問題。

3.2 按圖索驥--設(shè)計備選方案

成熟的架構(gòu)師首先對已經(jīng)存在的技術(shù)非常熟悉，對已經(jīng)經(jīng)過驗證的架構(gòu)模式爛熟于心，然后根據(jù)自己
對業(yè)務(wù)的理解，挑選合適的架構(gòu)模式進行組合，再對組合后的方案進行修改和調(diào)整。

常見錯誤

1. 設(shè)計最優(yōu)秀的方案
2. 只做一個方案
   1. 備選方案數(shù)量以3-5個為最佳
   2. 備選方案差異要比較明顯
   3. 備選方案不要只局限于已熟悉的技術(shù)
3. 備選方案過于詳細

3.3 深思熟慮--評估和選擇備選方案

“360度環(huán)評”：列出我們需要關(guān)注的質(zhì)量屬性點，然后分別從這些質(zhì)量屬性的維度去評估每個方案，再
綜合挑選合適當時情況的最優(yōu)方案。

常見的方案質(zhì)量屬性點有：性能、可用性、硬件成本、項目投入、復雜度、安全性、擴展性等

而且需要遵循架構(gòu)設(shè)計原則 合適、簡單、演進的原則

對比完成后“按優(yōu)先級選擇”，設(shè)計師綜合當前的業(yè)務(wù)發(fā)展情況、團隊人員規(guī)模和技能等因素，將質(zhì)量
屬性按照優(yōu)先級排序，首先挑選滿足第一優(yōu)先級的，如果都滿足，那就再看第二優(yōu)先級，以此類推

3.4 精雕細琢--詳細方案設(shè)計

詳細方案設(shè)計就是將方案涉及的關(guān)鍵技術(shù)細節(jié)確定下來。

通過如下方式進行避坑

1. 對方案的關(guān)鍵細節(jié)有較深入的理解。
2. 通過分步驟、分階段、分系統(tǒng)等方式盡量降低方案復雜度
3. 如果方案本身很復雜，就采取設(shè)計團隊的方式進行設(shè)計，博采眾長，匯集大家的智慧和經(jīng)驗

本文由博客一文多發(fā)平臺 OpenWrite 發(fā)布！