領(lǐng)域驅(qū)動設(shè)計和服務(wù)自演進(jìn)能力是內(nèi)功。

樂安網(wǎng)站制作公司哪家好，找成都創(chuàng)新互聯(lián)！從網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、響應(yīng)式網(wǎng)站開發(fā)等網(wǎng)站項(xiàng)目制作，到程序開發(fā)，運(yùn)營維護(hù)。成都創(chuàng)新互聯(lián)從2013年創(chuàng)立到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選成都創(chuàng)新互聯(lián)。
前言

《微服務(wù)的團(tuán)隊(duì)?wèi)?yīng)對之道》提到，微服務(wù)幫助企業(yè)提升其響應(yīng)力，而企業(yè)需要從DevOps、服務(wù)構(gòu)建、團(tuán)隊(duì)和文化四點(diǎn)入手，應(yīng)對微服務(wù)帶來的復(fù)雜度和各種挑戰(zhàn)，從而真正獲益。如果說運(yùn)維能力是微服務(wù)的加油站，服務(wù)則是其核心。

企業(yè)想要實(shí)施微服務(wù)架構(gòu)，經(jīng)常問到的第一個問題是，怎么拆？如何從單體到服務(wù)化的結(jié)構(gòu)？第二個問題是拆完后業(yè)務(wù)變了增加了怎么辦？另外，我們想要改變的系統(tǒng)往往已經(jīng)成功上線，并有著活躍的用戶。那么對其拆分還需要考慮現(xiàn)有的系統(tǒng)運(yùn)行，如何以安全最快低成本的方式拆分也是在這個過程中需要回答的問題。

本文會針對以上問題，介紹我們團(tuán)隊(duì)在服務(wù)拆分和演進(jìn)過程中的實(shí)踐和經(jīng)驗(yàn)總結(jié)。

我們項(xiàng)目架構(gòu)的演化歷程

該項(xiàng)目始于2009年，到現(xiàn)在已有7年的時間。在這7年中覆蓋的業(yè)務(wù)線不斷擴(kuò)大，從工單、差旅、計費(fèi)、文件、報表、增值業(yè)務(wù)等；業(yè)務(wù)流程從部分節(jié)點(diǎn)到用戶端的全線延伸；7年間打造多個產(chǎn)品，架構(gòu)經(jīng)歷了多次調(diào)整，從單體架構(gòu)、RPC、服務(wù)化、規(guī)?；轿⒎?wù)。

主要架構(gòu)變遷如下圖所示：

在這7年架構(gòu)演進(jìn)路上，我們遇到的主要挑戰(zhàn)如下：

如何拆？即如何正確理解業(yè)務(wù)，將單體結(jié)構(gòu)拆分為服務(wù)化架構(gòu)？ 拆完后業(yè)務(wù)變了增加了怎么辦？即在業(yè)務(wù)需求不斷發(fā)展變化的前提下，如何持續(xù)快速地演進(jìn)？ 如何安全地持續(xù)地拆？即如何在不影響當(dāng)下系統(tǒng)運(yùn)行狀態(tài)的前提下，持續(xù)安全地演進(jìn)？ 如何保證拆對了？ 拆完了怎么保證不被破壞？ 問題1：如何將單體結(jié)構(gòu)拆分為服務(wù)化架構(gòu)？

就如庖丁解牛一樣，拆分需要摸清內(nèi)部的構(gòu)造脈絡(luò)，在筋骨縫隙處下刀。那么微服務(wù)架構(gòu)中，我們認(rèn)為服務(wù)是業(yè)務(wù)能力的代表，需要圍繞業(yè)務(wù)進(jìn)行組織。拆分的關(guān)鍵在于正確理解業(yè)務(wù)，識別單體內(nèi)部的業(yè)務(wù)領(lǐng)域及其邊界，并按邊界進(jìn)行拆分。

1. 識別業(yè)務(wù)領(lǐng)域及邊界。

首先需要將客戶、體驗(yàn)設(shè)計師、業(yè)務(wù)分析師、技術(shù)人員集結(jié)在一起對業(yè)務(wù)需求進(jìn)行溝通，隨后對其進(jìn)行領(lǐng)域劃分，確定限界上下文(Boundary Context)，也稱戰(zhàn)略建模。

