軟件設(shè)計(jì)原則

GRASP 通用職責(zé)分配軟件模式

來自 Craig Larman 的軟件設(shè)計(jì)書《UML 和模式應(yīng)用》，Larman 在書中提出軟件設(shè)計(jì)的關(guān)鍵任務(wù)是職責(zé)分配，并提煉總結(jié)出 9 種 (5 種核心 +4 種擴(kuò)展) 軟件職責(zé)分配模式，這些模式是比 GoF 設(shè)計(jì)模式更抽象的元模式。

1. 信息專家 (Information Expert)

為對(duì)象分配職責(zé)的通用原則 – 把職責(zé)分配給擁有足夠信息可以履行職責(zé)的專家

2. 創(chuàng)建者 (Creator)

將創(chuàng)建 A 的職責(zé)賦給 B，如果至少下面一種情況為真：

• B“包含”或者聚合 A

• B 記錄 A 的實(shí)例

• B 密切地使用 A

• B 擁有 A 的初始化數(shù)據(jù)

3. 低耦合 (Low Coupling)

賦予職責(zé)使得對(duì)象間的耦合度盡可能低，最小化對(duì)象間的依賴和變更影響，最大化重用。

4. 高內(nèi)聚 (High Cohesion)

賦予職責(zé)使得每個(gè)對(duì)象的職責(zé)盡可能保持聚焦和單一，易于管理和理解。

5. 控制器 (Controller)

把職責(zé)賦予系統(tǒng)、設(shè)備或者子系統(tǒng)的表示類 (門面控制器)，或者某個(gè)用例的表示類 (用例控制器)，讓控制器接收事件并協(xié)調(diào)整個(gè)系統(tǒng)的運(yùn)作。

6. 多態(tài) (Polymorphism)

將職責(zé)分配給多個(gè)具有同名方法的多態(tài)子類，運(yùn)行時(shí)根據(jù)需要?jiǎng)討B(tài)切換子類，讓系統(tǒng)行為變得可插拔。

7. 純虛構(gòu) (Pure Fabrication)

針對(duì)真實(shí)問題域中不存在，但是設(shè)計(jì)建模中有用的概念，設(shè)計(jì)虛構(gòu)類并賦予職責(zé)。

8. 間接 (Indirection)

在兩個(gè)或者多個(gè)對(duì)象間有交互的情況下，為避免直接耦合，提高重用性，創(chuàng)建中間類并賦予職責(zé)，對(duì)象的交互交由中間類協(xié)調(diào)。

9. 受保護(hù)的變化 (Protected Variation)

簡(jiǎn)單講就是封裝變化。識(shí)別系統(tǒng)中可能的不穩(wěn)定或者變化，在不穩(wěn)定組件上創(chuàng)建穩(wěn)定的抽象接口，將可能的變化封裝在接口之后，使得系統(tǒng)內(nèi)部的不穩(wěn)定或者變化不會(huì)對(duì)系統(tǒng)的其它部分產(chǎn)生不良影響。

SOLID 面向?qū)ο笤O(shè)計(jì)原則

S.O.L.I.D 是面向?qū)ο笤O(shè)計(jì)和編程 (OOD&OOP) 中幾個(gè)重要原則的首字母縮寫，受 Robert Martin 推崇。

1. 單一職責(zé)原則 (The Single Responsibility Principle)

修改某個(gè)類的理由應(yīng)該只有一個(gè)，如果超過一個(gè)，說明類承擔(dān)不止一個(gè)職責(zé)，要視情況拆分。

2. 開放封閉原則 (The Open Closed Principle)

軟件實(shí)體應(yīng)該對(duì)擴(kuò)展開放，對(duì)修改封閉。一般不要直接修改類庫源碼（即使你有源代碼），通過繼承等方式擴(kuò)展。

3. 里氏替代原則 (The Liskov Substitution Principle)

