1、 系統(tǒng)架構(gòu)的設(shè)計原則InfoQ 微信號 infoqchina功能介紹 有內(nèi)容的技術(shù)社區(qū)媒體寫在前面如果一個技術(shù)已經(jīng)存在 2 年，比如現(xiàn)在很火的前端技術(shù) react 和 vue 等，那么我們能預(yù)估這個技術(shù)大致還有 2 年的生命期，再久就不確定了；如果一個架構(gòu)或設(shè)計原則已經(jīng)存在 15 年，例如單一職責和依賴倒置原則，我可以預(yù)期它還有 15 年甚至更久的生命期。原則是比具體技術(shù)更抽象，更接近事物本質(zhì)，也更經(jīng)得起時間考驗的東西。這些原則沉淀在架構(gòu)師的腦海中，最終內(nèi)化成他的 mindset，以潛意識方式影響和指導(dǎo)他的架構(gòu)和設(shè)計工作。在實踐中加深體會的軟件架構(gòu)設(shè)計和組織原則，這些原則性的東西卻絲毫沒有被時

2、間沖淡，反而愈加清新。現(xiàn)在即使不在一線開發(fā)，但這些沉淀下來的原則仍然潛移默化地影響日常管理和部分架構(gòu)設(shè)計指導(dǎo)工作。本文總結(jié)了那些業(yè)界知名，給我留下深刻印象的軟件架構(gòu)設(shè)計和組織原則，和大家一起分享。軟件設(shè)計原則 GRASP 通用職責分配軟件模式 來自 Craig Larman 的軟件設(shè)計書UML 和模式應(yīng)用附錄 1，Larman 在書中提出軟件設(shè)計的關(guān)鍵任務(wù)是職責分配，并提煉總結(jié)出 9 種 (5 種核心 +4 種擴展) 軟件職責分配模式，這些模式是比 GoF 設(shè)計模式更抽象的元模式。1. 信息專家 (Information Expert)為對象分配職責的通用原則 把職責分配給擁有足夠信息可以履行

3、職責的專家2. 創(chuàng)建者 (Creator)將創(chuàng)建 A 的職責賦給 B，如果至少下面一種情況為真：B“包含”或者聚合 AB 記錄 A 的實例B 密切地使用 AB 擁有 A 的初始化數(shù)據(jù)3. 低耦合 (Low Coupling)賦予職責使得對象間的耦合度盡可能低，最小化對象間的依賴和變更影響，最大化重用。4. 高內(nèi)聚 (High Cohesion)賦予職責使得每個對象的職責盡可能保持聚焦和單一，易于管理和理解。5. 控制器 (Controller)把職責賦予系統(tǒng)、設(shè)備或者子系統(tǒng)的表示類 (門面控制器)，或者某個用例的表示類 (用例控制器)，讓控制器接收事件并協(xié)調(diào)整個系統(tǒng)的運作。6. 多態(tài) (Pol

4、ymorphism)將職責分配給多個具有同名方法的多態(tài)子類，運行時根據(jù)需要動態(tài)切換子類，讓系統(tǒng)行為變得可插拔。7. 純虛構(gòu) (Pure Fabrication)針對真實問題域中不存在，但是設(shè)計建模中有用的概念，設(shè)計虛構(gòu)類并賦予職責。8. 間接 (Indirection)在兩個或者多個對象間有交互的情況下，為避免直接耦合，提高重用性，創(chuàng)建中間類并賦予職責，對象的交互交由中間類協(xié)調(diào)。9. 受保護的變化 (Protected Variation)簡單講就是封裝變化。識別系統(tǒng)中可能的不穩(wěn)定或者變化，在不穩(wěn)定組件上創(chuàng)建穩(wěn)定的抽象接口，將可能的變化封裝在接口之后，使得系統(tǒng)內(nèi)部的不穩(wěn)定或者變化不會對系統(tǒng)的其

5、它部分產(chǎn)生不良影響。SOLID 面向?qū)ο笤O(shè)計原則 S.O.L.I.D 是面向?qū)ο笤O(shè)計和編程 (OOD&OOP) 中幾個重要原則的首字母縮寫，受 Robert Martin 推崇。1. 單一職責原則 (The Single Responsibility Principle)修改某個類的理由應(yīng)該只有一個，如果超過一個，說明類承擔不止一個職責，要視情況拆分。2. 開放封閉原則 (The Open Closed Principle)軟件實體應(yīng)該對擴展開放，對修改封閉。一般不要直接修改類庫源碼（即使你有源代碼），通過繼承等方式擴展。3. 里氏替代原則 (The Liskov Substitution P

6、rinciple)當一個子類的實例能夠被替換成任何超類的實例時，它們之間才是真正的 is-a 關(guān)系。4. 依賴倒置原則 (The Dependency Inversion Principle)高層模塊不應(yīng)該依賴于底層模塊，二者都應(yīng)該依賴于抽象。換句話說，依賴于抽象，不要依賴于具體實現(xiàn)。比方說，你不會把電器電源線焊死在室內(nèi)電源接口處，而是用標準的插頭插在標準的插座 (抽象) 上。5. 接口分離原則 (The Interface Segregation Principle)不要強迫用戶去依賴它們不使用的接口。換句話說，使用多個專門的接口比使用單一的大而全接口要好。我的解讀 我職業(yè)早年主要關(guān)注軟件設(shè)

