目錄

?

一、前言

二、軟件設計原則

GRASP通用職責分配軟件模式

1. 信息專家(Information Expert)

2. 創建者(Creator)

3. 低耦合(Low Coupling)

4. 高內聚(High Cohesion)

5.控制器(Controller)

6. 多態(Polymorphism)

7. 純虛構(Pure Fabrication)

8. 間接(Indirection)

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

SOLID面向對象設計原則

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

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

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

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

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

我的解讀

三、分布式系統架構設計原則和理論

AKF架構原則

1. N + 1設計

2. 回滾設計

3. 禁用設計

4. 監控設計

5. 設計多活數據中心

6. 使用成熟的技術

7. 異步設計

8. 無狀態系統

9. 水平擴展而非垂直升級

10. 設計時至少要有兩步前瞻性

11. 非核心則購買

12. 使用商品化硬件

13. 小構建、小發布和快試錯

14. 隔離故障

15. 自動化

我的解讀

十二要素應用

1. 基準代碼

2. 依賴

3. 配置

4. 后端服務

5. 構建、發布和運行

6. 進程

7. 端口綁定

8. 并發

9. 易處理

10. 開發環境和線上環境等價

11. 日志

12. 管理進程

我的解讀

CAP定理

1. 一致性(Consistency)

2. 可用性(Availability)

3. 分區容忍性(Partition tolerance)

BASE理論

1. 基本可用(Basically Available)

2. 軟狀態(Soft State)

3. 最終一致性(Eventual Consistency)

我的解讀

四、組織和系統改進原則

康威法則

系統改進三原則

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

原理二：強化反饋環(Amplify Feedback Loops)

原理三：持續試驗和學習的文化(Culture of Continual Experimentation And Learning)

我的解讀

五、寫在最后

六、參考

---

一、前言

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

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

二、軟件設計原則

GRASP通用職責分配軟件模式

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

1. 信息專家(Information Expert)

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

2. 創建者(Creator)

將創建A的職責賦給B，如果至少下面一種情況為真：

• B“包含”或者聚合A
• B記錄A的實例
• B密切地使用A
• B擁有A的初始化數據

3. 低耦合(Low Coupling)

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

4. 高內聚(High Cohesion)

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

5.控制器(Controller)

把職責賦予系統、設備或者子系統的表示類(門面控制器)，或者某個用例的表示類(用例控制器)，讓控制器接收事件并協調整個系統的運作。

6. 多態(Polymorphism)

將職責分配給多個具有同名方法的多態子類，運行時根據需要動態切換子類，讓系統行為變得可插拔。

7. 純虛構(Pure Fabrication)

針對真實問題域中不存在，但是設計建模中有用的概念，設計虛構類并賦予職責。

8. 間接(Indirection)

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

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

簡單講就是封裝變化。識別系統中可能的不穩定或者變化，在不穩定組件上創建穩定的抽象接口，將可能的變化封裝在接口之后，使得系統內部的不穩定或者變化不會對系統的其它部分產生不良影響。

SOLID面向對象設計原則

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

修改某個類的理由應該只有一個，如果超過一個，說明類承擔不止一個職責，要視情況拆分。

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

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

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

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

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

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

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

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

我的解讀

我職業早年主要關注軟件設計和編程，所以花蠻多時間學習和消化GRASP和SOLID設計原則。這些原則對我影響很深，尤其是單一職責，信息專家，關注分離，依賴倒置/封裝變化，分而治之等核心原則，現在日常研發中我時常用這些原則指導新手工程師。

高內聚+低耦合，就像道中的一陰一陽，是所有其它OO設計原則的原則(元原則)，其它設計原則都是在這兩個基礎上泛化衍生出來的。

上述原則雖然是針對OO設計和編程提出，但是對于大規模系統架構仍然適用。比如，微服務架構就體現了：