當(dāng)一個(gè)子類的實(shí)例能夠被替換成任何超類的實(shí)例時(shí)，它們之間才是真正的 is-a 關(guān)系。

4. 依賴倒置原則 (The Dependency Inversion Principle)

高層模塊不應(yīng)該依賴于底層模塊，二者都應(yīng)該依賴于抽象。換句話說，依賴于抽象，不要依賴于具體實(shí)現(xiàn)。比方說，你不會(huì)把電器電源線焊死在室內(nèi)電源接口處，而是用標(biāo)準(zhǔn)的插頭插在標(biāo)準(zhǔn)的插座 (抽象) 上。

5. 接口分離原則 (The Interface Segregation Principle)

不要強(qiáng)迫用戶去依賴它們不使用的接口。換句話說，使用多個(gè)專門的接口比使用單一的大而全接口要好。

?

分布式系統(tǒng)架構(gòu)設(shè)計(jì)原則和理論

AKF 架構(gòu)原則

這 15 個(gè)架構(gòu)原則來自《架構(gòu)即未來 (The Art of Scalability)》 一書，作者馬丁 L. 阿伯特和邁克爾 T. 費(fèi)舍爾分別是 eBay 和 PayPal 的前 CTO，他們經(jīng)歷過 eBay 和 PayPal 大規(guī)模分布式電商平臺(tái)的架構(gòu)演進(jìn)，在一線實(shí)戰(zhàn)經(jīng)驗(yàn)的基礎(chǔ)上總結(jié)并提煉出 15 條架構(gòu)原則：

1. N + 1 設(shè)計(jì)

永遠(yuǎn)不要少于兩個(gè)，通常為三個(gè)。比方說無狀態(tài)的 Web/API 一般部署至少>=2 個(gè)。

2. 回滾設(shè)計(jì)

確保系統(tǒng)可以回滾到以前發(fā)布過的任何版本?？梢酝ㄟ^發(fā)布系統(tǒng)保留歷史版本，或者代碼中引入動(dòng)態(tài)開關(guān)切換機(jī)制 (Feature Switch)。

3. 禁用設(shè)計(jì)

能夠關(guān)閉任何發(fā)布的功能。新功能隱藏在動(dòng)態(tài)開關(guān)機(jī)制 (Feature Switch) 后面，可以按需一鍵打開，如發(fā)現(xiàn)問題隨時(shí)關(guān)閉禁用。

4. 監(jiān)控設(shè)計(jì)

在設(shè)計(jì)階段就必須考慮監(jiān)控，而不是在實(shí)施完畢之后補(bǔ)充。例如在需求階段就要考慮關(guān)鍵指標(biāo)監(jiān)控項(xiàng)，這就是度量驅(qū)動(dòng)開發(fā) (Metrics Driven Development) 的理念。

5. 設(shè)計(jì)多活數(shù)據(jù)中心

不要被一個(gè)數(shù)據(jù)中心的解決方案把自己限制住。當(dāng)然也要考慮成本和公司規(guī)模發(fā)展階段。

6. 使用成熟的技術(shù)

只用確實(shí)好用的技術(shù)。商業(yè)組織畢竟不是研究機(jī)構(gòu)，技術(shù)要落地實(shí)用，成熟的技術(shù)一般坑都被踩平了，新技術(shù)在完全成熟前一般需要踩坑躺坑。

7. 異步設(shè)計(jì)

能異步盡量用異步，只有當(dāng)絕對(duì)必要或者無法異步時(shí)，才使用同步調(diào)用。

8. 無狀態(tài)系統(tǒng)

盡可能無狀態(tài)，只有當(dāng)業(yè)務(wù)確實(shí)需要，才使用狀態(tài)。無狀態(tài)系統(tǒng)易于擴(kuò)展，有狀態(tài)系統(tǒng)不易擴(kuò)展且狀態(tài)復(fù)雜時(shí)更易出錯(cuò)。

