復(fù)雜業(yè)務(wù)系統(tǒng)的通用架構(gòu)設(shè)計法則

一、什么是復(fù)雜系統(tǒng)

我們經(jīng)常提到復(fù)雜系統(tǒng)，那么到底什么是復(fù)雜系統(tǒng)。我們看下維基的定義：復(fù)雜系統(tǒng)（英語：complex system），又稱復(fù)合系統(tǒng)，是指由許多可能相互作用的組成成分所組成的系統(tǒng)。強調(diào)了兩點：

由點組成

點之間有各種關(guān)聯(lián)

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

基于 Spring Boot + MyBatis Plus + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序，支持 RBAC 動態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項目地址：https://github.com/YunaiV/ruoyi-vue-pro

視頻教程：https://doc.iocoder.cn/video/

二、什么是架構(gòu)

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

整體：強調(diào)部分的組成，強調(diào)合力

規(guī)則：強調(diào)部分之間有關(guān)聯(lián)關(guān)系，有規(guī)則，有約束

通信：強調(diào)部分之間有往來，有交互

這樣說來，我們?nèi)祟惿鐣旧砭褪且粋€社會架構(gòu)，各種職責(zé)、分工、圈層，就我們的軟件系統(tǒng)來說，DDD 是架構(gòu)，MVC 也是架構(gòu)，大數(shù)據(jù)設(shè)計也有大數(shù)據(jù)的架構(gòu)。所以架構(gòu)無處不在，好的架構(gòu)能夠?qū)μ囟ǖ膯栴}，特定的領(lǐng)域起到規(guī)范和指導(dǎo)作用。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序，支持 RBAC 動態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項目地址：https://github.com/YunaiV/yudao-cloud

視頻教程：https://doc.iocoder.cn/video/

三、架構(gòu)的本質(zhì)

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

所以架構(gòu)本質(zhì)上就是一種指導(dǎo)型的約束，以約定整體和部分、部分和部分之間的關(guān)系，以使整體更加穩(wěn)定，更加可靠。

四、架構(gòu)分類

我們上面舉的例子我們可以叫做建筑架構(gòu)，實際上架構(gòu)有很多種類型，比如業(yè)務(wù)架構(gòu)，應(yīng)用架構(gòu)，技術(shù)架構(gòu)，數(shù)據(jù)架構(gòu)等。單個架構(gòu)分類，站在不同的維度也會有不同的看法，復(fù)雜性也會有相當(dāng)大的區(qū)別。比如企業(yè)級架構(gòu)能夠凸顯出公司的整體戰(zhàn)略，業(yè)務(wù)涉及情況，分布情況，發(fā)力情況。而某一個單一的業(yè)務(wù)線也同樣有自己的業(yè)務(wù)架構(gòu)，凸顯單獨業(yè)務(wù)自己的業(yè)務(wù)目標、戰(zhàn)略等。應(yīng)用架構(gòu)、技術(shù)架構(gòu)也是同理，會有不同層面視野的架構(gòu)。我們下面就以業(yè)務(wù)線內(nèi)部視角對我們常見的架構(gòu)分離進行下簡單的說明。

1.業(yè)務(wù)架構(gòu)

說到業(yè)務(wù)架構(gòu)，偏頂層設(shè)計了，業(yè)務(wù)的定義和劃分甚至?xí)绊懙秸麄€公司整體組織架構(gòu)的設(shè)立和關(guān)系。業(yè)務(wù)架構(gòu)偏向業(yè)務(wù)領(lǐng)域劃分，模型設(shè)計，對整體業(yè)務(wù)進行語言轉(zhuǎn)化，內(nèi)化為領(lǐng)域通用語言。

2.應(yīng)用架構(gòu)

體現(xiàn)應(yīng)用內(nèi)部的結(jié)構(gòu)關(guān)系。應(yīng)用如何進行設(shè)計，包括模塊如何劃分，功能如何實現(xiàn)，技術(shù)如何支撐，數(shù)據(jù)如何展示，流程如何定義，邏輯如何實現(xiàn)，數(shù)據(jù)如何存儲等等，都是應(yīng)用架構(gòu)的范疇。我們經(jīng)常說到的 MVC、分層架構(gòu)、CQRS、DDD 傳統(tǒng)洋蔥圈架構(gòu)、DDD 六邊形架構(gòu)都可以歸結(jié)為應(yīng)用架構(gòu)的范疇。