• 單一職責：一個微服務盡可能要職責單一，提供的接口也盡可能單一(接口分離原則)，安全/路由/限流等跨橫切面的關注點(Cross-Cutting Concerns)由獨立網關負責，體現關注分離(Separation of Concerns)。
• 信息專家：當不確定哪個團隊應該負責某個微服務時，一般原則也是誰擁有數據誰負責，基于有界上下文Bounded Context（一般是邊界比較清晰的領域數據源）構建微服務。
• 松散耦合：服務之間通過HTTP/JSON等輕量機制通信，服務之間不強耦合。
• 受保護的變化和依賴倒置：服務之間只依賴抽象接口，實現可能隨時變化。
• 間接：網關在外面的客戶端和內部的服務之間增加了一層間接，使兩者不強耦合，可以相互獨立演化。

作為架構師或者設計師，有兩個設計能力是需要重點培養的，也是最難和最能體現架構設計水平的：

• 合理的職責分配能力，也就是每個類/組件/子系統應該承擔什么職責，如何保證職責單一，它們之間如何協作；
• 系統抽象和核心領域建模能力，需要深入一線業務域。

三、分布式系統架構設計原則和理論

AKF架構原則

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

1. N + 1設計

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

2. 回滾設計

確保系統可以回滾到以前發布過的任何版本。可以通過發布系統保留歷史版本，或者代碼中引入動態開關切換機制(Feature Switch)。

3. 禁用設計

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

4. 監控設計

在設計階段就必須考慮監控，而不是在實施完畢之后補充。例如在需求階段就要考慮關鍵指標監控項，這就是度量驅動開發(Metrics Driven Development)的理念。

5. 設計多活數據中心

不要被一個數據中心的解決方案把自己限制住。當然也要考慮成本和公司規模發展階段。

6. 使用成熟的技術

只用確實好用的技術。商業組織畢竟不是研究機構，技術要落地實用，成熟的技術一般坑都被踩平了，新技術在完全成熟前一般需要踩坑躺坑。

7. 異步設計

能異步盡量用異步，只有當絕對必要或者無法異步時，才使用同步調用。

8. 無狀態系統

盡可能無狀態，只有當業務確實需要，才使用狀態。無狀態系統易于擴展，有狀態系統不易擴展且狀態復雜時更易出錯。

9. 水平擴展而非垂直升級

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

10. 設計時至少要有兩步前瞻性

在擴展性問題發生前考慮好下一步的行動計劃。架構師的價值就體現在這里，架構設計對于流量的增長要有提前量。

11. 非核心則購買

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

12. 使用商品化硬件

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

13. 小構建、小發布和快試錯

全部研發要小構建，不斷迭代，讓系統不斷成長。這個和微服務理念一致。

14. 隔離故障

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

15. 自動化

設計和構建自動化的過程。如果機器可以做，就不要依賴于人。自動化是DevOps的基礎。

我的解讀

這15條架構原則基本上是eBay在發展，經歷過流量數量級增長沖擊過程中，通過不斷踩坑踩出來的，是干貨中的干貨。消化吸收這15條原則，基本可保系統架構不會有原則性問題。

這15條原則同樣適用于現在的微服務架構。eBay發展較早，它內部其實很早(差不多2010年前)就已形成完善的微服務生態，只是沒有提出微服務這個概念。

這15條原則可根據TTM(Time To Market)，可用性/可擴展性/質量，成本/效率分布在三個環內，如下圖所示:

十二要素應用

Heroku[附錄3]是國外知名的云應用平臺。基于上百萬應用的托管和運營經驗，創始人Adam Wiggins提出了12要素應用宣言[附錄4]。簡單講，滿足這12個要素的應用是比較容易云化并居住在Heroku平臺上的。

1. 基準代碼

一份基準代碼，多份部署。如果用鏡像部署方式，則一個鏡像可以部署到多個環境(測試，預發，生產)，而不是給每個環境制作一個不同鏡像。

2. 依賴

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

3. 配置

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

4. 后端服務

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

5. 構建、發布和運行

嚴格分離構建和運行。如果使用鏡像部署，則構建、發布/運行是通過鏡像這種中間格式嚴格分離的。

6. 進程

一個或者多個無狀態的進程運行應用。容器運行時相當于進程，適用于無狀態Web/API。

7. 端口綁定

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

8. 并發

通過進程模型進行擴展。容器運行時相當于進程，通過起多個容器可以任意擴展并發數量。

