作者：京東科技 皮亮

1. 什麼是複雜系統

我們經常提到複雜系統，那麼到底什麼是複雜系統。我們看下維基的定義：複雜系統（英語：complex system），又稱複合系統，是指由許多可能相互作用的組成成分所組成的系統。強調了兩點：

1. 由點組成
2. 點之間有各種關聯

兩點的規模和複雜性直接決定了系統的複雜程度。比如就拿我們的電商系統舉例，分成很多部分，商品、庫存、採購、訂單、物流、財務，這個只是大的分類，還有針對C端的營銷、會員、購買、售後等體系，針對B端的商家入駐、管理等體系。各個部分、體系之間有著千絲萬縷的聯繫，可謂之複雜系統了。當然了，遠遠不止這些，隨著業務複雜性的不斷提升，整個系統的複雜性也會愈來愈複雜。

2. 什麼是架構

生活中我們經常談及“架構”，那麼到底什麼是“架構”，Robert C.Martin《架構整潔之道》中的定義：軟體架構是指設計軟體的人為軟體賦予的形狀，這個形狀是指系統如何被劃分為組件(Components)，各個組件如何排列（Arrangement），組件之間如何溝通（Communication，通訊），維基百科的定義：有關軟體整體結構與組件的抽象描述，用於指導大型軟體系統各個方面的設計,IEEE的定義：架構 = 組成單元的結構 + 組成單元的關係 + 原則和指南，總體來看會包括幾個內容：

1. 整體：強調部分的組成，強調合力
2. 規則：強調部分之間有關聯關係，有規則，有約束
3. 通信：強調部分之間有往來，有交互

這樣說來，我們人類社會本身就是一個社會架構，各種職責、分工、圈層，就我們的軟體系統來說，DDD是架構，MVC也是架構，大數據設計也有大數據的架構。所以架構無處不在，好的架構能夠對特定的問題，特定的領域起到規範和指導作用。

3. 架構的本質

我們知道，架構這個詞是源於建築行業的，英文原詞是：Architecture，維基百科上的解釋是規劃、設計和建造建築物的過程及產物。那我們就用建築行業來理解一下。建房子對大家而言再熟悉不過了，那我們蓋個小平層、蓋個兩層小高層、蓋個5層小高層、搞個10層、蓋個幾百層的摩天大樓的過程、因素、風險是完全不同的。蓋摩天大樓需要付出的成本更高，過程中的不確定性更多，挑戰和風險也更大，例如如何選地、選擇什麼樣的結構，如何承重，採光如何控制，優化、如何取暖，如何上水、排水，如何通風，如何避震等等。這些東西我們考慮的越多，房子未來的質量，可控性也會越好。

所以架構本質上就是一種指導型的約束，以約定整體和部分、部分和部分之間的關係，以使整體更加穩定，更加可靠。

4. 架構分類

我們上面舉的例子我們可以叫做建築架構，實際上架構有很多種類型，比如業務架構，應用架構，技術架構，數據架構等。單個架構分類，站在不同的維度也會有不同的看法，複雜性也會有相當大的區別。比如企業級架構能夠凸顯出公司的整體戰略，業務涉及情況，分佈情況，發力情況。而某一個單一的業務線也同樣有自己的業務架構，凸顯單獨業務自己的業務目標、戰略等。應用架構、技術架構也是同理，會有不同層面視野的架構。我們下麵就以業務線內部視角對我們常見的架構分離進行下簡單的說明。

4.1. 業務架構

說到業務架構，偏頂層設計了，業務的定義和劃分甚至會影響到整個公司整體組織架構的設立和關係。業務架構偏向業務領域劃分，模型設計，對整體業務進行語言轉化，內化為領域通用語言。

4.2. 應用架構

體現應用內部的結構關係。應用如何進行設計，包括模塊如何劃分，功能如何實現，技術如何支撐，數據如何展示，流程如何定義，邏輯如何實現，數據如何存儲等等，都是應用架構的範疇。我們經常說到的MVC、分層架構、CQRS、DDD傳統洋蔥圈架構、DDD六邊形架構都可以歸結為應用架構的範疇。

4.3. 技術架構

技術架構不一定局限於單個應用內部，尤其是當前微服務架構時代，服務之間如何交互，服務如何治理，數據如何存儲，緩存如何構建等等，都是技術架構的範疇。技術架構給應用和業務架構提供了一個技術基礎，以使業務更好的發展，更健壯的迭代，發展。

5. 架構需要考慮哪些因素

5.1. 功能性需求