9. 水平擴(kuò)展而非垂直升級(jí)

永遠(yuǎn)不要依賴更大、更快的系統(tǒng)。一般公司成長(zhǎng)到一定階段普遍經(jīng)歷過買更大、更快系統(tǒng)的階段，即使淘寶當(dāng)年也買小型機(jī)扛流量，后來扛不住才體會(huì)這樣做不 scalable，所以才有后來的去 IOE 行動(dòng)。

10. 設(shè)計(jì)時(shí)至少要有兩步前瞻性

在擴(kuò)展性問題發(fā)生前考慮好下一步的行動(dòng)計(jì)劃。架構(gòu)師的價(jià)值就體現(xiàn)在這里，架構(gòu)設(shè)計(jì)對(duì)于流量的增長(zhǎng)要有提前量。

11. 非核心則購買

如果不是你最擅長(zhǎng)，也提供不了差異化的競(jìng)爭(zhēng)優(yōu)勢(shì)則直接購買。避免 Not Invented Here 癥狀，避免凡事都要重造輪子，畢竟達(dá)成業(yè)務(wù)目標(biāo)才是重點(diǎn)。

12. 使用商品化硬件

在大多數(shù)情況下，便宜的就是最好的。這點(diǎn)和第 9 點(diǎn)是一致的，通過商品化硬件水平擴(kuò)展，而不是買更大、更快的系統(tǒng)。

13. 小構(gòu)建、小發(fā)布和快試錯(cuò)

全部研發(fā)要小構(gòu)建，不斷迭代，讓系統(tǒng)不斷成長(zhǎng)。這個(gè)和微服務(wù)理念一致。

14. 隔離故障

實(shí)現(xiàn)故障隔離設(shè)計(jì)，通過斷路保護(hù)避免故障傳播和交叉影響。通過艙壁泳道等機(jī)制隔離失敗單元 (Failure Unit)，一個(gè)單元的失敗不至影響其它單元的正常工作。

15. 自動(dòng)化

設(shè)計(jì)和構(gòu)建自動(dòng)化的過程。如果機(jī)器可以做，就不要依賴于人。自動(dòng)化是 DevOps 的基礎(chǔ)。

這 15 條架構(gòu)原則基本上是 eBay 在發(fā)展，經(jīng)歷過流量數(shù)量級(jí)增長(zhǎng)沖擊過程中，通過不斷踩坑踩出來的，是干貨中的干貨。消化吸收這 15 條原則，基本可保系統(tǒng)架構(gòu)不會(huì)有原則性問題。

這 15 條原則同樣適用于現(xiàn)在的微服務(wù)架構(gòu)。eBay 發(fā)展較早，它內(nèi)部其實(shí)很早 (差不多 2010 年前) 就已形成完善的微服務(wù)生態(tài)，只是沒有提出微服務(wù)這個(gè)概念。

這 15 條原則可根據(jù) TTM(Time To Market)，可用性 可擴(kuò)展性 質(zhì)量，成本 效率分布在三個(gè)環(huán)內(nèi)，如下圖所示。

?

CAP 定理

在 2000 年 7 月，加州大學(xué)伯克利分校的 Eric Brewer 教授在 ACM PODC 會(huì)議上提出了著名的 CAP 猜想，而后，在經(jīng)過兩年的努力，麻省理工學(xué)院的 Seth Gilbert 和 Nancy Lynch 從理論上證明了此猜想，從而使 CAP 理論正式成為了分布式計(jì)算領(lǐng)域的公認(rèn)定理。

CAP 理論強(qiáng)調(diào)，在分布式系統(tǒng)中，最多只能同時(shí)滿足一致性 (Consistency)、可用性 (Availability) 和分區(qū)容忍性 (Partition Tolerance) 中的兩項(xiàng)。其中:

• 一致性指所有節(jié)點(diǎn)在同一時(shí)間點(diǎn)看到的數(shù)據(jù)完全一致

