高級(jí)進(jìn)階：復(fù)雜業(yè)務(wù)系統(tǒng)的通用架構(gòu)設(shè)計(jì)

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

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

• 由點(diǎn)組成

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

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

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

• 項(xiàng)目地址：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è)計(jì)軟件的人為軟件賦予的形狀，這個(gè)形狀是指系統(tǒng)如何被劃分為組件 (Components)，各個(gè)組件如何排列（Arrangement），組件之間如何溝通（Communication，通訊），維基百科的定義：有關(guān)軟件整體結(jié)構(gòu)與組件的抽象描述，用于指導(dǎo)大型軟件系統(tǒng)各個(gè)方面的設(shè)計(jì)，IEEE 的定義：架構(gòu) = 組成單元的結(jié)構(gòu) + 組成單元的關(guān)系 + 原則和指南，總體來(lái)看會(huì)包括幾個(gè)內(nèi)容：

• 整體：強(qiáng)調(diào)部分的組成，強(qiáng)調(diào)合力
• 規(guī)則：強(qiáng)調(diào)部分之間有關(guān)聯(lián)關(guān)系，有規(guī)則，有約束
• 通信：強(qiáng)調(diào)部分之間有往來(lái)，有交互

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

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

• 項(xiàng)目地址：https://github.com/YunaiV/yudao-cloud
• 視頻教程：https://doc.iocoder.cn/video/

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

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

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

四、架構(gòu)分類

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

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

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

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

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

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

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

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

1.功能性需求

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

2.非功能性需求

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

3.可靠性

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

4.可用性

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

5.擴(kuò)展性

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

6.治理能力

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

7.響應(yīng)性能

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

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

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

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

• 確認(rèn)角色
• 確認(rèn)角色功能
• 確認(rèn)問(wèn)題子域
• 確認(rèn)模型、事件、歸屬
• 確認(rèn)界限上下文

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

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

• 復(fù)雜的問(wèn)題簡(jiǎn)單化，需要把復(fù)雜的問(wèn)題拆解成各個(gè)小的模塊，進(jìn)行逐個(gè)攻破，各個(gè)模塊職責(zé)會(huì)相對(duì)單一，未來(lái)的擴(kuò)展性和可維護(hù)性也相對(duì)獨(dú)立、簡(jiǎn)單。

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

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

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

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

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

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

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

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

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

3.架構(gòu)先行

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

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

4.分而治之

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

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

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

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

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

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

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

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

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

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

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

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

4.DevOps 架構(gòu)

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

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

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

十、總結(jié)

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

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