淺談復雜業(yè)務系統(tǒng)的架構設計

淺談復雜業(yè)務系統(tǒng)的架構設計什么是復雜系統(tǒng)

我們經常提到復雜系統(tǒng)，那么到底什么是復雜系統(tǒng)。我們看下維基的定義：復雜系統(tǒng)（英語：complexsystem），又稱復合系統(tǒng)，是指由許多可能相互作用的組成成分所組成的系統(tǒng)。強調了兩點：由點組成點之間有各種關聯兩點的規(guī)模和復雜性直接決定了系統(tǒng)的復雜程度。比如就拿我們的電商系統(tǒng)舉例，分成很多部分，商品、庫存、采購、訂單、物流、財務，這個只是大的分類，還有針對C端的營銷、會員、購買、售后等體系，針對B端的商家入駐、管理等體系。各個部分、體系之間有著千絲萬縷的聯系，可謂之復雜系統(tǒng)了。當然了，遠遠不止這些，隨著業(yè)務復雜性的不斷提升，整個系統(tǒng)的復雜性也會愈來愈復雜。2.什么是架構生活中我們經常談及“架構”，那么到底什么是“架構”，RobertC.Martin《架構整潔之道》中的定義：軟件架構是指設計軟件的人為軟件賦予的形狀，這個形狀是指系統(tǒng)如何被劃分為組件(Components)，各個組件如何排列（Arrangement），組件之間如何溝通（Communication，通訊），維基百科的定義：有關軟件整體結構與組件的抽象描述，用于指導大型軟件系統(tǒng)各個方面的設計,IEEE的定義：架構=組成單元的結構+組成單元的關系+原則和指南，總體來看會包括幾個內容：整體：強調部分的組成，強調合力規(guī)則：強調部分之間有關聯關系，有規(guī)則，有約束通信：強調部分之間有往來，有交互這樣說來，我們人類社會本身就是一個社會架構，各種職責、分工、圈層，就我們的軟件系統(tǒng)來說，DDD是架構，MVC也是架構，大數據設計也有大數據的架構。所以架構無處不在，好的架構能夠對特定的問題，特定的領域起到規(guī)范和指導作用。3.架構的本質我們知道，架構這個詞是源于建筑行業(yè)的，英文原詞是：Architecture，維基百科上的解釋是規(guī)劃、設計和建造建筑物的過程及產物。那我們就用建筑行業(yè)來理解一下。建房子對大家而言再熟悉不過了，那我們蓋個小平層、蓋個兩層小高層、蓋個5層小高層、搞個10層、蓋個幾百層的摩天大樓的過程、因素、風險是完全不同的。蓋摩天大樓需要付出的成本更高，過程中的不確定性更多，挑戰(zhàn)和風險也更大，例如如何選地、選擇什么樣的結構，如何承重，采光如何控制，優(yōu)化、如何取暖，如何上水、排水，如何通風，如何避震等等。這些東西我們考慮的越多，房子未來的質量，可控性也會越好。所以架構本質上就是一種指導型的約束，以約定整體和部分、部分和部分之間的關系，以使整體更加穩(wěn)定，更加可靠。4.架構分類我們上面舉的例子我們可以叫做建筑架構，實際上架構有很多種類型，比如業(yè)務架構，應用架構，技術架構，數據架構等。單個架構分類，站在不同的維度也會有不同的看法，復雜性也會有相當大的區(qū)別。比如企業(yè)級架構能夠凸顯出公司的整體戰(zhàn)略，業(yè)務涉及情況，分布情況，發(fā)力情況。而某一個單一的業(yè)務線也同樣有自己的業(yè)務架構，凸顯單獨業(yè)務自己的業(yè)務目標、戰(zhàn)略等。應用架構、技術架構也是同理，會有不同層面視野的架構。我們下面就以業(yè)務線內部視角對我們常見的架構分離進行下簡單的說明。4.1.業(yè)務架構

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

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

技術架構不一定局限于單個應用內部，尤其是當前微服務架構時代，服務之間如何交互，服務如何治理，數據如何存儲，緩存如何構建等等，都是技術架構的范疇。技術架構給應用和業(yè)務架構提供了一個技術基礎，以使業(yè)務更好的發(fā)展，更健壯的迭代，發(fā)展。5.架構需要考慮哪些因素5.1.功能性需求

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

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

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

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

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

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

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

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

復雜系統(tǒng)一定要進行細致功能、模塊、領域的劃分。每個模塊的都應該有明確，單一的職責。這樣我們在分析問題的時候，可以把問題聚焦在某一個范圍內，不會產生太大的影響，方便整體系統(tǒng)的維護和擴展。8.2.縱向+橫向拓展能力至關重要

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

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

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

隨著社會的不斷進步，信息化組件發(fā)達，我們更需要信息化的方式去解決系統(tǒng)化的問題。早前我們更多的通過數據驅動的模式，也就是我們會先去思考會用到什么樣的結構去存儲相關的數據，模型之間都有什么樣依賴關系，怎么樣組織數據，怎么樣把數據和外圍交互，這些思想也是典型的MVC架構。MVC架構迫使我們是面向視圖來開發(fā)的，我們知道視圖的變化最是不可控的，越是偏向于用戶的東西，越是容易受到用戶主觀的影響。我們知道復雜系統(tǒng)必然存在的紛繁復雜的依賴，依賴不可能存在于視圖部分，肯定會表現為接口的依賴。對于復雜系統(tǒng)，我們要強迫我們轉換思維，強迫我們面向接口進行設計。結合著業(yè)務系統(tǒng)的復雜性，如果想要系統(tǒng)未來具有長期價值，不得不把大的系統(tǒng)進行拆分，用統(tǒng)一的業(yè)務語言進行描述，把不可識別的問題，拆分成可識別的問題域進行解決，這也就是現在又逐漸盛行起來的領域驅動設計的方法。9.1.領域驅動設計

領域驅動設計，強迫我們不再用數據進行驅動，而是使用領域進行驅動。遇到問題，我們先進性領域上的劃分和拆解。這個問題到底屬于哪個問題域，或者需要拆解到哪些問題域，然后再通過領域的組合、依賴完成最終問題的解決。領域驅動，早在2004年EricEvans在《Domain-DrivenDesign:TacklingComplexityintheHeartofSoftware》（領域驅動設計：軟件核心復雜性應對之道）這本書中就戰(zhàn)略和戰(zhàn)術兩個方面進行了詳細的闡述。目前來看，對于復雜系統(tǒng)的設計，領域驅動的模式利于系統(tǒng)的可持續(xù)發(fā)展。9.2.微服務架構

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

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

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