3.技術(shù)架構(gòu)

技術(shù)架構(gòu)不一定局限于單個應(yīng)用內(nèi)部，尤其是當(dāng)前微服務(wù)架構(gòu)時代，服務(wù)之間如何交互，服務(wù)如何治理，數(shù)據(jù)如何存儲，緩存如何構(gòu)建等等，都是技術(shù)架構(gòu)的范疇。技術(shù)架構(gòu)給應(yīng)用和業(yè)務(wù)架構(gòu)提供了一個技術(shù)基礎(chǔ)，以使業(yè)務(wù)更好的發(fā)展，更健壯的迭代，發(fā)展。

五、架構(gòu)需要考慮哪些因素

1.功能性需求

無論是什么架構(gòu)，我們第一時間考慮的一定是需要滿足我們實際的業(yè)務(wù)述求的。沒有需求的架構(gòu)就是相當(dāng)于空中樓閣，中看不中用，不切實際。這并不是真正的架構(gòu)。一般來說，功能需求會直接決定業(yè)務(wù)架構(gòu)，對應(yīng)用和技術(shù)架構(gòu)影響不大。我們的架構(gòu)必須能夠正確、完整地對功能性需求起到支撐作用。

2.非功能性需求

架構(gòu)滿足功能性需求是第一要務(wù)，同時我們需要考慮能夠穩(wěn)定、可靠的支持功能，也就是我們同時需要滿足一些非功能行需求，比如性能、可靠性、擴展性、兼容性等等。

3.可靠性

為了更好的服務(wù)于功能，我們需要確保架構(gòu)能夠穩(wěn)定、高效的運行。不會時不時的出現(xiàn)服務(wù)崩潰或者不可用的情況。

4.可用性

同樣的，服務(wù)對外要始終處于可用的狀態(tài)，即使單個服務(wù)實例出現(xiàn)問題，我們依然可以正常的對外提供服務(wù)。

5.擴展性

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

6.治理能力

好的架構(gòu)一定是方便運營、管理和監(jiān)控的。甚至微觀到工程管理，代碼一定是易于維護、擴展、協(xié)同的。

7.響應(yīng)性能

一般的，功能性需求都會對性能有一定的預(yù)期。這個業(yè)務(wù)要我們在架構(gòu)上做很多工作，比如讀寫分離、緩存、異步等等的介入，以滿足整體架構(gòu)的響應(yīng)能力。

六、復(fù)雜系統(tǒng)如何分析

有的同學(xué)會有誤區(qū)，一想到類似這樣的系統(tǒng)就覺得會有很大的復(fù)雜性，就會考慮知難而退。但是你所認為的難不一定是難。我們都知道一句熟語：“難者不會，會者不難”，往往會由于大家經(jīng)驗的不同，對待同一問題的想法和思路就都會不一樣。這也就是為什么我們會在系統(tǒng)設(shè)計的時候，強調(diào)專家的重要性。尤其是目前又被逐漸提及并廣泛應(yīng)用的 DDD 領(lǐng)域驅(qū)動設(shè)計方法，更加提倡領(lǐng)域?qū)＜业闹匾?。這樣才能夠識別現(xiàn)實問題的復(fù)雜性和根本痛點所在，進而能夠客觀合理的推導(dǎo)出可靠、合適的解決方案。很明顯，復(fù)雜系統(tǒng)設(shè)計中非常重要的兩個環(huán)節(jié)：需求分析、架構(gòu)設(shè)計。

需求分析過程中，我們需要確認需求到底要解決什么問題，面向的角色有哪些?，F(xiàn)在流行的分析方法要數(shù) DDD 領(lǐng)域驅(qū)動的分析方法。使用 DDD 的模式分析業(yè)務(wù)需求大概會有幾個步驟：

確認角色

確認角色功能

確認問題子域

確認模型、事件、歸屬

確認界限上下文

七、復(fù)雜系統(tǒng)的設(shè)計原則