以下我們經(jīng)常使用的方法和參考的紅藍(lán)寶書：

Inception-> User Journey | Scenarios，用于梳理業(yè)務(wù)流程，由粗粒度到細(xì)粒度逐一場景分析。 四色建模，用于提取核心概念、關(guān)鍵數(shù)據(jù)項(xiàng)和業(yè)務(wù)約束。 領(lǐng)域驅(qū)動設(shè)計-戰(zhàn)略設(shè)計，用于劃分領(lǐng)域及邊界、進(jìn)行技術(shù)驗(yàn)證。 Eventstorming，用于提取領(lǐng)域中的業(yè)務(wù)事件，便于正確建模。

Inception與DDD戰(zhàn)略設(shè)計的對比：

一個業(yè)務(wù)領(lǐng)域或子域是一個企業(yè)中的業(yè)務(wù)范圍以及在其中進(jìn)行的活動，核心子域指業(yè)務(wù)成功的主要促成因素，是企業(yè)的核心競爭力；通用子域不是核心，但被整個業(yè)務(wù)系統(tǒng)所使用；支撐子域不是核心，不被整個系統(tǒng)使用，該能力可從外部購買。一個業(yè)務(wù)領(lǐng)域和子域可以包括多個業(yè)務(wù)能力，一個業(yè)務(wù)能力對應(yīng)一個服務(wù)。領(lǐng)域的邊界即限界上下文，也是服務(wù)的邊界，它封裝了一系列的領(lǐng)域模型。

一個業(yè)務(wù)流程代表了企業(yè)的一個業(yè)務(wù)領(lǐng)域，業(yè)務(wù)流程所涉及的數(shù)據(jù)或角色或是通用子域，或是支撐子域，由其在企業(yè)的核心競爭力的角色所決定。比如企業(yè)有統(tǒng)一身份認(rèn)證，決策不同部門負(fù)責(zé)不同的流程任務(wù)，那么身份認(rèn)證子域并不產(chǎn)生業(yè)務(wù)價值，不是業(yè)務(wù)成功的促成因素，但是所有流程的入口，因而為通用子域，可為單獨(dú)服務(wù)；而部門負(fù)責(zé)的業(yè)務(wù)則為核心子域。

舉個例子

工單業(yè)務(wù)流程：

某企業(yè)為服務(wù)人員提供工單服務(wù)的業(yè)務(wù)流程簡化如下。首先搜索服務(wù)人員，選取服務(wù)人員購買的服務(wù)，基于目標(biāo)國家的工單流程，向服務(wù)人員收取資料，對其進(jìn)行審計，最后發(fā)送結(jié)果。

識別的領(lǐng)域：

其中服務(wù)為其核心競爭能力，包括該企業(yè)對全球各國的政策理解，即法律流程，服務(wù)資料（問卷），計算服務(wù)，資料審計服務(wù)，相比其他競爭對手的服務(wù)（價位/效率等），這些都為改企業(yè)提供核心的業(yè)務(wù)價值，自然也是核心子域。而其他用于統(tǒng)計改企業(yè)員工工作的工單，組織結(jié)構(gòu)和員工為支撐子域，并不直接產(chǎn)生業(yè)務(wù)價值

領(lǐng)域劃分的原則

在劃分的過程中，經(jīng)常糾結(jié)的一個問題是：這個模型（概念或數(shù)據(jù)）看起來放這個領(lǐng)域合適，放另一個也合適，如何抉擇呢？

第一，依據(jù)該模型與邊界內(nèi)其他模型或角色關(guān)系的緊密程度。比如，是否當(dāng)該模型變化時，其他模型也需要進(jìn)行變化；該數(shù)據(jù)是否通常由當(dāng)前上下文中的角色在當(dāng)前活動范圍內(nèi)使用。 第二，服務(wù)邊界內(nèi)的業(yè)務(wù)能力職責(zé)應(yīng)單一，不是完成同一業(yè)務(wù)能力的模型不放在同一個上下文中。 第三，劃分的子域和服務(wù)需滿足正交原則。領(lǐng)域名字代表的自然語言上下文保持互相獨(dú)立。 第四，讀寫分離的原則。例如報表需有單獨(dú)報表子域。核心子域的劃分更多基于來自業(yè)務(wù)價值的產(chǎn)生方，而非不產(chǎn)生價值的報表系統(tǒng)。 第五，模型在很多業(yè)務(wù)操作中同時被修改和更新。 第六，組織中業(yè)務(wù)部分的劃分也是一種參考，一個業(yè)務(wù)部門的存在往往有其獨(dú)特的業(yè)務(wù)價值。

