淺談復(fù)雜業(yè)務(wù)系統(tǒng)的架構(gòu)設(shè)計(jì)

淺談復(fù)雜業(yè)務(wù)系統(tǒng)的架構(gòu)設(shè)計(jì)什么是復(fù)雜系統(tǒng)

我們經(jīng)常提到復(fù)雜系統(tǒng)，那么到底什么是復(fù)雜系統(tǒng)。我們看下維基的定義：復(fù)雜系統(tǒng)（英語：complexsystem），又稱復(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)舉例，分成很多部分，商品、庫存、采購、訂單、物流、財(cái)務(wù)，這個(gè)只是大的分類，還有針對(duì)C端的營銷、會(huì)員、購買、售后等體系，針對(duì)B端的商家入駐、管理等體系。各個(gè)部分、體系之間有著千絲萬縷的聯(lián)系，可謂之復(fù)雜系統(tǒng)了。當(dāng)然了，遠(yuǎn)遠(yuǎn)不止這些，隨著業(yè)務(wù)復(fù)雜性的不斷提升，整個(gè)系統(tǒng)的復(fù)雜性也會(huì)愈來愈復(fù)雜。2.什么是架構(gòu)生活中我們經(jīng)常談及“架構(gòu)”，那么到底什么是“架構(gòu)”，RobertC.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)系+原則和指南，總體來看會(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)部分之間有往來，有交互這樣說來，我們?nèi)祟惿鐣?huì)本身就是一個(gè)社會(huì)架構(gòu)，各種職責(zé)、分工、圈層，就我們的軟件系統(tǒng)來說，DDD是架構(gòu)，MVC也是架構(gòu)，大數(shù)據(jù)設(shè)計(jì)也有大數(shù)據(jù)的架構(gòu)。所以架構(gòu)無處不在，好的架構(gòu)能夠?qū)μ囟ǖ膯栴}，特定的領(lǐng)域起到規(guī)范和指導(dǎo)作用。3.架構(gòu)的本質(zhì)我們知道，架構(gòu)這個(gè)詞是源于建筑行業(yè)的，英文原詞是：Architecture，維基百科上的解釋是規(guī)劃、設(shè)計(jì)和建造建筑物的過程及產(chǎn)物。那我們就用建筑行業(yè)來理解一下。建房子對(duì)大家而言再熟悉不過了，那我們蓋個(gè)小平層、蓋個(gè)兩層小高層、蓋個(gè)5層小高層、搞個(gè)10層、蓋個(gè)幾百層的摩天大樓的過程、因素、風(fēng)險(xiǎn)是完全不同的。蓋摩天大樓需要付出的成本更高，過程中的不確定性更多，挑戰(zhàn)和風(fēng)險(xiǎn)也更大，例如如何選地、選擇什么樣的結(jié)構(gòu)，如何承重，采光如何控制，優(yōu)化、如何取暖，如何上水、排水，如何通風(fēng)，如何避震等等。這些東西我們考慮的越多，房子未來的質(zhì)量，可控性也會(huì)越好。所以架構(gòu)本質(zhì)上就是一種指導(dǎo)型的約束，以約定整體和部分、部分和部分之間的關(guān)系，以使整體更加穩(wěn)定，更加可靠。4.架構(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ì)我們常見的架構(gòu)分離進(jìn)行下簡單的說明。4.1.業(yè)務(wù)架構(gòu)

說到業(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)行語言轉(zhuǎn)化，內(nèi)化為領(lǐng)域通用語言。4.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)常說到的MVC、分層架構(gòu)、CQRS、DDD傳統(tǒng)洋蔥圈架構(gòu)、DDD六邊形架構(gòu)都可以歸結(jié)為應(yīng)用架構(gòu)的范疇。4.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ā)展。5.架構(gòu)需要考慮哪些因素5.1.功能性需求

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

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

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

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

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

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

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

