不管你是新手程序員、職場老司機(jī)，還是資深架構(gòu)師，這篇文章對你來說應(yīng)該都有裨益。雖然仍是假期，但也建議你多花點時間讀一讀這些真言。

寫在前面

如果一個技術(shù)已經(jīng)存在 2 年，比如現(xiàn)在很火的前端技術(shù) react 和 vue 等，那么我能預(yù)估這個技術(shù)大致還有 2 年的生命期，再久就不確定了；如果一個架構(gòu)或設(shè)計原則已經(jīng)存在 15 年，例如單一職責(zé)和依賴倒置原則，我可以預(yù)期它還有 15 年甚至更久的生命期。原則是比具體技術(shù)更抽象，更接近事物本質(zhì)，也更經(jīng)得起時間考驗的東西。這些原則沉淀在架構(gòu)師的腦海中，最終內(nèi)化成他的 mindset，以潛意識方式影響和指導(dǎo)他的架構(gòu)和設(shè)計工作。

一晃我在軟件研發(fā)行業(yè)工作十多個年頭了，前面大部分時間做架構(gòu)設(shè)計和開發(fā)，現(xiàn)在轉(zhuǎn)型做研發(fā)管理。隨著時間的推移，很多技戰(zhàn)術(shù)細(xì)節(jié)性的東西 (工具，框架，編程語言) 在我腦海中漸漸模糊，但是一些平時學(xué)習(xí)積累起來，并且在實踐中加深體會的軟件架構(gòu)設(shè)計和組織原則，這些原則性的東西卻絲毫沒有被時間沖淡，反而愈加清新。現(xiàn)在即使我不在一線開發(fā)，但這些沉淀下來的原則仍然潛移默化地影響我的日常管理和部分架構(gòu)設(shè)計指導(dǎo)工作。我想有必要總結(jié)一下那些業(yè)界知名，給我留下深刻印象的軟件架構(gòu)設(shè)計和組織原則，和大家一起分享。

軟件設(shè)計原則GRASP 通用職責(zé)分配軟件模式

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

1. 信息專家 (Information Expert)

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

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

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

B“包含”或者聚合 AB 記錄 A 的實例B 密切地使用 AB 擁有 A 的初始化數(shù)據(jù)

3. 低耦合 (Low Coupling)

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

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

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

5. 控制器 (Controller)

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

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

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

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

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

8. 間接 (Indirection)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我的解讀

我職業(yè)早年主要關(guān)注軟件設(shè)計和編程，所以花蠻多時間學(xué)習(xí)和消化 GRASP 和 SOLID 設(shè)計原則。這些原則對我影響很深，尤其是單一職責(zé)，信息專家，關(guān)注分離，依賴倒置 / 封裝變化，分而治之等核心原則，現(xiàn)在日常研發(fā)中我時常用這些原則指導(dǎo)新手工程師。高內(nèi)聚 + 低耦合，就像道中的一陰一陽，是所有其它 OO 設(shè)計原則的原則 (元原則)，其它設(shè)計原則都是在這兩個基礎(chǔ)上泛化衍生出來的。上述原則雖然是針對 OO 設(shè)計和編程提出，但是對于大規(guī)模系統(tǒng)架構(gòu)仍然適用。比如，微服務(wù)架構(gòu)就體現(xiàn)了：單一職責(zé)：一個微服務(wù)盡可能要職責(zé)單一，提供的接口也盡可能單一 (接口分離原則)，安全 / 路由 / 限流等跨橫切面的關(guān)注點 (Cross-Cutting Concerns) 由獨立網(wǎng)關(guān)負(fù)責(zé)，體現(xiàn)關(guān)注分離 (Separation of Concerns)。信息專家：當(dāng)不確定哪個團(tuán)隊?wèi)?yīng)該負(fù)責(zé)某個微服務(wù)時，一般原則也是誰擁有數(shù)據(jù)誰負(fù)責(zé)，基于有界上下文 Bounded Context（一般是邊界比較清晰的領(lǐng)域數(shù)據(jù)源）構(gòu)建微服務(wù)。松散耦合：服務(wù)之間通過 HTTP/JSON 等輕量機(jī)制通信，服務(wù)之間不強(qiáng)耦合。受保護(hù)的變化和依賴倒置：服務(wù)之間只依賴抽象接口，實現(xiàn)可能隨時變化。間接：網(wǎng)關(guān)在外面的客戶端和內(nèi)部的服務(wù)之間增加了一層間接，使兩者不強(qiáng)耦合，可以相互獨立演化。作為架構(gòu)師或者設(shè)計師，有兩個設(shè)計能力是需要重點培養(yǎng)的，也是最難和最能體現(xiàn)架構(gòu)設(shè)計水平的：合理的職責(zé)分配能力，也就是每個類 / 組件 / 子系統(tǒng)應(yīng)該承擔(dān)什么職責(zé)，如何保證職責(zé)單一，它們之間如何協(xié)作；系統(tǒng)抽象和核心領(lǐng)域建模能力，需要深入一線業(yè)務(wù)域。

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

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

1.N + 1 設(shè)計

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

2. 回滾設(shè)計

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

3. 禁用設(shè)計

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

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

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

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

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

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

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

7. 異步設(shè)計

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

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

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

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

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

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

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

11. 非核心則購買

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

12. 使用商品化硬件

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

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

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

14. 隔離故障

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

15. 自動化

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

我的解讀