無論是什麼架構，我們第一時間考慮的一定是需要滿足我們實際的業務述求的。沒有需求的架構就是相當於空中樓閣，中看不中用，不切實際。這並不是真正的架構。一般來說，功能需求會直接決定業務架構，對應用和技術架構影響不大。我們的架構必須能夠正確、完整地對功能性需求起到支撐作用。

5.2. 非功能性需求

架構滿足功能性需求是第一要務，同時我們需要考慮能夠穩定、可靠的支持功能，也就是我們同時需要滿足一些非功能行需求，比如性能、可靠性、擴展性、相容性等等。

5.3. 可靠性

為了更好的服務於功能，我們需要確保架構能夠穩定、高效的運行。不會時不時的出現服務崩潰或者不可用的情況。

5.4. 可用性

同樣的，服務對外要始終處於可用的狀態，即使單個服務實例出現問題，我們依然可以正常的對外提供服務。

5.5. 擴展性

功能性需求不是一層不變的，尤其在當今盛行敏捷的時代，需求不是一次性提出的。我們需要對系統、服務的整體能力有全面的定位和把控。這就需要我們的架構在新的需求出現的時候，可以方便的進行擴展支持。

5.6. 治理能力

好的架構一定是方便運營、管理和監控的。甚至微觀到工程管理，代碼一定是易於維護、擴展、協同的。

5.7. 響應性能

一般的，功能性需求都會對性能有一定的預期。這個業務要我們在架構上做很多工作，比如讀寫分離、緩存、非同步等等的介入，以滿足整體架構的響應能力。

6. 複雜系統如何分析

有的同學會有誤區，一想到類似這樣的系統就覺得會有很大的複雜性，就會考慮知難而退。但是你所認為的難不一定是難。我們都知道一句熟語：“難者不會，會者不難”，往往會由於大家經驗的不同，對待同一問題的想法和思路就都會不一樣。這也就是為什麼我們會在系統設計的時候，強調專家的重要性。尤其是目前又被逐漸提及並廣泛應用的DDD領域驅動設計方法，更加提倡領域專家的重要性。這樣才能夠識別現實問題的複雜性和根本痛點所在，進而能夠客觀合理的推導出可靠、合適的解決方案。很明顯，複雜系統設計中非常重要的兩個環節：需求分析、架構設計。需求分析過程中，我們需要確認需求到底要解決什麼問題，面向的角色有哪些。現在流行的分析方法要數DDD領域驅動的分析方法。使用DDD的模式分析業務需求大概會有幾個步驟：

1. 確認角色
2. 確認角色功能
3. 確認問題子域
4. 確認模型、事件、歸屬
5. 確認界限上下文

7. 複雜系統的設計原則

1. 識別出核心問題：對於需求的承接，有些人會直接進行入開發設計階段，尤其是對於出入職場的小伙伴。其實遇到需求我們更多的需要思考，為什麼要做這個需求，這個想明白，非常有助於我們進行業務等相關的架構設計，進而掌舵整個需求。這樣不會很容易的走入偏路。
2. 複雜的問題簡單化，需要把複雜的問題拆解成各個小的模塊，進行逐個攻破，各個模塊職責會相對單一，未來的擴展性和可維護性也相對獨立、簡單
3. 確認使用通用的語言進行溝通，尤其是面向領域設計中，領域模型的認識大家一定要保持一致
4. 理清系統、模型的定位、關係、交互等
5. 具備未來的規劃能力，包括系統、技術、方案、容量等等，以使系統能夠長期更好、更穩定的提供價值服務
6. 遵循各種設計模式，最佳實踐，避免從0開始，包括：SOLID設計原則，CAP理論，BASE理論

8. 複雜系統的架構特點

8.1. 重視功能拆解，模塊化設計，原子化設計

複雜系統一定要進行細緻功能、模塊、領域的劃分。每個模塊的都應該有明確，單一的職責。這樣我們在分析問題的時候，可以把問題聚焦在某一個範圍內，不會產生太大的影響，方便整體系統的維護和擴展。

8.2. 縱向 + 橫向拓展能力至關重要

我們做小的功能的時候，可能不會考慮太多。但是複雜系統的時候，必須要考慮很多，包括未來的功能承載、流量承載、數據規模、響應要求等等，這些都需要我們在縱向或者橫向留出足夠的擴展能力。這些不能一蹴而就，但是需要根據規劃留有必要的擴展，以使系統具有長期價值。

8.3. 架構先行

對於複雜系統，已經不是一個或幾個流程圖能解決的事情了。我們需要通過領域架構明確領域劃分及領域邊界，通過系統架構明確功能模塊和功能邊界，通過應用架構明確各個應用的職責、邊界、結構劃分、依賴關係等。通過技術架構明確我們使用的技術棧及在整體系統中的應用邊界。通過數據架構明確我們的數據存儲方式、結構、數據使用方式等。