• 可用性則指 reads 和 writes 操作始終成功和響應(yīng)時(shí)間正常

• 分區(qū)容忍性則指分布式系統(tǒng)能夠在遭遇到某節(jié)點(diǎn)或網(wǎng)絡(luò)分區(qū)故障時(shí)，仍然能夠?qū)ν馓峁M足一致

BASE 理論

eBay 架構(gòu)師 Dan Pritchett 憑借其豐富的實(shí)踐經(jīng)驗(yàn)，在 ACM 上發(fā)表了一篇文章，并提出了 BASE 理論，作為對(duì) CAP 理論的一種延伸。其核心思想是：盡管無法做到強(qiáng)一致性（即 CAP 理論中的一致性概念），但是通過采用適當(dāng)?shù)姆绞娇梢詫?shí)現(xiàn)最終一致性。BASE 代表基本可用（Basically Available）、軟狀態(tài)（Soft State）和最終一致性（Eventual Consistency）。

1.基本可用 (Basically Available)

基本可用是指分布式系統(tǒng)在出現(xiàn)故障時(shí)，允許損失部分可用性，即保證核心可用。比如服務(wù)降級(jí)。

2.軟狀態(tài) (Soft State)

軟狀態(tài)是指允許系統(tǒng)存在中間狀態(tài)，而該中間狀態(tài)不會(huì)影響系統(tǒng)的整體可用性。分布式存儲(chǔ)中一般一份數(shù)據(jù)至少存三個(gè)副本，允許不同節(jié)點(diǎn)間副本同步的延遲就是軟狀態(tài)的體現(xiàn)。

3.最終一致性 (Eventual Consistency)

最終一致性是指系統(tǒng)中的所有數(shù)據(jù)副本經(jīng)過一段時(shí)間后，最終能夠達(dá)成一致狀態(tài)。弱一致性和強(qiáng)一致性相反，最終一致性是弱一致性的一種特殊情況。

CAP 和 BASE 理論課題極深，背后甚至涉及到很復(fù)雜的數(shù)學(xué)證明。但我從簡(jiǎn)單淺顯的角度來理解：在分布式系統(tǒng)中，性能、高可用、不丟數(shù)據(jù)和數(shù)據(jù)一致性通常是強(qiáng)需求。由于流量不斷增長(zhǎng)，數(shù)據(jù)復(fù)制和分區(qū)成為了不可避免的挑戰(zhàn)：
復(fù)制（replication）：數(shù)據(jù)在多個(gè)節(jié)點(diǎn)上存儲(chǔ)多份，以確保數(shù)據(jù)不丟失且系統(tǒng)保持高可用；
分區(qū)（partition）：數(shù)據(jù)按照某種規(guī)則切分分發(fā)到不同節(jié)點(diǎn)上，以降低單個(gè)節(jié)點(diǎn)的負(fù)載并提高系統(tǒng)性能，例如數(shù)據(jù)庫的分庫分表、系統(tǒng)拆分成微服務(wù)等，這種做法也會(huì)帶來一些一致性問題。為了解決一致性問題，我們可以在時(shí)間上做出一定的妥協(xié)，即實(shí)現(xiàn)最終一致性。如果要求時(shí)間上的強(qiáng)一致性，就必須適當(dāng)?shù)貭奚捎眯?。因此，在系統(tǒng)架構(gòu)設(shè)計(jì)上，與狀態(tài)一致性的斗爭(zhēng)是其中一個(gè)重要組成部分。
當(dāng)選擇使用分布式產(chǎn)品時(shí)，比如 NoSQL 數(shù)據(jù)庫，必須了解它在 CAP 環(huán)章除的位置，以確保它可以滿足特定場(chǎng)景的需求。

組織和系統(tǒng)改進(jìn)原則

康威法則