識別出核心問題。對于需求的承接，有些人會直接進行入開發(fā)設(shè)計階段，尤其是對于出入職場的小伙伴。其實遇到需求我們更多的需要思考，為什么要做這個需求，這個想明白，非常有助于我們進行業(yè)務(wù)等相關(guān)的架構(gòu)設(shè)計，進而掌舵整個需求，這樣不會很容易的走入偏路。

復(fù)雜的問題簡單化，需要把復(fù)雜的問題拆解成各個小的模塊，進行逐個攻破，各個模塊職責(zé)會相對單一，未來的擴展性和可維護性也相對獨立、簡單。

確認使用通用的語言進行溝通，尤其是面向領(lǐng)域設(shè)計中，領(lǐng)域模型的認識大家一定要保持一致。

理清系統(tǒng)、模型的定位、關(guān)系、交互等。

具備未來的規(guī)劃能力，包括系統(tǒng)、技術(shù)、方案、容量等等，以使系統(tǒng)能夠長期更好、更穩(wěn)定的提供價值服務(wù)。

遵循各種設(shè)計模式，最佳實踐，避免從 0 開始，包括：SOLID 設(shè)計原則，CAP 理論，BASE 理論。

八、復(fù)雜系統(tǒng)的架構(gòu)特點

1.重視功能拆解，模塊化設(shè)計，原子化設(shè)計

復(fù)雜系統(tǒng)一定要進行細致功能、模塊、領(lǐng)域的劃分。每個模塊的都應(yīng)該有明確，單一的職責(zé)。這樣我們在分析問題的時候，可以把問題聚焦在某一個范圍內(nèi)，不會產(chǎn)生太大的影響，方便整體系統(tǒng)的維護和擴展。

2.縱向 + 橫向拓展能力至關(guān)重要

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

3.架構(gòu)先行

對于復(fù)雜系統(tǒng)，已經(jīng)不是一個或幾個流程圖能解決的事情了。我們需要通過領(lǐng)域架構(gòu)明確領(lǐng)域劃分及領(lǐng)域邊界，通過系統(tǒng)架構(gòu)明確功能模塊和功能邊界，通過應(yīng)用架構(gòu)明確各個應(yīng)用的職責(zé)、邊界、結(jié)構(gòu)劃分、依賴關(guān)系等。通過技術(shù)架構(gòu)明確我們使用的技術(shù)棧及在整體系統(tǒng)中的應(yīng)用邊界。通過數(shù)據(jù)架構(gòu)明確我們的數(shù)據(jù)存儲方式、結(jié)構(gòu)、數(shù)據(jù)使用方式等。

這些架構(gòu)一定要清晰，明確，著眼于系統(tǒng)長期價值。

4.分而治之

對于復(fù)雜系統(tǒng)，拆分是必然的，大的問題化解成小的問題，根據(jù)領(lǐng)域、模塊、功能的劃分，我們把問題歸屬于不同的邊界內(nèi)，進行逐個攻破。小的問題得道解決，那么通過合理的依賴和組合，即可有效的解決大的問題，達到整個系統(tǒng)的建設(shè)目的。

九、典型的復(fù)雜問題解決架構(gòu)

隨著社會的不斷進步，信息化組件發(fā)達，我們更需要信息化的方式去解決系統(tǒng)化的問題。早前我們更多的通過數(shù)據(jù)驅(qū)動的模式，也就是我們會先去思考會用到什么樣的結(jié)構(gòu)去存儲相關(guān)的數(shù)據(jù)，模型之間都有什么樣依賴關(guān)系，怎么樣組織數(shù)據(jù)，怎么樣把數(shù)據(jù)和外圍交互，這些思想也是典型的 MVC 架構(gòu)。