有的同學(xué)會(huì)有誤區(qū)，一想到類似這樣的系統(tǒng)就覺得會(huì)有很大的復(fù)雜性，就會(huì)考慮知難而退。但是你所認(rèn)為的難不一定是難。我們都知道一句熟語：“難者不會(huì)，會(huì)者不難”，往往會(huì)由于大家經(jīng)驗(yàn)的不同，對(duì)待同一問題的想法和思路就都會(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í)問題的復(fù)雜性和根本痛點(diǎn)所在，進(jìn)而能夠客觀合理的推導(dǎo)出可靠、合適的解決方案。很明顯，復(fù)雜系統(tǒng)設(shè)計(jì)中非常重要的兩個(gè)環(huán)節(jié)：需求分析、架構(gòu)設(shè)計(jì)。需求分析過程中，我們需要確認(rèn)需求到底要解決什么問題，面向的角色有哪些?，F(xiàn)在流行的分析方法要數(shù)DDD領(lǐng)域驅(qū)動(dòng)的分析方法。使用DDD的模式分析業(yè)務(wù)需求大概會(huì)有幾個(gè)步驟：確認(rèn)角色確認(rèn)角色功能確認(rèn)問題子域確認(rèn)模型、事件、歸屬確認(rèn)界限上下文7.復(fù)雜系統(tǒng)的設(shè)計(jì)原則識(shí)別出核心問題：對(duì)于需求的承接，有些人會(huì)直接進(jìn)行入開發(fā)設(shè)計(jì)階段，尤其是對(duì)于出入職場的小伙伴。其實(shí)遇到需求我們更多的需要思考，為什么要做這個(gè)需求，這個(gè)想明白，非常有助于我們進(jìn)行業(yè)務(wù)等相關(guān)的架構(gòu)設(shè)計(jì)，進(jìn)而掌舵整個(gè)需求。這樣不會(huì)很容易的走入偏路。復(fù)雜的問題簡單化，需要把復(fù)雜的問題拆解成各個(gè)小的模塊，進(jìn)行逐個(gè)攻破，各個(gè)模塊職責(zé)會(huì)相對(duì)單一，未來的擴(kuò)展性和可維護(hù)性也相對(duì)獨(dú)立、簡單確認(rèn)使用通用的語言進(jìn)行溝通，尤其是面向領(lǐng)域設(shè)計(jì)中，領(lǐng)域模型的認(rèn)識(shí)大家一定要保持一致理清系統(tǒng)、模型的定位、關(guān)系、交互等具備未來的規(guī)劃能力，包括系統(tǒng)、技術(shù)、方案、容量等等，以使系統(tǒng)能夠長期更好、更穩(wěn)定的提供價(jià)值服務(wù)遵循各種設(shè)計(jì)模式，最佳實(shí)踐，避免從0開始，包括：SOLID設(shè)計(jì)原則，CAP理論，BASE理論8.復(fù)雜系統(tǒng)的架構(gòu)特點(diǎn)8.1.重視功能拆解，模塊化設(shè)計(jì)，原子化設(shè)計(jì)

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

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

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

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

隨著社會(huì)的不斷進(jìn)步，信息化組件發(fā)達(dá)，我們更需要信息化的方式去解決系統(tǒng)化的問題。早前我們更多的通過數(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)迫使我們是面向視圖來開發(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)未來具有長期價(jià)值，不得不把大的系統(tǒng)進(jìn)行拆分，用統(tǒng)一的業(yè)務(wù)語言進(jìn)行描述，把不可識(shí)別的問題，拆分成可識(shí)別的問題域進(jìn)行解決，這也就是現(xiàn)在又逐漸盛行起來的領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的方法。9.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)。遇到問題，我們先進(jìn)性領(lǐng)域上的劃分和拆解。這個(gè)問題到底屬于哪個(gè)問題域，或者需要拆解到哪些問題域，然后再通過領(lǐng)域的組合、依賴完成最終問題的解決。領(lǐng)域驅(qū)動(dòng)，早在2004年EricEvans在《Domain-DrivenDesign:TacklingComplexityintheHeartofSoftware》（領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)：軟件核心復(fù)雜性應(yīng)對(duì)之道）這本書中就戰(zhàn)略和戰(zhàn)術(shù)兩個(gè)方面進(jìn)行了詳細(xì)的闡述。目前來看，對(duì)于復(fù)雜系統(tǒng)的設(shè)計(jì)，領(lǐng)域驅(qū)動(dòng)的模式利于系統(tǒng)的可持續(xù)發(fā)展。9.2.微服務(wù)架構(gòu)

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

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

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