背景
在日常業(yè)務(wù)的研發(fā)過程中，由于需求的緊迫性，往往留給研發(fā)團(tuán)隊(duì)的時(shí)間相對(duì)有限。這種情況下，為了確保業(yè)務(wù)盡快上線，不得不在一定程度上犧牲設(shè)計(jì)的嚴(yán)謹(jǐn)性和技術(shù)的前瞻性，雖然短期內(nèi)看似解決了燃眉之急，但長(zhǎng)此以往，卻逐漸累積了大量的技術(shù)債務(wù)。
技術(shù)債，又稱設(shè)計(jì)債或代碼債，是指在軟件開發(fā)過程中為了追求快速交付而采取的非最佳實(shí)現(xiàn)方式所帶來(lái)的后續(xù)成本。這種“債務(wù)”可能源于使用了臨時(shí)性的解決方案、忽略了代碼質(zhì)量、或沒有遵循良好的設(shè)計(jì)原則和實(shí)踐。
隨著技術(shù)復(fù)雜度的逐步提升，系統(tǒng)的可維護(hù)性不可避免地受到侵蝕。這種演變并非線性的遞增，而是呈現(xiàn)出指數(shù)級(jí)的增長(zhǎng)趨勢(shì)，最終會(huì)導(dǎo)致需求吞吐、交付質(zhì)量雙雙下降。
為進(jìn)一步提升服務(wù)品質(zhì)和用戶體驗(yàn)，斗拱進(jìn)件板塊決定啟動(dòng)客戶全旅程項(xiàng)目，實(shí)施客戶體驗(yàn)的深度改造。但是在整個(gè)項(xiàng)目的研發(fā)實(shí)施過程中，工程師們發(fā)現(xiàn)由于業(yè)務(wù)邏輯與系統(tǒng)模塊的復(fù)雜與緊耦合，在開發(fā)的時(shí)候碰到了較多的困難與挑戰(zhàn)，包括研發(fā)代碼的周期與測(cè)試的質(zhì)量等等，雖然最終有驚無(wú)險(xiǎn)，順利完成交付，但是我們發(fā)現(xiàn)，進(jìn)件系統(tǒng)的維護(hù)與擴(kuò)展已進(jìn)入一個(gè)新的難度等級(jí)，必須啟動(dòng)戰(zhàn)略性重構(gòu)升級(jí)計(jì)劃，為業(yè)務(wù)可持續(xù)發(fā)展夯實(shí)基礎(chǔ)。
問題分析
經(jīng)過多年的持續(xù)迭代投入，斗拱的整套進(jìn)件體系功能越來(lái)越強(qiáng)大，代碼量也越來(lái)越多，一次完整的進(jìn)件，要由大量的微服務(wù)共同協(xié)作完成。從應(yīng)用架構(gòu)層面，進(jìn)件系統(tǒng)可分為：以領(lǐng)域?qū)訛閺?fù)用核心，以功能層為交付重心，以交互層為體驗(yàn)迭代中心，這樣的一套三層架構(gòu)體系：
● 交互層：包含API、WEB頁(yè)、APP等交互邏輯與服務(wù)；
● 功能層：組合領(lǐng)域?qū)釉咏涌冢纬蓸I(yè)務(wù)功能向交互層輸出；
● 領(lǐng)域?qū)樱禾峁┏橄筮^后的原子服務(wù)能力，場(chǎng)景關(guān)聯(lián)性弱；
該分層架構(gòu)在人員配備充足，業(yè)務(wù)及團(tuán)隊(duì)穩(wěn)定的情況下，是能夠充分發(fā)揮其設(shè)計(jì)效能的。然而，隨著斗拱業(yè)務(wù)規(guī)模的持續(xù)擴(kuò)大，面對(duì)多產(chǎn)品線高并發(fā)迭代的工程挑戰(zhàn)與客戶需求的爆發(fā)式增長(zhǎng)態(tài)勢(shì)，研發(fā)資源的配置根本滿足不了業(yè)務(wù)的吞吐速率要求。為確保重要業(yè)務(wù)目標(biāo)的順利交付，部分團(tuán)隊(duì)不得不采用敏捷交付機(jī)制，在架構(gòu)設(shè)計(jì)層面進(jìn)行必要的動(dòng)態(tài)平衡——通過建立架構(gòu)治理框架下的技術(shù)決策機(jī)制，允許在關(guān)鍵路徑上實(shí)施階段性靈活調(diào)整，同時(shí)為體系化重構(gòu)預(yù)留技術(shù)窗口。
其次，在推進(jìn)支付平臺(tái)化建設(shè)的戰(zhàn)略進(jìn)程中，由于缺乏成熟的范式可供參考，我們特地組建了專門的技術(shù)委員會(huì)。面對(duì)各行各業(yè)的多樣化需求、各類用戶角色以及紛繁復(fù)雜的場(chǎng)景故事，如何在一套平臺(tái)上實(shí)現(xiàn)這些功能，成為了委員會(huì)頻繁討論的焦點(diǎn)：是沉淀復(fù)用還是個(gè)性化定制？是僅考慮某一端還是全面支持所有端？是做到交互層、功能層還是領(lǐng)域?qū)樱扛鞣接^點(diǎn)不一，但都有其獨(dú)到之處。
長(zhǎng)期運(yùn)作下來(lái)，進(jìn)件系統(tǒng)各層級(jí)，都在大規(guī)模的并行迭代，以致于：
第一，用戶交互層與功能層之間，出現(xiàn)了比較多的冗余邏輯，加劇了系統(tǒng)的復(fù)雜度。
第二，功能層與領(lǐng)域?qū)又g，也存在相似的重復(fù)代碼現(xiàn)象，技術(shù)債務(wù)累積。
再者，功能層主要由管理服務(wù)和查詢服務(wù)兩個(gè)團(tuán)隊(duì)負(fù)責(zé)。其中，管理服務(wù)涵蓋了客戶體驗(yàn)的方方面面，包括但不限于進(jìn)件材料與流程、業(yè)務(wù)配置與開通、協(xié)議簽署，以及一系列配套的運(yùn)營(yíng)支撐功能。這些功能不僅要滿足標(biāo)準(zhǔn)化的業(yè)務(wù)需求，還需兼顧用戶的功能體驗(yàn)和重點(diǎn)客戶的個(gè)性化定制。隨著時(shí)間的推移，管理服務(wù)逐漸變得愈加龐大復(fù)雜，后續(xù)的維護(hù)與擴(kuò)展難度也隨之逐步增加。
最終，管理服務(wù)成為了交付瓶頸，需求越積越多。當(dāng)新增客戶全旅程這樣一個(gè)非常大的業(yè)務(wù)能力時(shí)，我們來(lái)到了復(fù)雜度指數(shù)上升的邊沿。
重構(gòu)思路
重構(gòu)（Refactoring），即還技術(shù)債，是指在不改變軟件外部行為的前提下，對(duì)軟件內(nèi)部結(jié)構(gòu)進(jìn)行優(yōu)化和調(diào)整的過程。其主要目的是提高代碼的可讀性、可維護(hù)性和可擴(kuò)展性，從而降低后續(xù)開發(fā)和維護(hù)的成本，提升交付質(zhì)量和效率。
論及重構(gòu)，領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（DDD）無(wú)疑是最先映入腦海的方法論。沒錯(cuò)，我們也正是借助DDD的戰(zhàn)略設(shè)計(jì)，對(duì)子域進(jìn)行了重新劃分，形成商戶、審核、協(xié)議等子域，通過DDD的戰(zhàn)術(shù)設(shè)計(jì)，將一些共通的邏輯提煉出來(lái)，形成業(yè)務(wù)權(quán)限、計(jì)費(fèi)等模塊。
領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（Domain-Driven Design，簡(jiǎn)稱DDD）是一種軟件設(shè)計(jì)方法論，它強(qiáng)調(diào)以業(yè)務(wù)領(lǐng)域?yàn)楹诵倪M(jìn)行軟件設(shè)計(jì)，通過創(chuàng)建豐富的領(lǐng)域模型來(lái)反映業(yè)務(wù)邏輯，從而實(shí)現(xiàn)業(yè)務(wù)和技術(shù)的統(tǒng)一。
整個(gè)重構(gòu)落地也是非常復(fù)雜，為了確保業(yè)務(wù)連續(xù)性不受影響，我們通過系統(tǒng)化、工程化的手段，分批次啟動(dòng)項(xiàng)目實(shí)施。整體分為兩大階段：
階段一：領(lǐng)域拆分與沉淀
1、原斗拱進(jìn)件板塊，按照DDD的設(shè)計(jì)思想，重新進(jìn)行領(lǐng)域的劃分；
2、按照新的劃分(子域A、子域B...)，將交互層、功能層的邏輯沉淀到各個(gè)領(lǐng)域；
3、擴(kuò)充領(lǐng)域職能，使其不僅提供內(nèi)部服務(wù)，同時(shí)提供對(duì)外的API及應(yīng)用組件；
核心思路：把原先按功能職責(zé)拆分的橫向切分架構(gòu)，重構(gòu)為按領(lǐng)域職責(zé)拆分的縱向切分架構(gòu)，如下圖所示：
階段二：領(lǐng)域模塊升級(jí)優(yōu)化
1、在每個(gè)領(lǐng)域內(nèi)，針對(duì)較難維護(hù)的領(lǐng)域模塊，進(jìn)行二次重構(gòu)、升級(jí)、優(yōu)化；
核心思路：各個(gè)領(lǐng)域團(tuán)隊(duì)內(nèi)部不定期發(fā)起重構(gòu)（可能大可能小），升級(jí)優(yōu)化自身負(fù)責(zé)的系統(tǒng)代碼，提升其可維護(hù)性及可擴(kuò)展性。
本篇文章中，我們主要探討階段一，后續(xù)的重構(gòu)文章系列中，我們?cè)僦鸩教接戨A段二的技術(shù)故事。
領(lǐng)域拆分與沉淀
1、領(lǐng)域劃分
在啟動(dòng)重構(gòu)之前，至關(guān)重要的是要進(jìn)行廣泛而深入的溝通與交流，以明確各個(gè)領(lǐng)域的定義、內(nèi)容及其邊界。這一過程中，我們應(yīng)用DDD方法論，圍繞用戶故事對(duì)上層服務(wù)的業(yè)務(wù)邏輯，尤其是功能服務(wù)進(jìn)行全面梳理。此環(huán)節(jié)需大量業(yè)務(wù)專家及系統(tǒng)負(fù)責(zé)人的積極參與，經(jīng)過多輪次的討論與碰撞，最終達(dá)成共識(shí)，并明確各領(lǐng)域的負(fù)責(zé)人。
接下來(lái)，我們將斗拱進(jìn)件的對(duì)外API接口清單、控臺(tái)頁(yè)面菜單、內(nèi)部功能服務(wù)接口清單逐一列出，并根據(jù)其所屬領(lǐng)域進(jìn)行歸類。對(duì)于那些同時(shí)涉及多個(gè)領(lǐng)域的頁(yè)面、內(nèi)外接口，就由熟悉相關(guān)業(yè)務(wù)的領(lǐng)導(dǎo)根據(jù)其經(jīng)驗(yàn)作出決策，給到最合適的領(lǐng)域。
一旦確定了領(lǐng)域歸屬，接下來(lái)的任務(wù)便是從代碼層面著手，對(duì)所有的API服務(wù)、頁(yè)面及BFF（Backend For Frontend）服務(wù)、功能服務(wù)進(jìn)行改造與遷移工作，將其合理地拆分并沉淀到各自對(duì)應(yīng)的領(lǐng)域服務(wù)中。
2、代碼實(shí)施
整個(gè)代碼實(shí)施過程，分為五步：著色->代碼拆分->服務(wù)拆分>數(shù)據(jù)庫(kù)拆分->整理&優(yōu)化。
步驟一：著色
對(duì)后端BFF服務(wù)、功能層服務(wù)中，所有Public的API方法、Service方法、Repository方法等，添加自定義@Domain注解，以標(biāo)識(shí)其所屬領(lǐng)域。對(duì)于被多個(gè)領(lǐng)域同時(shí)使用的公共方法，要么標(biāo)記多個(gè)領(lǐng)域名稱，要么標(biāo)記為All，即所有領(lǐng)域。
說明：此過程同樣涉及大量討論與交流。為了最終達(dá)成共識(shí)，建議按固定一個(gè)人的拆分思路統(tǒng)一開展，出現(xiàn)爭(zhēng)議由其來(lái)拍板，以免陷入無(wú)休止的爭(zhēng)辯而無(wú)法說服彼此的局面。
步驟二：代碼拆分
在不改變服務(wù)化結(jié)構(gòu)以及微服務(wù)調(diào)用入口的前提下，將@Domain標(biāo)記的代碼及其遞歸引用的私有代碼，全部復(fù)制到為各個(gè)領(lǐng)域新建的獨(dú)立工程目錄中，此時(shí)需修改方法提供方及方法調(diào)用方相應(yīng)的import包路徑，標(biāo)記多個(gè)領(lǐng)域的方法就復(fù)制多份，標(biāo)記為All的公共方法，就每個(gè)域都復(fù)制一份。
說明：這個(gè)過程比較復(fù)雜的地方是依賴識(shí)別，我們是在Idea插件的基礎(chǔ)上自主研發(fā)工具實(shí)現(xiàn)的。遷移完成后，新版本在生產(chǎn)環(huán)境中運(yùn)行至少兩周，以驗(yàn)證其穩(wěn)定性和可靠性。
步驟三：服務(wù)拆分
在調(diào)用入口不變的前提下，將跨領(lǐng)域的內(nèi)存調(diào)用代碼，轉(zhuǎn)成微服務(wù)遠(yuǎn)程調(diào)用代碼。此時(shí)，微服務(wù)的數(shù)量會(huì)顯著增加，大致等于被拆分微服務(wù)個(gè)數(shù)乘以領(lǐng)域數(shù)量，此時(shí)每個(gè)服務(wù)就可以獨(dú)立迭代需求了。同樣，該過程也是通過工具完成，微服務(wù)調(diào)用代碼是按統(tǒng)一模版格式生成的，所以類及方法的命名會(huì)存在一些不人性化的情況。
說明：這個(gè)過程會(huì)遇到比較多的問題，如：內(nèi)存全局變量問題、數(shù)據(jù)庫(kù)事務(wù)問題、抽象繼承類問題、異步通知問題、超時(shí)時(shí)長(zhǎng)設(shè)置問題等，我們?cè)诤罄m(xù)的重構(gòu)系列文章中再行展開。遷移完成后，新版本在生產(chǎn)環(huán)境中至少穩(wěn)定運(yùn)行兩周，代表該階段的完成。
步驟四：數(shù)據(jù)庫(kù)拆分
為各領(lǐng)域創(chuàng)建獨(dú)立的數(shù)據(jù)庫(kù)，并將各領(lǐng)域獨(dú)有的庫(kù)表及數(shù)據(jù)內(nèi)容遷移至新庫(kù)中。針對(duì)那些跨多個(gè)領(lǐng)域的共享表，則要進(jìn)行數(shù)據(jù)拆分與遷移，該一步驟相比前面的代碼拆分、服務(wù)拆分，工作量和復(fù)雜度都有顯著上升。鑒于該步驟短期內(nèi)難以完成，同時(shí)考慮到以下實(shí)際情況，我們決定暫時(shí)擱置，未來(lái)?yè)駲C(jī)實(shí)施：
● 對(duì)所有數(shù)據(jù)庫(kù)表，進(jìn)行領(lǐng)域歸屬劃分，每張表僅歸屬一個(gè)域，針對(duì)該表的結(jié)構(gòu)及關(guān)鍵數(shù)據(jù)變更，均由所屬領(lǐng)域團(tuán)隊(duì)完成，避免引入跨領(lǐng)域協(xié)作問題；
● 在服務(wù)拆分階段時(shí)，大部分跨領(lǐng)域的數(shù)據(jù)操作都已轉(zhuǎn)成微服務(wù)調(diào)用，只有少數(shù)因性能、事務(wù)等考量的查詢，直接通過Mapper跨庫(kù)訪問。
● 跨域共享表的數(shù)量不多，由其他域代為維護(hù)的規(guī)模不大，復(fù)雜度尚在可控范圍內(nèi)；
步驟五：整理&優(yōu)化
拆到各個(gè)領(lǐng)域的微服務(wù)，整體是包含了原后端BFF服務(wù)、功能服務(wù)全部的源代碼，工程包非常大，類也非常多。各個(gè)團(tuán)隊(duì)需要手動(dòng)整理這些代碼，剔除不屬于本領(lǐng)域的部分以及未被使用到的函數(shù)和方法。此外，對(duì)于那些在服務(wù)拆分階段產(chǎn)生的工具型微服務(wù)接口，我們使用@Deprecated注解予以標(biāo)記，明確表示這些接口不再接受迭代更新，若未來(lái)有需求要迭代，則按照標(biāo)準(zhǔn)的接口規(guī)范重新設(shè)計(jì)實(shí)施，以此逐步淘汰工具型的接口。
3、重構(gòu)效果
在歷時(shí)三個(gè)多月的項(xiàng)目實(shí)施過程中，我們遇到各種各樣的挑戰(zhàn)，也逐一克服。整個(gè)項(xiàng)目的復(fù)雜度極高，參與進(jìn)來(lái)的都是各團(tuán)隊(duì)的核心成員及眾多資深架構(gòu)師。最終，項(xiàng)目也取得了令人矚目的成果。
從業(yè)務(wù)角度統(tǒng)計(jì)，進(jìn)件相關(guān)需求的交付吞吐率提升了30%，缺陷密度（上線100個(gè)需求引入的缺陷數(shù)）下降30%。
從技術(shù)層面來(lái)看，日常需求的協(xié)作模式從原先前端、功能和領(lǐng)域的多方協(xié)作，演變?yōu)閱蝹€(gè)領(lǐng)域團(tuán)隊(duì)為主；所有原領(lǐng)域?qū)友邪l(fā)人員全面參與到業(yè)務(wù)開發(fā)中，顯著提升了他們的業(yè)務(wù)經(jīng)驗(yàn)；所有技術(shù)TL積極參與了領(lǐng)域邊界的討論，對(duì)各自邊界有統(tǒng)一清晰的認(rèn)識(shí)，很少再出現(xiàn)邊界爭(zhēng)論；原功能層的管理服務(wù)，在經(jīng)過重點(diǎn)拆分和沉淀后，系統(tǒng)的維護(hù)復(fù)雜度明顯降低。
總結(jié)
斗拱進(jìn)件體系的重構(gòu)實(shí)踐，充分彰顯了直面技術(shù)債務(wù)的重要性。通過縝密規(guī)劃與嚴(yán)謹(jǐn)執(zhí)行，我們不僅實(shí)現(xiàn)了重構(gòu)的目標(biāo)，還顯著提升了業(yè)務(wù)和技術(shù)效能。這不僅是對(duì)技術(shù)架構(gòu)的一次優(yōu)化，更是團(tuán)隊(duì)協(xié)作能力與技術(shù)實(shí)力的全面提升。
免責(zé)聲明：以上內(nèi)容為本網(wǎng)站轉(zhuǎn)自其它媒體，相關(guān)信息僅為傳遞更多信息之目的，不代表本網(wǎng)觀點(diǎn)，亦不代表本網(wǎng)站贊同其觀點(diǎn)或證實(shí)其內(nèi)容的真實(shí)性。如稿件版權(quán)單位或個(gè)人不想在本網(wǎng)發(fā)布，可與本網(wǎng)聯(lián)系，本網(wǎng)視情況可立即將其撤除。
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。