7、計和編程，所以花蠻多時間學(xué)習和消化 GRASP 和 SOLID 設(shè)計原則。這些原則對我影響很深，尤其是單一職責，信息專家，關(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)了：單一職責：一個微服務(wù)盡可能要職責單一，提供的接口也盡可能單一 (接口分離原則)，安全 / 路由 / 限流等跨橫切面的關(guān)注點 (Cross-Cutt

8、ing Concerns) 由獨立網(wǎng)關(guān)負責，體現(xiàn)關(guān)注分離 (Separation of Concerns)。信息專家：當不確定哪個團隊應(yīng)該負責某個微服務(wù)時，一般原則也是誰擁有數(shù)據(jù)誰負責，基于有界上下文 Bounded Context（一般是邊界比較清晰的領(lǐng)域數(shù)據(jù)源）構(gòu)建微服務(wù)。松散耦合：服務(wù)之間通過 HTTP/JSON 等輕量機制通信，服務(wù)之間不強耦合。受保護的變化和依賴倒置：服務(wù)之間只依賴抽象接口，實現(xiàn)可能隨時變化。間接：網(wǎng)關(guān)在外面的客戶端和內(nèi)部的服務(wù)之間增加了一層間接，使兩者不強耦合，可以相互獨立演化。作為架構(gòu)師或者設(shè)計師，有兩個設(shè)計能力是需要重點培養(yǎng)的，也是最難和最能體現(xiàn)架構(gòu)設(shè)計水平的：

9、合理的職責分配能力，也就是每個類 / 組件 / 子系統(tǒng)應(yīng)該承擔什么職責，如何保證職責單一，它們之間如何協(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)演進，在一線實戰(zhàn)經(jīng)驗的基礎(chǔ)上總結(jié)并提煉出 15 條架構(gòu)原則：1.N + 1 設(shè)計永遠不要少于兩個，通常為三個。比方說無狀態(tài)的 Web/A

10、PI 一般部署至少=2 個。2. 回滾設(shè)計確保系統(tǒng)可以回滾到以前發(fā)布過的任何版本。可以通過發(fā)布系統(tǒng)保留歷史版本，或者代碼中引入動態(tài)開關(guān)切換機制 (Feature Switch)。3. 禁用設(shè)計能夠關(guān)閉任何發(fā)布的功能。新功能隱藏在動態(tài)開關(guān)機制 (Feature Switch) 后面，可以按需一鍵打開，如發(fā)現(xiàn)問題隨時關(guān)閉禁用。4. 監(jiān)控設(shè)計在設(shè)計階段就必須考慮監(jiān)控，而不是在實施完畢之后補充。例如在需求階段就要考慮關(guān)鍵指標監(jiān)控項，這就是度量驅(qū)動開發(fā) (Metrics Driven Development) 的理念。5. 設(shè)計多活數(shù)據(jù)中心不要被一個數(shù)據(jù)中心的解決方案把自己限制住。當然也要考慮成本和公司

11、規(guī)模發(fā)展階段。6. 使用成熟的技術(shù)只用確實好用的技術(shù)。商業(yè)組織畢竟不是研究機構(gòu)，技術(shù)要落地實用，成熟的技術(shù)一般坑都被踩平了，新技術(shù)在完全成熟前一般需要踩坑躺坑。7. 異步設(shè)計能異步盡量用異步，只有當絕對必要或者無法異步時，才使用同步調(diào)用。8. 無狀態(tài)系統(tǒng)盡可能無狀態(tài)，只有當業(yè)務(wù)確實需要，才使用狀態(tài)。無狀態(tài)系統(tǒng)易于擴展，有狀態(tài)系統(tǒng)不易擴展且狀態(tài)復(fù)雜時更易出錯。9. 水平擴展而非垂直升級永遠不要依賴更大、更快的系統(tǒng)。一般公司成長到一定階段普遍經(jīng)歷過買更大、更快系統(tǒng)的階段，即使淘寶當年也買小型機扛流量，后來扛不住才體會這樣做不 scalable，所以才有后來的去 IOE 行動。10. 設(shè)計時至少要有