簡單打個比方，同一個領(lǐng)域上下文中的模型要保持近親關(guān)系，五福以內(nèi)，同一血統(tǒng)（業(yè)務(wù)）。

領(lǐng)域劃分的誤區(qū)和建議 業(yè)務(wù)能力還是計算能力？在劃分一些貌似通用的領(lǐng)域時，其實(shí)只是用到了通用的計算能力而不是業(yè)務(wù)能力，只需采用通用庫的方式進(jìn)行封裝，而無需使用服務(wù)的方式。如我們系統(tǒng)的模板服務(wù)，是構(gòu)建通用的模板服務(wù)，服務(wù)于整個平臺的服務(wù)；還是每個服務(wù)擁有獨(dú)立的模板模塊？ 盡早識別剝離通用領(lǐng)域。如身份認(rèn)證與鑒權(quán)領(lǐng)域，是企業(yè)系統(tǒng)中最復(fù)雜、有相對多變的領(lǐng)域，需要及早隔離它對核心業(yè)務(wù)的干擾。 時刻促成技術(shù)人員與客戶、業(yè)務(wù)人員的對話。業(yè)務(wù)領(lǐng)域的劃分離不開對業(yè)務(wù)意圖的真正理解。而需求人員和體驗(yàn)設(shè)計師對于User Journey的使用更熟悉，而技術(shù)人員、架構(gòu)師對領(lǐng)域驅(qū)動設(shè)計、Eventstorming更熟悉。不管哪種方法都要求跨角色的群體協(xié)同工作，即客戶人員、業(yè)務(wù)分析師、體驗(yàn)設(shè)計師與技術(shù)人員、架構(gòu)師。而現(xiàn)實(shí)的情況中，User Journey更多的在Inception，在需求階段進(jìn)行，而領(lǐng)域驅(qū)動設(shè)計、Eventstorming更多的在開發(fā)設(shè)計階段被使用，故而需求階段經(jīng)常缺失技術(shù)人員，而開發(fā)設(shè)計階段經(jīng)常缺失客戶、業(yè)務(wù)人員的參與。 另一個常見的現(xiàn)象是，Inception的參與人員和真正的開發(fā)團(tuán)隊(duì)有可能不是同一個群體，那么Inception中的業(yè)務(wù)溝通往往以UI的方式作為傳遞，因此在開發(fā)中經(jīng)常只能通過UI設(shè)計來理解業(yè)務(wù)的真正意圖。 所以要想將正確的理解業(yè)務(wù)，做對軟件，需要時刻促成技術(shù)人員與客戶、業(yè)務(wù)人員的對話。

識別了被拆對象的結(jié)構(gòu)和邊界，下一步需要決定拆分的策略和拆分的步驟。

2.拆分方法與策略

拆分方法需要根據(jù)遺留系統(tǒng)的狀態(tài)，通常分為絞殺者與修繕者兩種模式。

絞殺者模式 指在遺留系統(tǒng)外圍，將新功能用新的方式構(gòu)建為新的服務(wù)。隨著時間的推移，新的服務(wù)逐漸“絞殺”老的一流系統(tǒng)。對于那些老舊龐大難以更改的遺留系統(tǒng)，推薦采用絞殺者模式。 修繕者模式 就如修房或修路一樣，將老舊待修繕的部分進(jìn)行隔離，用新的方式對其進(jìn)行單獨(dú)修復(fù)。修復(fù)的同時，需保證與其他部分仍能協(xié)同功能。

我們過去所做的拆分中多為修繕者模式，其基本原理來自Martin Fowler的branch by abstraction的重構(gòu)方法，如下圖所示：

就如我們團(tuán)隊(duì)所總結(jié)的16字重構(gòu)箴言，我覺得十分的貼切：

“舊的不變，新的創(chuàng)建，一步切換，舊的再見”。