MVC 架構(gòu)迫使我們是面向視圖來開發(fā)的，我們知道視圖的變化最是不可控的，越是偏向于用戶的東西，越是容易受到用戶主觀的影響。我們知道復(fù)雜系統(tǒng)必然存在的紛繁復(fù)雜的依賴，依賴不可能存在于視圖部分，肯定會表現(xiàn)為接口的依賴。對于復(fù)雜系統(tǒng)，我們要強迫我們轉(zhuǎn)換思維，強迫我們面向接口進行設(shè)計。結(jié)合著業(yè)務(wù)系統(tǒng)的復(fù)雜性，如果想要系統(tǒng)未來具有長期價值，不得不把大的系統(tǒng)進行拆分，用統(tǒng)一的業(yè)務(wù)語言進行描述，把不可識別的問題，拆分成可識別的問題域進行解決，這也就是現(xiàn)在又逐漸盛行起來的領(lǐng)域驅(qū)動設(shè)計的方法。

1.領(lǐng)域驅(qū)動設(shè)計

領(lǐng)域驅(qū)動設(shè)計，強迫我們不再用數(shù)據(jù)進行驅(qū)動，而是使用領(lǐng)域進行驅(qū)動。遇到問題，我們先進性領(lǐng)域上的劃分和拆解。這個問題到底屬于哪個問題域，或者需要拆解到哪些問題域，然后再通過領(lǐng)域的組合、依賴完成最終問題的解決。

領(lǐng)域驅(qū)動，早在 2004 年 Eric Evans 在《Domain-Driven Design : Tackling Complexity in the Heart of Software》（領(lǐng)域驅(qū)動設(shè)計：軟件核心復(fù)雜性應(yīng)對之道）這本書中就戰(zhàn)略和戰(zhàn)術(shù)兩個方面進行了詳細的闡述。

目前來看，對于復(fù)雜系統(tǒng)的設(shè)計，領(lǐng)域驅(qū)動的模式利于系統(tǒng)的可持續(xù)發(fā)展。

2.微服務(wù)架構(gòu)

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

3.云原生架構(gòu)

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

4.DevOps 架構(gòu)

DevOps 之前，我們也一直在談敏捷，業(yè)界也有戰(zhàn)術(shù)上的落地方案。比如極限編程、Scrum 等等。如果說敏捷更多是為了解決需求、產(chǎn)品、研發(fā)、測試之間的協(xié)同、高效，那么 DevOps 更多的是在解決研發(fā)、運維間的協(xié)同問題。DevOps 近年來發(fā)展的是如火如荼，這和領(lǐng)域驅(qū)動、微服務(wù)架構(gòu)、云架構(gòu)技術(shù)、虛擬化技術(shù)（尤其是 Docker 的發(fā)展）的發(fā)展息息相關(guān)。準確的說，是各種技術(shù)微妙組合的一種共力。DevOps 的發(fā)展，是的運維不再關(guān)心應(yīng)用的部署等問題，這些事情都可以交給研發(fā)來處理，運維更多的在給研發(fā)提供自動化的構(gòu)建、集成、部署、監(jiān)控等等相關(guān)的云基礎(chǔ)能力。

5.大數(shù)據(jù)架構(gòu)

當(dāng)今的是一個數(shù)字化的時代，各行各業(yè)都在忙于進行數(shù)字化的轉(zhuǎn)型。對于復(fù)雜的業(yè)務(wù)系統(tǒng)，數(shù)據(jù)的價值尤顯突出，那么自然對于海量數(shù)據(jù)的處理、價值的挖掘訴求是必然存在的。那么數(shù)據(jù)的海量存儲、提取、傳輸、清洗、計算、挖掘等能力就需要通過大數(shù)據(jù)架構(gòu)的模式進行設(shè)計。

十、總結(jié)

現(xiàn)如今，系統(tǒng)設(shè)計的關(guān)鍵已經(jīng)變成分布式、云化、微服務(wù)化、大數(shù)據(jù)化。架構(gòu)的本質(zhì)依然沒有改變，只是由于社會的發(fā)展，我們的需求，需要處理的問題、依賴愈來愈復(fù)雜，我們需要用發(fā)展的眼光，時刻追隨技術(shù)前沿，進而推進、優(yōu)化、迭代系統(tǒng)的架構(gòu)設(shè)計。

復(fù)雜系統(tǒng)的架構(gòu)設(shè)計不是一蹴而就的，合適的才是正確的。希望本文能夠?qū)δ谶M行復(fù)雜系統(tǒng)設(shè)計時有一定的參考意義。