建站
咨詢
售后
建站咨詢
新聞中心
Microservices(微服務(wù)架構(gòu))和DDD(領(lǐng)域驅(qū)動(dòng)設(shè)計(jì))是時(shí)下最炙手可熱的兩個(gè)技術(shù)詞語。在最近兩年的咨詢工作中總是會(huì)被不同的團(tuán)隊(duì)和角色詢問，由此也促使我思考為什么這兩個(gè)技術(shù)詞匯被這么深入人心的綁定，它們之間的關(guān)系是什么呢?
成都創(chuàng)新互聯(lián)公司專業(yè)為企業(yè)提供贛州網(wǎng)站建設(shè)、贛州做網(wǎng)站、贛州網(wǎng)站設(shè)計(jì)、贛州網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)與制作、贛州企業(yè)網(wǎng)站模板建站服務(wù)，10多年贛州做網(wǎng)站經(jīng)驗(yàn)，不只是建網(wǎng)站，更提供有價(jià)值的思路和整體網(wǎng)絡(luò)服務(wù)。
服務(wù)于更高的業(yè)務(wù)響應(yīng)力
首先從兩個(gè)詞匯的發(fā)明來看它們是沒有因果關(guān)系的。
DDD是Eric Evans于2003年出版的書名，同時(shí)也是這個(gè)架構(gòu)設(shè)計(jì)方法名的起源。DDD的想法是讓我們的軟件實(shí)現(xiàn)和一個(gè)演進(jìn)的架構(gòu)模型保持一致，而這個(gè)演進(jìn)的模型來自于我們的業(yè)務(wù)需求。這種演進(jìn)式設(shè)計(jì)方法在當(dāng)時(shí)看來還是比較挑戰(zhàn)的，更為流行的解決架構(gòu)設(shè)計(jì)復(fù)雜度的方法是分層：比如數(shù)據(jù)架構(gòu)、服務(wù)架構(gòu)、中間件架構(gòu)等。MVC在互聯(lián)網(wǎng)應(yīng)用開發(fā)領(lǐng)域也基本成為了標(biāo)配。
時(shí)間很快過了10年，Martin Fowler和ThoughtWorks英國架構(gòu)師James Lewis坐下來一起分析了好幾個(gè)能夠持續(xù)演進(jìn)的大型復(fù)雜系統(tǒng)，總結(jié)出了9大核心特質(zhì)，然后用Microservices來定義了擁有這些特質(zhì)的架構(gòu)。
之后由于Google、Netflix、Amazon等一系列明星企業(yè)都對號入座，Microservices開始風(fēng)靡整個(gè)軟件業(yè)。這時(shí)候很多人會(huì)問微服務(wù)架構(gòu)是怎么設(shè)計(jì)出來的，業(yè)界人士會(huì)說DDD是一個(gè)好方法，其中也包括微服務(wù)定義者M(jìn)artin Fowler，畢竟DDD原書的序是他給著的，于是乎DDD開始在被定義10年后火了。
從我個(gè)人角度來看，如果真的需要找到因果關(guān)系的話，最根本的驅(qū)動(dòng)力來自于科技時(shí)代對軟件系統(tǒng)(數(shù)字化)響應(yīng)力要求的不斷提升，而系統(tǒng)的復(fù)雜度卻隨著業(yè)務(wù)的多元化而與日俱增。如何駕馭這樣的高復(fù)雜度成了每個(gè)企業(yè)必須面對的挑戰(zhàn)，以至于業(yè)界開始把這種模型總結(jié)為響應(yīng)力企業(yè)(Responsive Enterprise)，而模型中總結(jié)的大部分原則都是為了更好的適應(yīng)環(huán)境不確定性帶來的高復(fù)雜度。
從業(yè)務(wù)視角分離復(fù)雜度
每個(gè)人能夠認(rèn)知的復(fù)雜度都是有限的，在面對高復(fù)雜度的時(shí)候我們會(huì)做關(guān)注點(diǎn)分離，這是一個(gè)最基本的哲學(xué)原則。顯然在針對復(fù)雜業(yè)務(wù)場景進(jìn)行建模時(shí)，我們也會(huì)應(yīng)用此原則。這個(gè)時(shí)候去分離關(guān)注點(diǎn)一般可以從兩個(gè)維度出發(fā)：
- 技術(shù)維度分離，類似MVC這樣的分層思想是我們廣泛接受的。
- 業(yè)務(wù)維度分離，根據(jù)不同的業(yè)態(tài)劃分系統(tǒng)，比如按售前、銷售、售后劃分。
以上兩個(gè)維度沒有孰優(yōu)孰劣之分，在處理復(fù)雜問題的時(shí)候一定都會(huì)用上，但為了能夠高效響應(yīng)業(yè)務(wù)的變化，微服務(wù)的架構(gòu)更強(qiáng)調(diào)業(yè)務(wù)維度的關(guān)注點(diǎn)分離來應(yīng)對高復(fù)雜度。這是顯著區(qū)別于傳統(tǒng)SOA架構(gòu)的特質(zhì)之一，比如誕生于傳統(tǒng)SOA時(shí)代的ESB(工業(yè)服務(wù)總線)就是一個(gè)典型的技術(shù)關(guān)注點(diǎn)分離出來的中間件。
隨著業(yè)務(wù)的變化，我們也看到ESB成為了一個(gè)架構(gòu)上的反模式，即大量的業(yè)務(wù)規(guī)則和流程被封裝在了ESB里，讓ESB成為了不可駕馭的復(fù)雜度之源，以至于破壞了SOA架構(gòu)之前承諾的各種優(yōu)勢。當(dāng)然Microservices架構(gòu)并非是新一代SOA架構(gòu)這么簡單，已經(jīng)有不少文章在討論這個(gè)話題，本文就不在展開了。
所以從本質(zhì)上作為一種架構(gòu)設(shè)計(jì)方法的DDD和作為一種架構(gòu)風(fēng)格的Microservices都是為著追求高響應(yīng)力目標(biāo)而從業(yè)務(wù)視角去分離復(fù)雜度的手段。
如果這個(gè)時(shí)代你還覺得自己的架構(gòu)不需要這種響應(yīng)力，我建議你問問身邊維護(hù)3年以上系統(tǒng)的朋友或同事們，他們會(huì)告訴你這是怎樣的一種痛苦。實(shí)際上很多企業(yè)對這種響應(yīng)力的追求已經(jīng)很“瘋狂”了，這也是微服務(wù)的兩位定義者可能都始料未及的。
他們在定義文章中帶著很強(qiáng)警告語氣讓大家慎用，但在這個(gè)科技時(shí)代，微服務(wù)架構(gòu)實(shí)施的可能風(fēng)險(xiǎn)對比高響應(yīng)力在未來可能帶來的市場機(jī)會(huì)幾乎可以忽略不計(jì)。一個(gè)Netflix的成功就足以讓大部分企業(yè)毫不猶豫的選擇微服務(wù)作為自身的架構(gòu)風(fēng)格。
業(yè)務(wù)和技術(shù)漸進(jìn)統(tǒng)一的架構(gòu)設(shè)計(jì)
如果Microservices和DDD在目標(biāo)上達(dá)成了上文的統(tǒng)一，那么在具體做法上和以前有什么不同呢?
為了解釋清楚這個(gè)問題讓我們極簡化架構(gòu)設(shè)計(jì)為以下三個(gè)層面工作：
- 業(yè)務(wù)架構(gòu)：根據(jù)業(yè)務(wù)需求設(shè)計(jì)業(yè)務(wù)模塊及交互關(guān)系。
- 系統(tǒng)架構(gòu)：根據(jù)業(yè)務(wù)需求設(shè)計(jì)系統(tǒng)和子系統(tǒng)的模塊。
- 技術(shù)架構(gòu)：根據(jù)業(yè)務(wù)需求決定采用的技術(shù)及框架。
顯然這三者在具體一個(gè)架構(gòu)設(shè)計(jì)活動(dòng)中應(yīng)該是有先后順序的，但并非一定是孰先孰后，比如一個(gè)簡單的web應(yīng)用，很多人會(huì)說MVC是標(biāo)配了(首先確定了系統(tǒng)架構(gòu))，或者有人說用RoR快(首先確定了技術(shù)架構(gòu))。在給定的業(yè)務(wù)場景里，也許這樣的順序是合理的。
(架構(gòu)設(shè)計(jì)工作分層及傳統(tǒng)意義上的負(fù)責(zé)人)
這個(gè)時(shí)候咱們增加復(fù)雜業(yè)務(wù)需求和快速市場變化這兩個(gè)環(huán)境變量，這個(gè)順序就變得很有意思了。于是我們聽到不少走出初創(chuàng)期的互聯(lián)網(wǎng)服務(wù)平臺(tái)開始“重寫”他們的系統(tǒng)(從PHP到Java)，很多文章開始反思MVC帶來的僵化(臃腫的展現(xiàn)層)。
經(jīng)歷了這樣變遷的架構(gòu)師們都會(huì)感同身受的出來為DDD站臺(tái)，其原因就是“跳過”(或“后補(bǔ)”)業(yè)務(wù)架構(gòu)顯然表明設(shè)計(jì)出來的架構(gòu)關(guān)注點(diǎn)并不在業(yè)務(wù)的響應(yīng)力上，因?yàn)闃I(yè)務(wù)的可能變化點(diǎn)并沒有被分析出來指導(dǎo)系統(tǒng)和技術(shù)架構(gòu)的設(shè)計(jì)。
DDD的核心訴求就是能夠讓業(yè)務(wù)架構(gòu)和系統(tǒng)架構(gòu)形成綁定關(guān)系，從而當(dāng)我們?nèi)ロ憫?yīng)業(yè)務(wù)變化調(diào)整業(yè)務(wù)架構(gòu)時(shí)，系統(tǒng)架構(gòu)的改變是隨之自發(fā)的。
這個(gè)變化的結(jié)果有兩個(gè)：
- 業(yè)務(wù)架構(gòu)的梳理和系統(tǒng)架構(gòu)的梳理是同步漸進(jìn)的，其結(jié)果是劃分出的業(yè)務(wù)上下文和系統(tǒng)模塊結(jié)構(gòu)是綁定的。
- 技術(shù)架構(gòu)是解耦的，可以根據(jù)劃分出來的業(yè)務(wù)上下文的系統(tǒng)架構(gòu)選擇最合適的實(shí)現(xiàn)技術(shù)。
***點(diǎn)顯然也是我們產(chǎn)生微服務(wù)劃分所必須遵循的，因?yàn)槲⒎?wù)追求的是業(yè)務(wù)層面的復(fù)用，所以設(shè)計(jì)出來的系統(tǒng)必須是跟業(yè)務(wù)一致的。第二點(diǎn)更是微服務(wù)架構(gòu)的特質(zhì)：“去中心化”的治理技術(shù)和數(shù)據(jù)管理。 作為架構(gòu)設(shè)計(jì)的方法，DDD的各種實(shí)踐，包括最近流行的Event Storming(事件風(fēng)暴)實(shí)際上都是促進(jìn)業(yè)務(wù)和系統(tǒng)架構(gòu)梳理的漸進(jìn)式認(rèn)知。
在一次DDD工作坊中，一位同事給出了“你們連業(yè)務(wù)故事都講不清楚，還有必要繼續(xù)做架構(gòu)設(shè)計(jì)嗎?”這樣的經(jīng)典評論。而DDD的整個(gè)方法也沒有涉及具體的技術(shù)架構(gòu)實(shí)現(xiàn)，這個(gè)選型的權(quán)利很多時(shí)候被“下放”給了真正的開發(fā)團(tuán)隊(duì)。
值得一提的是采用DDD這種架構(gòu)設(shè)計(jì)方法并不一定就產(chǎn)生Mircoservices這種架構(gòu)風(fēng)格，往往會(huì)推薦用大顆粒度的服務(wù)來包含業(yè)務(wù)分析過程中發(fā)現(xiàn)的不確定點(diǎn)，以避免拆分后變化過度頻繁帶來的雙向修改成本。
跨職能協(xié)作的架構(gòu)設(shè)計(jì)
業(yè)務(wù)和系統(tǒng)的漸進(jìn)認(rèn)知改變了很多之前的架構(gòu)工作模式，在采用DDD的過程中，很容易感受到業(yè)務(wù)專家的重要性。而如果還有人寄希望讓業(yè)務(wù)能夠一次性給架構(gòu)師講清楚需求，那我建議抱有這樣希望的同學(xué)去親身參加一次自己不熟悉業(yè)務(wù)領(lǐng)域的架構(gòu)設(shè)計(jì)討論。你會(huì)很容易得出結(jié)論“原來業(yè)務(wù)也不懂他要什么”。當(dāng)然業(yè)務(wù)人員聽說要參加某種(軟件)架構(gòu)設(shè)計(jì)方法時(shí)心里也一定是抵觸的。
DDD成功運(yùn)用的基礎(chǔ)就是創(chuàng)造讓業(yè)務(wù)和系統(tǒng)這兩種不同認(rèn)知模型逐步統(tǒng)一的環(huán)境。
(業(yè)務(wù)架構(gòu)和系統(tǒng)架構(gòu)設(shè)計(jì))
所以“不幸”的是如果你不能建立一個(gè)跨業(yè)務(wù)和技術(shù)的新型架構(gòu)設(shè)計(jì)小組，你的DDD實(shí)踐就沒有成功的基礎(chǔ)，繼而采用微服務(wù)架構(gòu)可能就會(huì)是一場災(zāi)難。幸運(yùn)的是這種跨職能組織結(jié)構(gòu)已經(jīng)是前文中“采用”微服務(wù)架構(gòu)企業(yè)(如Amazon)的標(biāo)配，你不必再論證這件事情的可實(shí)施性。剩下的關(guān)鍵就是如何能夠讓不同背景的人們協(xié)作起來。這也是大家可以看到DDD領(lǐng)域的下一個(gè)熱點(diǎn)，類似Event Storming這樣的模式化協(xié)作工作坊會(huì)更多的出現(xiàn)在大家的視線里。
永無終止的DDD和演進(jìn)的Microservices
DDD是容易上癮的，當(dāng)大家發(fā)現(xiàn)原來通過這個(gè)建模過程業(yè)務(wù)專家更了解服務(wù)劃分(系統(tǒng)模塊)，架構(gòu)設(shè)計(jì)更懂業(yè)務(wù)需求，這種協(xié)作會(huì)成為常態(tài)。在這個(gè)tech@core的時(shí)代，這樣的融合將成為企業(yè)的核心競爭力。
當(dāng)然剛開始采用DDD方法的時(shí)候，請不要認(rèn)為每個(gè)系統(tǒng)搞一次所謂的DDD工作坊就能夠找到***的服務(wù)劃分了。業(yè)務(wù)的變化是持續(xù)的，而每次業(yè)務(wù)架構(gòu)變化必然牽動(dòng)系統(tǒng)架構(gòu)的變化。良好的領(lǐng)域架構(gòu)綁定了業(yè)務(wù)和系統(tǒng)，讓雙方人員能夠用統(tǒng)一語言交流，這件事情建立不易，而持續(xù)運(yùn)作更難。
成功的DDD方法運(yùn)用是貫穿系統(tǒng)的整個(gè)生命周期的，這個(gè)過程中業(yè)務(wù)和技術(shù)的協(xié)作是持續(xù)發(fā)生的。
Microservices的***一個(gè)特質(zhì)：“演進(jìn)式”設(shè)計(jì) - 也明確了設(shè)計(jì)是一種持續(xù)的活動(dòng)。DDD提供了一種符合這個(gè)微服務(wù)特質(zhì)的工作方法，讓演進(jìn)能夠落地。值得一提的是就筆者最近的經(jīng)驗(yàn)，這個(gè)演進(jìn)過程中最難認(rèn)知到變化的就是DDD里最顯而易見的“統(tǒng)一語言”。當(dāng)大家形成了一個(gè)業(yè)務(wù)概念-“客戶”后，少有團(tuán)隊(duì)能夠持續(xù)審視這個(gè)“客戶”是否隨著市場的變化而發(fā)生了含義的變遷。
對比傳統(tǒng)的SOA，微服務(wù)的拆分也是動(dòng)態(tài)的，禚嫻靜在自己的文章中描述一個(gè)系統(tǒng)采用微服務(wù)架構(gòu)歷程中服務(wù)拆分的演變。這里不會(huì)有一個(gè)ESB來以不變應(yīng)萬變，這種幻想在過去的10年里已經(jīng)被數(shù)次打臉。DDD的好處是讓業(yè)務(wù)和技術(shù)人員都能夠在合作中理解這種變化，而不至于陷入業(yè)務(wù)人員抱怨技術(shù)架構(gòu)不知所謂，技術(shù)人員覺得業(yè)務(wù)人員朝三暮四的尷尬。
你需要成為那個(gè)高個(gè)子!
Martin Fowler在Microservies的定義文章中畫了下面的圖，評論“你必須有那個(gè)高度”來隱喻微服務(wù)實(shí)施的能力要求。就架構(gòu)建模方面來說我認(rèn)為DDD應(yīng)該是一個(gè)團(tuán)隊(duì)必須去掌握的，包括這個(gè)團(tuán)隊(duì)的業(yè)務(wù)人員和產(chǎn)品設(shè)計(jì)人員。
(微服務(wù)前置條件示意)
很有意思的是目前Service Design也是全球用戶體驗(yàn)設(shè)計(jì)領(lǐng)域的一個(gè)熱門話題，從用戶視角出發(fā)去設(shè)計(jì)整個(gè)服務(wù)鏈條。比如時(shí)下熱門的共享單車，一個(gè)成功的服務(wù)設(shè)計(jì)應(yīng)該是從用戶開始有用車需求觸發(fā)到***完成騎行繳費(fèi)離開，而不僅僅是去設(shè)計(jì)一輛能夠互聯(lián)網(wǎng)解鎖的自行車。
我們可以找到很多Service Deisgn和DDD在原則上的相似之處，比如用戶中心和協(xié)同設(shè)計(jì)。借用上面的高個(gè)子說法:
在業(yè)務(wù)需求認(rèn)知和跨職能協(xié)作方面你一定需要成為高個(gè)子!
【本文是專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號：思特沃克，轉(zhuǎn)載請聯(lián)系原作者】
新聞名稱：DDD&Microservices
URL分享：http://fisionsoft.com.cn/article/ccchoei.html