通過識別內(nèi)部的被拆模塊，對其增加接口層，將舊的引用改為新接口調(diào)用；隨后將接口封裝為API，并將對接口的引用改為本地API調(diào)用；最后將新服務(wù)部署為新進(jìn)程，調(diào)用改為真正的服務(wù)API調(diào)用。

同時，拆分建議從業(yè)務(wù)相對獨(dú)立、耦合度最小的地方開始。待團(tuán)隊(duì)獲取相應(yīng)經(jīng)驗(yàn)和基礎(chǔ)設(shè)施平臺構(gòu)建完善后，再進(jìn)行核心應(yīng)用遷移和大規(guī)模的改造。另外，核心通用服務(wù)盡量先行，如身份認(rèn)證服務(wù)。

3. 拆分步驟

對于模塊的拆分包括兩部分：數(shù)據(jù)庫與業(yè)務(wù)代碼，可以先數(shù)據(jù)庫后業(yè)務(wù)代碼，亦可先業(yè)務(wù)代碼后數(shù)據(jù)庫。然而我們的項(xiàng)目拆分中遇到的挑戰(zhàn)是數(shù)據(jù)層的拆分。在2015年的拆分中發(fā)現(xiàn)，數(shù)據(jù)庫層由于當(dāng)時系統(tǒng)性能調(diào)優(yōu)的驅(qū)動，在代碼中出現(xiàn)了跨模塊的數(shù)據(jù)庫連表查詢。這導(dǎo)致后期服務(wù)的拆分非常的困難。因此在拆分步驟上我們更多的推薦數(shù)據(jù)庫先行。

4.數(shù)據(jù)庫拆分

我們借鑒了重構(gòu)數(shù)據(jù)庫一書中提到的方法，通過重復(fù)schema同步數(shù)據(jù)，對數(shù)據(jù)庫的讀寫操作分別進(jìn)行遷移。如下圖所示：

雖然技術(shù)上是可行的，然而這仍然占用了大量不必要的時間，包括大量的數(shù)據(jù)遷移。這也是導(dǎo)致當(dāng)時的拆分無法在給定時間內(nèi)完成的很大因素。

5. 我們的結(jié)果：

系統(tǒng)架構(gòu)圖：

問題2：拆分后業(yè)務(wù)變了增加了怎么辦？

隨著客戶業(yè)務(wù)的變化，我們的服務(wù)也在持續(xù)的增加，而其中碰到了一個特大的服務(wù)。服務(wù)的大小如何衡量呢？該服務(wù)生產(chǎn)代碼7萬行+，測試代碼14萬行+，測試運(yùn)行時間2個小時。團(tuán)隊(duì)中7個stream每天50%工作需要對這個服務(wù)進(jìn)行更改，使得團(tuán)隊(duì)間的依賴非常嚴(yán)重，獨(dú)立功能無法單獨(dú)快速前行，交付速度及質(zhì)量都受到了影響。

我們的總結(jié)：

客戶的業(yè)務(wù)是在變化的，我們對業(yè)務(wù)的認(rèn)知也是逐漸的過程，所以Martin Fowler在他的文章中提出，系統(tǒng)的初期建議以單體結(jié)構(gòu)開始，隨業(yè)務(wù)發(fā)展決定其是否被拆分或合并。那么這也意味著這樣構(gòu)建的服務(wù)在它的生命周期中必然會持續(xù)被拆分或合并。那么為了實(shí)現(xiàn)這樣一個目標(biāo)，使系統(tǒng)擁有快速的響應(yīng)力，也要求這樣的拆分必然是高效的低成本的。

因此，服務(wù)的設(shè)計需要滿足如下的原則：

服務(wù)要有明確的業(yè)務(wù)邊界，以單體開始并不意味著沒有邊界。 服務(wù)要有邊界，即使以單體開始也要定義單體時期的邊界。我們系統(tǒng)中有一個名為“Monkey”的服務(wù)，是在中國虎年啟動的，由此它并不是一個業(yè)務(wù)概念。當(dāng)這個服務(wù)的名字為MonkeyAPI時，可以想象5年來它變成了什么？幾乎所有和這個產(chǎn)品相關(guān)的功能都放入了這個服務(wù)中。脫離平臺來看這一個產(chǎn)品的系統(tǒng)，其實(shí)它只是做了前后端分離而已。這個例子告訴我們，沒有邊界就會導(dǎo)致大雜燴，之后對其進(jìn)行整理和重造的代價很大，可能需要花費(fèi)“幾代人”的努力。 服務(wù)要有明確清晰的契約設(shè)計，即對外提供的業(yè)務(wù)能力。 服務(wù)內(nèi)部要保持高度模塊化，才能夠容易的被拆分。 可測試。 問題3：如何安全地持續(xù)地拆？