這些架構一定要清晰，明確，著眼於系統長期價值。

8.4. 分而治之

對於複雜系統，拆分是必然的，大的問題化解成小的問題，根據領域、模塊、功能的劃分，我們把問題歸屬於不同的邊界內，進行逐個攻破。小的問題得道解決，那麼通過合理的依賴和組合，即可有效的解決大的問題，達到整個系統的建設目的。

9. 典型的複雜問題解決架構

隨著社會的不斷進步，信息化組件發達，我們更需要信息化的方式去解決系統化的問題。早前我們更多的通過數據驅動的模式，也就是我們會先去思考會用到什麼樣的結構去存儲相關的數據，模型之間都有什麼樣依賴關係，怎麼樣組織數據，怎麼樣把數據和外圍交互，這些思想也是典型的MVC架構。

MVC架構迫使我們是面向視圖來開發的，我們知道視圖的變化最是不可控的，越是偏向於用戶的東西，越是容易受到用戶主觀的影響。我們知道複雜系統必然存在的紛繁複雜的依賴，依賴不可能存在於視圖部分，肯定會表現為介面的依賴。對於複雜系統，我們要強迫我們轉換思維，強迫我們面向介面進行設計。結合著業務系統的複雜性，如果想要系統未來具有長期價值，不得不把大的系統進行拆分，用統一的業務語言進行描述，把不可識別的問題，拆分成可識別的問題域進行解決，這也就是現在又逐漸盛行起來的領域驅動設計的方法。

9.1. 領域驅動設計

領域驅動設計，強迫我們不再用數據進行驅動，而是使用領域進行驅動。遇到問題，我們先進性領域上的劃分和拆解。這個問題到底屬於哪個問題域，或者需要拆解到哪些問題域，然後再通過領域的組合、依賴完成最終問題的解決。

領域驅動，早在2004年Eric Evans在《Domain-Driven Design : Tackling Complexity in the Heart of Software》（領域驅動設計：軟體核心複雜性應對之道）這本書中就戰略和戰術兩個方面進行了詳細的闡述。

目前來看，對於複雜系統的設計，領域驅動的模式利於系統的可持續發展。

9.2. 微服務架構

其實微服務架構就是早些時候的SOA（面向服務架構）的一種變體。其實這個詞是從2014年Martin Fowler發表的一篇文章《Are Microservices the Future》開始被業界廣傳而火起來的。微服務架構強調去中心化管理，儘可能的保持服務的自治性和獨立性。強調能力通過不同的小的服務進行整合獲取。這樣我們可以對服務進行有選擇的縱向和橫向擴展，同時也避免了單個系統的臃腫和功能的堆疊、耦合。

9.3. 雲原生架構

說到原生，大家再熟悉不過了。比如我們說IOS，Android原生界面，意味著界面是他們本來就支持的。而談到雲原生，對於服務而言，我們更多強調服務先天具有雲上部署、提供服務的能力。這種能力使得服務具有先天的去中心化的能力，先天的橫向擴展的能力。這也是微服務重點強調的能力。

9.4. DevOps架構

DevOps之前，我們也一直在談敏捷，業界也有戰術上的落地方案。比如極限編程、Scrum等等。如果說敏捷更多是為瞭解決需求、產品、研發、測試之間的協同、高效，那麼DevOps更多的是在解決研發、運維間的協同問題。DevOps近年來發展的是如火如荼，這和領域驅動、微服務架構、雲架構技術、虛擬化技術（尤其是Docker的發展）的發展息息相關。準確的說，是各種技術微妙組合的一種共力。DevOps的發展，是的運維不再關心應用的部署等問題，這些事情都可以交給研發來處理，運維更多的在給研發提供自動化的構建、集成、部署、監控等等相關的雲基礎能力。

9.5. 大數據架構

當今的是一個數字化的時代，各行各業都在忙於進行數字化的轉型。對於複雜的業務系統，數據的價值尤顯突出，那麼自然對於海量數據的處理、價值的挖掘訴求是必然存在的。那麼數據的海量存儲、提取、傳輸、清洗、計算、挖掘等能力就需要通過大數據架構的模式進行設計。

10. 總結

現如今，系統設計的關鍵已經變成分散式、雲化、微服務化、大數據化。架構的本質依然沒有改變，只是由於社會的發展，我們的需求，需要處理的問題、依賴愈來愈複雜，我們需要用發展的眼光，時刻追隨技術前沿，進而推進、優化、迭代系統的架構設計。

複雜系統的架構設計不是一蹴而就的，合適的才是正確的。希望本文能夠對您在進行複雜系統設計時有一定的參考意義。