9. 易處理

快速啟動和優雅終止可最大化健壯性。docker容器支持秒級啟動和關閉。

10. 開發環境和線上環境等價

盡可能保持開發、測試、預發和線上環境相同。容器可以保證容器內運行時環境的一致性，還需要保證不同環境的一致性，例如不同環境內的操作系統，負載均衡，服務發現，后臺服務，監控告警等要盡可能一致。

11. 日志

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

12. 管理進程

后臺管理任務當作一次性的進程。其實相當于在Heroku上以獨立進程方式運行任務Job。

我的解讀

12要素應用也是當前云原生應用(Cloud Native App)的參考標準，我把這12要素也稱為云應用遷移原則。滿足這12個要素的應用，可以比較順利遷移到各種云平臺(Kubernetes, Marathon, Cloud Foundry等)上。

對于面臨企業遺留應用改造和云化遷移的架構師，可以重點參考這12條遷移原則。

Docker容器技術可以認為是為云遷移量身定制的技術。容器化是后續云遷移的捷徑，所以遺留應用改造可以先想辦法做到容器化。

CAP定理

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

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

1. 一致性(Consistency)

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

2. 可用性(Availability)

可用性指“Reads and writes always succeed”，即服務一直可用，而且響應時間正常。

3. 分區容忍性(Partition tolerance)

分區容忍性指“the system continue to operate despite arbitrary message loss or failure of part of the system.”，即分布式系統在遇到某節點或網絡分區故障時，仍然能夠對外提供滿足一致性和可用性的服務。

BASE理論

eBay架構師Dan Pritchett基于對大規模分布式系統的實踐總結，在ACM上發表文章提出了BASE理論，BASE理論是對于CAP理論的延伸，核心思想是即使無法做到強一致性(Strong Consistency，CAP中的一致性指強一致性)，但是可以采用適當的方式達到最終一致性(Eventual Consistency)。

BASE指基本可用(Basically Available)、軟狀態(Soft State)和最終一致性(Eventual Consistency)。

1. 基本可用(Basically Available)

基本可用是指分布式系統在出現故障時，允許損失部分可用性，即保證核心可用。比如服務降級。

2. 軟狀態(Soft State)

軟狀態是指允許系統存在中間狀態，而該中間狀態不會影響系統的整體可用性。分布式存儲中一般一份數據至少存三個副本，允許不同節點間副本同步的延遲就是軟狀態的體現。

3. 最終一致性(Eventual Consistency)

最終一致性是指系統中的所有數據副本經過一段時間后，最終能夠達成一致狀態。弱一致性和強一致性相反，最終一致性是弱一致性的一種特殊情況。

我的解讀

CAP和BASE理論可以摳得很深，背后甚至有很復雜的數學證明。我理解得相對簡單淺顯：性能、高可用、不丟數據和數據一致性對分布式系統來說一般是強需求，隨著流量的增長，復制和分區在所難免：

• 復制(replication)：數據在多個節點上存多份保證不丟和高可用；
• 分區(partition)：數據按某個緯度切分分布在不同節點上分攤流量壓力保證高性能，同時也是為了降低每個節點的復雜性。例如數據庫的分庫分表，系統拆分微服務化也是一種分區。
  這兩者都會帶來一致性問題，一致性在時間上有一點妥協的余地-即是最終一致性；時間上要求強一致的話，只有可用性可以適當折中。系統架構的游戲很大部分是和狀態一致性作斗爭的游戲。

選擇使用分布式產品時，比如NoSQL數據庫，你需要了解它在CAP環中所在的位置，確保它滿足你的場景需要。

四、組織和系統改進原則

康威法則

Melvin Conway在1967年提出所謂康威法則[附錄5]，指出組織架構和系統架構之間有一種隱含的映射關系：

Organization which design system […] are constrained to produce designs which are copies of the communication structures of these organization. 設計系統的組織其產生的設計等價于組織間的溝通結構。

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

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)。 如果系統架構不支持，你無法建立一個高效的組織；同樣，如果你的組織架構不支持，你也無法建立一個高效的系統架構。