就如前言中提到的，系統(tǒng)已經(jīng)上線大量的用戶正在使用，如何在不影響當(dāng)下系統(tǒng)運(yùn)行狀態(tài)的前提下，持續(xù)安全地演進(jìn)？其實(shí)持續(xù)演進(jìn)就是一場架構(gòu)層次的重構(gòu)，在這樣的路上同樣需要：

壞味道驅(qū)動，架構(gòu)的壞味道是代碼壞味道在更高層次的展現(xiàn)，也就意味著架構(gòu)的混亂程度同樣反映了該系統(tǒng)代碼層的質(zhì)量問題。 安全小步的重構(gòu)。 有足夠的測試進(jìn)行保護(hù)——契約測試。 持續(xù)驗(yàn)證演進(jìn)的方向。 真正有挑戰(zhàn)的問題4：如何保證拆對了？

拆分不能沒有目標(biāo)，尤其在具有風(fēng)險的架構(gòu)層次拆分更需謹(jǐn)慎。那么我們?nèi)绾悟?yàn)證拆分的結(jié)果和收益？或許它可以提高開發(fā)效率，交付速度快，上線快，宕機(jī)時間也短，還能提高開發(fā)質(zhì)量，可擴(kuò)展性好，穩(wěn)定，維護(hù)成本低，新人成長快，團(tuán)隊(duì)容易掌握等等。然而軟件開發(fā)是一個復(fù)雜的事情，拆分可以引起多個維度的變化，度量的難度在于如何準(zhǔn)確定位由拆分這一單一因素引起的價值的變化（增加或降低）。

其實(shí)要回答這個問題，還是要回到拆分之初：為什么而拆？ 我所見過的案例中有因?yàn)檎卧虿鸬?、業(yè)務(wù)發(fā)展需要的、系統(tǒng)集成驅(qū)動的等等；有因之而成功的，也有因之而失敗的。拆并不是一件容易的事，有諸多的因素。我認(rèn)為不管表象是什么，拆之前需要弄清拆分的價值所在，這也是我們可以保證拆分結(jié)果的源頭。

總結(jié)

系統(tǒng)可由單體結(jié)構(gòu)開始，不斷的演進(jìn)。而團(tuán)隊(duì)需要對業(yè)務(wù)保持敏感，與客戶、業(yè)務(wù)人員進(jìn)行業(yè)務(wù)對話，不斷修煉領(lǐng)域驅(qū)動設(shè)計和重構(gòu)的能力。

在拆分的路上，我們的經(jīng)驗(yàn)顯示其的障礙來自意大利面一樣的系統(tǒng)。不管我們是什么樣的架構(gòu)風(fēng)格，高內(nèi)聚低耦合的模塊化代碼內(nèi)部質(zhì)量仍然是我們架構(gòu)演進(jìn)的基石。具有夯實(shí)領(lǐng)域驅(qū)動設(shè)計和重構(gòu)功底的團(tuán)隊(duì)才可以應(yīng)對這些挑戰(zhàn)，持續(xù)演進(jìn)，保持其生命力。而架構(gòu)變遷之前需要弄清背后的變遷動因與價值，探索性前進(jìn)，及時反饋驗(yàn)證，才是正解。那么我們?nèi)绾伪ＷC架構(gòu)不被破壞呢？這個問題會在后續(xù)的文章中持續(xù)探討。

最后，勿忘初心，且行且演進(jìn)。

標(biāo)題名稱：服務(wù)拆分與架構(gòu)演進(jìn)
本文鏈接：http://aaarwkj.com/article42/chdphc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供微信公眾號、建站公司、服務(wù)器托管、標(biāo)簽優(yōu)化、搜索引擎優(yōu)化、企業(yè)網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)