Melvin Conway 在 1967 年提出所謂康威法則，指出組織架構(gòu)和系統(tǒng)架構(gòu)之間有一種隱含的映射關(guān)系：

Organization which design system […] are constrained to produce designs which are copies of the communication structures of these organization. 設(shè)計(jì)系統(tǒng)的組織其產(chǎn)生的設(shè)計(jì)等價(jià)于組織間的溝通結(jié)構(gòu)。

康威法則也可以倒過來闡述：

Conway’s law reversed：You won’t be able to successfully establish an efficient organization structure that is not supported by your system design(architecture)。如果系統(tǒng)架構(gòu)不支持，你無法建立一個(gè)高效的組織；同樣，如果你的組織架構(gòu)不支持，你也無法建立一個(gè)高效的系統(tǒng)架構(gòu)。

系統(tǒng)改進(jìn)三原則

IT 運(yùn)維管理暢銷書《鳳凰項(xiàng)目》 的作者 Gene Kim 在調(diào)研了眾多高效能 IT 組織后總結(jié)出支撐 DevOps 運(yùn)作的三個(gè)原理 (The Three Ways: The Principles Underpinning DevOps)，我認(rèn)為也是系統(tǒng)改進(jìn)提升的一般性原理，見下圖：

原理一：系統(tǒng)思考 (System Thinking)

對(duì)于以開發(fā)為導(dǎo)向的組織而言，他們的能力已不僅僅只是生產(chǎn)軟件，更重要的是持續(xù)地向客戶傳遞價(jià)值。該價(jià)值從業(yè)務(wù)需求開始，依次經(jīng)過研發(fā)、測(cè)試、部署、運(yùn)維等流程，并最終以服務(wù)形式交付給客戶。整個(gè)價(jià)值鏈的流速并不只依賴于單個(gè)團(tuán)隊(duì)或個(gè)人的杰出貢獻(xiàn)，而是由整個(gè)價(jià)值鏈中最薄弱環(huán)節(jié)的限制而決定。所以，局部?jī)?yōu)化通常并不管用，反而還可能會(huì)損害整體效率。Gene Kim還特別強(qiáng)調(diào)："瓶頸之外的所有優(yōu)化只是幻象"。

原理二：強(qiáng)化反饋環(huán)?(Amplify Feedback Loops)

通過加強(qiáng)反饋機(jī)制實(shí)現(xiàn)流程改進(jìn)是非常常見的方法。原則二著重于加強(qiáng)企業(yè)與客戶、組織團(tuán)隊(duì)、流程和系統(tǒng)內(nèi)部的反饋環(huán)路。如果沒有測(cè)量，則無法實(shí)現(xiàn)提升，只有通過測(cè)量數(shù)據(jù)反饋來優(yōu)化和改進(jìn)系統(tǒng)。

原理三：持續(xù)試驗(yàn)和學(xué)習(xí)的文化?(Culture of Continual Experimentation And Learning)

新企業(yè)管理文化鼓勵(lì)進(jìn)行勇于嘗試和不斷實(shí)驗(yàn)、學(xué)習(xí)、改進(jìn)的文化氛圍。

總結(jié)

盡管上述原則對(duì)架構(gòu)師而言具有深遠(yuǎn)的指導(dǎo)意義，但在實(shí)際工作中，根據(jù)業(yè)務(wù)、時(shí)間、資源和團(tuán)隊(duì)情況靈活應(yīng)用它們才能收到更好的效果。這些原則并非僵化的規(guī)則，有時(shí)候甚至?xí)贿`反，不過要注意，這樣的做法通常都有相應(yīng)的成本，架構(gòu)師需要在意并及時(shí)變通以彌補(bǔ)成本帶來的損失。

?

作者|易安文章來源地址http://www.zghlxwxcb.cn/news/detail-710404.html

到了這里，關(guān)于架構(gòu)師必須掌握的架構(gòu)設(shè)計(jì)原則的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！