這 15 條架構(gòu)原則基本上是 eBay 在發(fā)展，經(jīng)歷過流量數(shù)量級增長沖擊過程中，通過不斷踩坑踩出來的，是干貨中的干貨。消化吸收這 15 條原則，基本可保系統(tǒng)架構(gòu)不會有原則性問題。這 15 條原則同樣適用于現(xiàn)在的微服務(wù)架構(gòu)。eBay 發(fā)展較早，它內(nèi)部其實很早 (差不多 2010 年前) 就已形成完善的微服務(wù)生態(tài)，只是沒有提出微服務(wù)這個概念。這 15 條原則可根據(jù) TTM(Time To Market)，可用性 / 可擴(kuò)展性 / 質(zhì)量，成本 / 效率分布在三個環(huán)內(nèi)，如下圖所示。

12 要素應(yīng)用

Heroku[附錄 3] 是國外知名的云應(yīng)用平臺?；谏习偃f應(yīng)用的托管和運營經(jīng)驗，創(chuàng)始人 Adam Wiggins 提出了 12 要素應(yīng)用宣言 [附錄 4]。簡單講，滿足這 12 個要素的應(yīng)用是比較容易云化并居住在 Heroku 平臺上的。

1. 基準(zhǔn)代碼

一份基準(zhǔn)代碼，多份部署。如果用鏡像部署方式，則一個鏡像可以部署到多個環(huán)境 (測試，預(yù)發(fā)，生產(chǎn))，而不是給每個環(huán)境制作一個不同鏡像。

2. 依賴

顯式聲明依賴。如果用鏡像部署，則一般依賴被直接打在鏡像中，或者聲明在 docker file 中。

3. 配置

在環(huán)境中存儲配置。在 Heroku 或者類似的 PaaS 平臺上，配置一般是推薦注入到環(huán)境變量中的?，F(xiàn)在采用集中式配置中心也是一種流行方式。

4. 后端服務(wù)

把后端服務(wù) (例如緩存，數(shù)據(jù)庫，MQ 等) 當(dāng)作附加資源，相關(guān)配置和連接字符串通過環(huán)境變量注入，或者采用配置中心。

5. 構(gòu)建、發(fā)布和運行

嚴(yán)格分離構(gòu)建和運行。如果使用鏡像部署，則構(gòu)建、發(fā)布 / 運行是通過鏡像這種中間格式嚴(yán)格分離的。

6. 進(jìn)程

一個或者多個無狀態(tài)的進(jìn)程運行應(yīng)用。容器運行時相當(dāng)于進(jìn)程，適用于無狀態(tài) Web/API。

7. 端口綁定

通過端口綁定提供服務(wù)。容器也是通過端口綁定對外提供服務(wù)。

8. 并發(fā)

通過進(jìn)程模型進(jìn)行擴(kuò)展。容器運行時相當(dāng)于進(jìn)程，通過起多個容器可以任意擴(kuò)展并發(fā)數(shù)量。

9. 易處理

快速啟動和優(yōu)雅終止可最大化健壯性。docker 容器支持秒級啟動和關(guān)閉。

10. 開發(fā)環(huán)境和線上環(huán)境等價

盡可能保持開發(fā)、測試、預(yù)發(fā)和線上環(huán)境相同。容器可以保證容器內(nèi)運行時環(huán)境的一致性，還需要保證不同環(huán)境的一致性，例如不同環(huán)境內(nèi)的操作系統(tǒng)，負(fù)載均衡，服務(wù)發(fā)現(xiàn)，后臺服務(wù)，監(jiān)控告警等要盡可能一致。

11. 日志

把日志當(dāng)作數(shù)據(jù)流。Heroku 不支持本地文件，所以必須以流方式把日志輸送到后臺日志服務(wù)。除了日志以外還要補(bǔ)充考慮 metrics 流的采集和輸送。

12. 管理進(jìn)程

后臺管理任務(wù)當(dāng)作一次性的進(jìn)程。其實相當(dāng)于在 Heroku 上以獨立進(jìn)程方式運行任務(wù) Job。

我的解讀

12 要素應(yīng)用也是當(dāng)前云原生應(yīng)用 (Cloud Native App) 的參考標(biāo)準(zhǔn)，我把這 12 要素也稱為云應(yīng)用遷移原則。滿足這 12 個要素的應(yīng)用，可以比較順利遷移到各種云平臺 (Kubernetes, Marathon, Cloud Foundry 等) 上。對于面臨企業(yè)遺留應(yīng)用改造和云化遷移的架構(gòu)師，可以重點參考這 12 條遷移原則。Docker 容器技術(shù)可以認(rèn)為是為云遷移量身定制的技術(shù)。容器化是后續(xù)云遷移的捷徑，所以遺留應(yīng)用改造可以先想辦法做到容器化。

CAP 定理

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

CAP 認(rèn)為：一個分布式系統(tǒng)最多同時滿足一致性 (Consistency)，可用性 (Availability) 和分區(qū)容忍性 (Partition Tolerance) 這三項中的兩項。

1.一致性 (Consistency)

一致性指“all nodes see the same data at the same time”，即更新操作成功，所有節(jié)點在同一時間的數(shù)據(jù)完全一致。

2.可用性 (Availability)

可用性指“Reads and writes always succeed”，即服務(wù)一直可用，而且響應(yīng)時間正常。

3.分區(qū)容忍性 (Partition tolerance)

分區(qū)容忍性指“the system continue to operate despite arbitrary message loss or failure of part of the system.”，即分布式系統(tǒng)在遇到某節(jié)點或網(wǎng)絡(luò)分區(qū)故障時，仍然能夠?qū)ν馓峁M足一致性和可用性的服務(wù)。

BASE...