12、兩步前瞻性在擴展性問題發(fā)生前考慮好下一步的行動計劃。架構(gòu)師的價值就體現(xiàn)在這里，架構(gòu)設(shè)計對于流量的增長要有提前量。11. 非核心則購買如果不是你最擅長，也提供不了差異化的競爭優(yōu)勢則直接購買。避免 Not Invented Here 癥狀，避免凡事都要重造輪子，畢竟達成業(yè)務(wù)目標才是重點。12. 使用商品化硬件在大多數(shù)情況下，便宜的就是最好的。這點和第 9 點是一致的，通過商品化硬件水平擴展，而不是買更大、更快的系統(tǒng)。13. 小構(gòu)建、小發(fā)布和快試錯全部研發(fā)要小構(gòu)建，不斷迭代，讓系統(tǒng)不斷成長。這個和微服務(wù)理念一致。14. 隔離故障實現(xiàn)故障隔離設(shè)計，通過斷路保護避免故障傳播和交叉影響。通過艙壁泳道等機制

13、隔離失敗單元 (Failure Unit)，一個單元的失敗不至影響其它單元的正常工作。15. 自動化設(shè)計和構(gòu)建自動化的過程。如果機器可以做，就不要依賴于人。自動化是 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)

14、，可用性 / 可擴展性 / 質(zhì)量，成本 / 效率分布在三個環(huán)內(nèi)，如下圖所示。12 要素應(yīng)用 Heroku附錄 3 是國外知名的云應(yīng)用平臺。基于上百萬應(yīng)用的托管和運營經(jīng)驗，創(chuàng)始人 Adam Wiggins 提出了 12 要素應(yīng)用宣言 附錄 4。簡單講，滿足這 12 個要素的應(yīng)用是比較容易云化并居住在 Heroku 平臺上的。1. 基準代碼一份基準代碼，多份部署。如果用鏡像部署方式，則一個鏡像可以部署到多個環(huán)境 (測試，預(yù)發(fā)，生產(chǎn))，而不是給每個環(huán)境制作一個不同鏡像。2. 依賴顯式聲明依賴。如果用鏡像部署，則一般依賴被直接打在鏡像中，或者聲明在 docker file 中。3. 配置在環(huán)境中存儲配

15、置。在 Heroku 或者類似的 PaaS 平臺上，配置一般是推薦注入到環(huán)境變量中的。現(xiàn)在采用集中式配置中心也是一種流行方式。4. 后端服務(wù)把后端服務(wù) (例如緩存，數(shù)據(jù)庫，MQ 等) 當作附加資源，相關(guān)配置和連接字符串通過環(huán)境變量注入，或者采用配置中心。5. 構(gòu)建、發(fā)布和運行嚴格分離構(gòu)建和運行。如果使用鏡像部署，則構(gòu)建、發(fā)布 / 運行是通過鏡像這種中間格式嚴格分離的。6. 進程一個或者多個無狀態(tài)的進程運行應(yīng)用。容器運行時相當于進程，適用于無狀態(tài) Web/API。7. 端口綁定通過端口綁定提供服務(wù)。容器也是通過端口綁定對外提供服務(wù)。8. 并發(fā)通過進程模型進行擴展。容器運行時相當于進程，通過起多個

16、容器可以任意擴展并發(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)，負載均衡，服務(wù)發(fā)現(xiàn)，后臺服務(wù)，監(jiān)控告警等要盡可能一致。11. 日志把日志當作數(shù)據(jù)流。Heroku 不支持本地文件，所以必須以流方式把日志輸送到后臺日志服務(wù)。除了日志以外還要補充考慮 metrics 流的采集和輸送。12. 管理進程后臺管理任務(wù)當作一次性的進程。其實相當于在 Heroku 上以獨立進程方式運行任務(wù) Job。我的

17、解讀 12 要素應(yīng)用也是當前云原生應(yīng)用 (Cloud Native App) 的參考標準，我把這 12 要素也稱為云應(yīng)用遷移原則。滿足這 12 個要素的應(yīng)用，可以比較順利遷移到各種云平臺 (Kubernetes, Marathon, Cloud Foundry 等) 上。對于面臨企業(yè)遺留應(yīng)用改造和云化遷移的架構(gòu)師，可以重點參考這 12 條遷移原則。Docker 容器技術(shù)可以認為是為云遷移量身定制的技術(shù)。容器化是后續(xù)云遷移的捷徑，所以遺留應(yīng)用改造可以先想辦法做到容器化。CAP 定理 2000 年 7 月，加州大學(xué)伯克利分校的 Eric Brewer 教授在 ACM PODC 會議上提出 CAP