系統改進三原則

IT運維管理暢銷書《鳳凰項目》[附錄8]的作者Gene Kim在調研了眾多高效能IT組織后總結出支撐DevOps運作的三個原理(The Three Ways: The Principles Underpinning DevOps)[附錄9]，我認為也是系統改進提升的一般性原理[附錄7]，見下圖：

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

開發驅動的組織，其能力不是制作軟件，而是持續的交付客戶價值。價值從業務需求開始，經過研發測試，到部署運維，依次流動，并最終以服務形式交付到客戶手中。整個價值鏈流速并不依賴單個部分(團隊或個人)的杰出工作，而是受整個價值鏈最薄弱環節(瓶頸)的限制。所以局部優化通常無效，反而招致全局受損。

Gene Kim特別指出：

Any improvements made anywhere besides the bottleneck are an illusion. 在瓶頸之外的任何優化提升都只是幻象。

原理二：強化反饋環(Amplify Feedback Loops)

過程改進常常通過加強反饋環來達成。原理二強調企業和客戶之間、組織團隊間、流程上和系統內的反饋環。沒有測量就沒有提升，反饋要以測量數據為準，通過反饋數據優化改進系統。

原理三：持續試驗和學習的文化(Culture of Continual Experimentation And Learning)

在企業管理文化層面強調勇于試錯和持續試驗、學習和改進的文化。

我的解讀

康威法則給我們的啟示：系統架構和組織架構之間有隱含的映射關系，你不能單方面改變一方的結構，調整時必須兩邊聯動。系統架構如果是耦合的，就很難組織分散式的團隊結構，兩邊映射不起來，團隊之間容易摩擦導致生產率下降。所以一般先按業務邊界對單塊應用進行解耦拆分，同時做相應的團隊拆分，使兩邊可以映射，每個團隊可以獨立開發、測試和部署各自的微服務，進而提升生產率。這就是近年流行的微服務架構背后的組織原則。詳見我之前發表的文章《企業的組織架構是如何影響技術架構的》[附錄6]。

系統思考要求我們加強團隊合作，培養流式思維和瓶頸約束思維，找出瓶頸并針對性地優化。在研發型組織中，常見的系統瓶頸如運維機器資源提供(Provisioning)緩慢，發布流程繁瑣容易出錯，開發/測試／UAT環境缺失或不完善，遺留系統耦合歷史負擔重，基礎研發平臺薄弱等等。這些瓶頸點特別需要關注優化。

反饋原理要求我們關注基于數據的反饋，技術上的手段包括大數據分析和系統各個層次的測量監控。沒有測量就沒有反饋，沒有反饋就沒有提升。

在管理文化層面：

• 管理層要承認企業內部近50%的創新或流程改進項目是有可能失敗的，即使失敗，員工不會受到責罰，鼓勵持續的試驗和從中學習；
• 管理層要有技術償債意識，勿追求100%員工利用率，要預留20%~30%的時間給員工做創新和系統改進提升項目。

五、寫在最后

上述原則是架構師必須深入理解和掌握的，但是不能盲從，實際工作中要根據業務、時間、資源和團隊情況隨機應變。原則有時甚至可以被違反，當然這樣做一定有成本，架構師要意識這一點，并適時變通補償。

上述原則僅是我個人視角總結，有些理解難免偏頗。如果你認為我忽略了哪些重要的原則，或理解有誤，請記得線下和我交流！

六、參考

UML和模式應用(原書第3版)

架構即未來：現代企業可擴展的Web架構、流程和組織(原書第2版)

Heroku云應用平臺

The Twelve-Factor App

康威法則

企業的組織架構是如何影響技術架構的

痛定思痛，談成長型公司應該如何突破方輪子困局!

鳳凰項目：一個IT運維的傳奇故事

The Three Ways: The Principles Underpinning DevOps

作者：架構師波波?
來源：CSDN?
原文：https://blog.csdn.net/yang75108/article/details/86982867?
版權聲明：本文為博主原創文章，轉載請附上博文鏈接！

?

總結

以上是生活随笔為你收集整理的架构师必须知道的架构设计原则的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。