18、猜想。2 年后，麻省理工學(xué)院的 Seth Gilbert 和 Nancy Lynch 從理論上證明了 CAP。之后，CAP 理論正式成為分布式計算領(lǐng)域的公認定理。CAP 認為：一個分布式系統(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

19、 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 理論 eBay 架構(gòu)師 Dan Pritchett 基于對大規(guī)模分布式系統(tǒng)的實踐總結(jié)，在 ACM 上發(fā)表文章提出了 BASE 理論，BASE 理論是對

20、于 CAP 理論的延伸，核心思想是即使無法做到強一致性 (Strong Consistency，CAP 中的一致性指強一致性)，但是可以采用適當?shù)姆绞竭_到最終一致性 (Eventual Consistency)。BASE 指基本可用 (Basically Available)、軟狀態(tài) (Soft State) 和最終一致性 (Eventual Consistency)。1.基本可用 (Basically Available)基本可用是指分布式系統(tǒng)在出現(xiàn)故障時，允許損失部分可用性，即保證核心可用。比如服務(wù)降級。2.軟狀態(tài) (Soft State)軟狀態(tài)是指允許系統(tǒng)存在中間狀態(tài)，而該中間狀態(tài)不會影

21、響系統(tǒng)的整體可用性。分布式存儲中一般一份數(shù)據(jù)至少存三個副本，允許不同節(jié)點間副本同步的延遲就是軟狀態(tài)的體現(xiàn)。3.最終一致性 (Eventual Consistency)最終一致性是指系統(tǒng)中的所有數(shù)據(jù)副本經(jīng)過一段時間后，最終能夠達成一致狀態(tài)。弱一致性和強一致性相反，最終一致性是弱一致性的一種特殊情況。我的解讀 CAP 和 BASE 理論可以摳得很深，背后甚至有很復(fù)雜的數(shù)學(xué)證明。我理解得相對簡單淺顯：性能、高可用、不丟數(shù)據(jù)和數(shù)據(jù)一致性對分布式系統(tǒng)來說一般是強需求，隨著流量的增長，復(fù)制和分區(qū)在所難免：復(fù)制 (replication)：數(shù)據(jù)在多個節(jié)點上存多份保證不丟和高可用；分區(qū) (partition)

22、：數(shù)據(jù)按某個緯度切分分布在不同節(jié)點上分攤流量壓力保證高性能，同時也是為了降低每個節(jié)點的復(fù)雜性。例如數(shù)據(jù)庫的分庫分表，系統(tǒng)拆分微服務(wù)化也是一種分區(qū)。這兩者都會帶來一致性問題，一致性在時間上有一點妥協(xié)的余地 - 即是最終一致性；時間上要求強一致的話，只有可用性可以適當折中。系統(tǒng)架構(gòu)的游戲很大部分是和狀態(tài)一致性作斗爭的游戲。選擇使用分布式產(chǎn)品時，比如 NoSQL 數(shù)據(jù)庫，你需要了解它在 CAP 環(huán)中所在的位置，確保它滿足你的場景需要。組織和系統(tǒng)改進原則 康威法則 Melvin Conway 在 1967 年提出所謂康威法則 附錄 5，指出組織架構(gòu)和系統(tǒng)架構(gòu)之間有一種隱含的映射關(guān)系：Organizat

23、ion which design system are constrained to produce designs which are copies of the communication structures of these organization. 設(shè)計系統(tǒng)的組織其產(chǎn)生的設(shè)計等價于組織間的溝通結(jié)構(gòu)。康威法則也可以倒過來闡述：Conways law reversed：You wont be able to successfully establish an efficient organization structure that is not supported by your s

24、ystem design(architecture)。 如果系統(tǒng)架構(gòu)不支持，你無法建立一個高效的組織；同樣，如果你的組織架構(gòu)不支持，你也無法建立一個高效的系統(tǒng)架構(gòu)。系統(tǒng)改進三原則 IT 運維管理暢銷書鳳凰項目附錄 8 的作者 Gene Kim 在調(diào)研了眾多高效能 IT 組織后總結(jié)出支撐 DevOps 運作的三個原理 (The Three Ways: The Principles Underpinning DevOps)附錄 9，我認為也是系統(tǒng)改進提升的一般性原理 附錄 7，見下圖：原理一：系統(tǒng)思考 (System Thinking)開發(fā)驅(qū)動的組織，其能力不是制作軟件，而是持續(xù)的交付客戶價值。價值從業(yè)務(wù)需求開始，經(jīng)過研發(fā)測試，到部署運維，依次流動，并最終以服務(wù)形式交付到客戶手中。整個價值鏈流速并不依賴單個部分 (團隊或個人) 的杰出工作，而是受整個價值鏈最薄弱環(huán)節(jié) (瓶頸) 的限制。所以局部優(yōu)化通常無效，反而招致全局受損。Gene Kim 特別指出：Any improvements made anywhere besides the bottleneck are an illusion. 在瓶頸之外的任何優(yōu)化提升都只是幻象。原理二：強化反饋環(huán) (Amplify Feedback Loops)過程改進常常通過加強反饋環(huán)來達成。原理二強調(diào)