簡介

在業(yè)務(wù)開發(fā)的過程中，往往存在平臺代碼和業(yè)務(wù)代碼耦合嚴(yán)重難以分離、業(yè)務(wù)和業(yè)務(wù)之間代碼交織缺少拆解的現(xiàn)象。平臺和業(yè)務(wù)代碼交織導(dǎo)致不易修改，不同業(yè)務(wù)的代碼交織增加了不同負(fù)責(zé)團(tuán)隊之間的協(xié)同成本。因此不論從代碼質(zhì)量，還是從團(tuán)隊協(xié)作的角度來看都嚴(yán)重地影響了開發(fā)團(tuán)隊之間的協(xié)同效率和開發(fā)效率，最終影響到了用戶體驗和業(yè)務(wù)發(fā)展。在閑魚，商品發(fā)布和編輯功能也是如此。本文將以閑魚商品發(fā)布和編輯功能的改造為例，向大家展示閑魚是如何解決此類問題，從而更有效地協(xié)同更多團(tuán)隊更快更穩(wěn)定地支撐各種業(yè)務(wù)的。

發(fā)布編輯功能的升級改造

為了實現(xiàn)上述目標(biāo)，針對發(fā)布和編輯功能，進(jìn)行了兩輪升級。第一輪的目標(biāo)在于“平臺和業(yè)務(wù)分離、業(yè)務(wù)和業(yè)務(wù)隔離”；而第二輪將更進(jìn)一步，目標(biāo)在于“系統(tǒng)之間的解耦合，提升團(tuán)隊協(xié)同效率”。

1.平臺和業(yè)務(wù)分離，業(yè)務(wù)和業(yè)務(wù)隔離

第一輪改造中，閑魚將原先的商品發(fā)布和編輯功能從老應(yīng)用中抽取到了新應(yīng)用item。為了實現(xiàn)“平臺和業(yè)務(wù)分離、業(yè)務(wù)和業(yè)務(wù)隔離”的目標(biāo)，閑魚自研了一套技術(shù)框架SWAK，具體請參考文章《業(yè)務(wù)代碼解構(gòu)利器--SWAK》，該文介紹了其設(shè)計思想和實現(xiàn)原理。接入SWAK框架后，平臺邏輯和業(yè)務(wù)邏輯得到了分離，各個業(yè)務(wù)（如租房業(yè)務(wù)、免費送業(yè)務(wù)）之間的邏輯也不再耦合，而是變成package隔離（當(dāng)然也是可以做成jar包隔離）。

看一看改造后的應(yīng)用情況示意圖：

• 我們根據(jù)發(fā)布和編輯的主干流程，抽象了17個SWAK擴(kuò)展點。
• 發(fā)布和編輯的主干流程主要就是對這些擴(kuò)展點的編排。主干流程的編寫并不需要考慮業(yè)務(wù)上怎么實現(xiàn)這些擴(kuò)展點的。
• 我們根據(jù)不同的業(yè)務(wù)(在SWAK里面更準(zhǔn)確的表述是tag)對這些擴(kuò)展點進(jìn)行了各自的實現(xiàn)。

根據(jù)這樣的開發(fā)方式，我們可以把開發(fā)同學(xué)分成如下的兩種角色：

• 各業(yè)務(wù)開發(fā)人員。各業(yè)務(wù)開發(fā)人員主要是負(fù)責(zé)各個業(yè)務(wù)相關(guān)的代碼。在item應(yīng)用里面，業(yè)務(wù)同學(xué)需要維護(hù)其業(yè)務(wù)中和發(fā)布編輯相關(guān)的個性化業(yè)務(wù)邏輯。
• 主干開發(fā)人員。主干的人員只需要維護(hù)主干的代碼，尤其是擴(kuò)展點的抽象。隨著不同業(yè)務(wù)的不斷接入，原先的擴(kuò)展點也需要隨之調(diào)整。

如在之前的《業(yè)務(wù)代碼解構(gòu)利器--SWAK》一文中指出的一樣，經(jīng)過SWAK改造后，獲得了如下的幾個優(yōu)點：

• 代碼邏輯清晰，可變和不可變一目了然。

• 代碼復(fù)用度變高。
• 可變邏輯按照標(biāo)簽進(jìn)行隔離，單個標(biāo)簽的實現(xiàn)不會影響到其他標(biāo)簽的實現(xiàn)，降低開發(fā)和測試成本。無論是按照“類型”分還是按照類目分，對應(yīng)的開發(fā)和測試同學(xué)只需要關(guān)注對應(yīng)的邏輯即可。
• 新接手的開發(fā)人員能夠快速理解，輕松上手。

2.系統(tǒng)之間的解耦合，提升團(tuán)隊協(xié)同效率

以租房為例——租房業(yè)務(wù)的同學(xué)需要在item應(yīng)用中維護(hù)一套租房發(fā)布編輯相關(guān)的邏輯（如校驗地小區(qū)數(shù)據(jù)、地鐵數(shù)據(jù)真實性等）；租房業(yè)務(wù)的同學(xué)還需要在詳情應(yīng)用的邏輯中維護(hù)一套和租房詳情相關(guān)的邏輯（如展示地圖，展示內(nèi)部設(shè)施標(biāo)簽）；租房業(yè)務(wù)的同學(xué)還需要在交易應(yīng)用的邏輯中維護(hù)一套和租房交易相關(guān)的邏輯（如預(yù)約看房）等等。租房的同學(xué)不僅僅需要著手于自己的代碼邏輯，還需要修改發(fā)布和編輯應(yīng)用item、還需要修改詳情應(yīng)用，還需要修改交易應(yīng)用......這種體驗是非常糟糕的，有極大的可能性接手一個簡單業(yè)務(wù)就需要修改和發(fā)布四五個應(yīng)用。

另一方面，從主干開發(fā)人員的角度來說，其應(yīng)用不僅僅由自己或自己的小團(tuán)隊來維護(hù)，還有很多業(yè)務(wù)開發(fā)人員也在修改和發(fā)布此應(yīng)用，且頻率會遠(yuǎn)遠(yuǎn)超過主干開發(fā)任務(wù)的發(fā)布和部署頻次（否則就是主干擴(kuò)展點邏輯抽取得不好了）。這不利于整個應(yīng)用的穩(wěn)定性。A業(yè)務(wù)服務(wù)掛了，應(yīng)該只影響A業(yè)務(wù)，而不應(yīng)該影響主干。依此邏輯，最好能做到JVM隔離。本質(zhì)上來說，第一輪改造完成了業(yè)務(wù)之間的解耦合，而第二輪則是系統(tǒng)之間的解耦合。

康威定律告訴我們：

Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure.

簡而言之就是人員組織結(jié)構(gòu)和系統(tǒng)結(jié)構(gòu)之間的一致性。而完成系統(tǒng)之間的解耦合又恰恰是符合康威定律的。這一輪的改造，我們稱之為“業(yè)務(wù)服務(wù)化”。

業(yè)務(wù)服務(wù)化改造方案

• 首先，我們把租房業(yè)務(wù)給單獨抽取出來。原先的帖子和拍賣業(yè)務(wù)暫時沒有獨立的團(tuán)隊來予以維護(hù)（但也基本上沒有什么新需求）因此暫時仍然放在主干應(yīng)用中，時機(jī)合適將會和租房應(yīng)用一樣遷移出去。
• 其次，租房業(yè)務(wù)通過遠(yuǎn)程服務(wù)的方式給主干應(yīng)用提供服務(wù)。接口即是主干業(yè)務(wù)的提供的擴(kuò)展點。由于現(xiàn)在是優(yōu)先使用遠(yuǎn)程服務(wù)來連接主干應(yīng)用和垂直應(yīng)用，考慮到性能問題和安全問題，我們在擴(kuò)展點的定義上也做了一些特殊的改動，后文會有針對性的詳述。
• 最后，SWAK框架做了一些改變以注冊和調(diào)用遠(yuǎn)程服務(wù)。相對于本地服務(wù)，遠(yuǎn)程服務(wù)一般都是有超時、連接異常等問題。然而不同接口對于這些異常情況其處理策略也是截然不同的，后文“SWAK框架的針對性改進(jìn)”會詳述這些改動。

通過這種方式，我們將主干應(yīng)用和各業(yè)務(wù)應(yīng)用徹底分離了。仍然以租房業(yè)務(wù)為例，租房團(tuán)隊負(fù)責(zé)開發(fā)和維護(hù)租房業(yè)務(wù)的獨立應(yīng)用rent。租房個性化的發(fā)布和編輯需求只需要開發(fā)和部署rent應(yīng)用，而不必修改主干應(yīng)用。主干應(yīng)用只由主干團(tuán)隊的同學(xué)負(fù)責(zé)維護(hù)，不會被其他業(yè)務(wù)團(tuán)隊的同學(xué)所開發(fā)和部署，穩(wěn)定性更加能得以保障。各業(yè)務(wù)系統(tǒng)獨立開發(fā)、獨立部署。這些都大幅地減少了不必要的溝通成本、提升協(xié)同效率。

主干應(yīng)用和業(yè)務(wù)應(yīng)用是通過薄薄的一層接口所聯(lián)系起來的，這層薄薄的接口都是“聲明”：Interface定義、DO的定義和擴(kuò)展點的默認(rèn)Reduce策略定義。

SWAK框架的針對性改進(jìn)

在之前的《業(yè)務(wù)代碼解構(gòu)利器--SWAK》一文中指出了，SWAK框架在應(yīng)用啟動的時候會通過各種注冊器(registery)注冊框架所需的信息。其中最重要的信息就是——業(yè)務(wù)tag及其對應(yīng)的SWAK接口的實現(xiàn)類類名或者類實例instance。大多RPC框架都會在client端提供一個代理，代理掉內(nèi)部的服務(wù)發(fā)現(xiàn)、?；睢⑿蛄谢?、網(wǎng)絡(luò)通信、反序列化等一系列操作。實際上，SWAK為了支持遠(yuǎn)程服務(wù)調(diào)用，只需要將業(yè)務(wù)tag，以及這些RPC的client的instance的對應(yīng)關(guān)系注冊進(jìn)去就可以了。在閑魚，RPC使用的是阿里通用的HSF框架(其類似的一個開源框架是Dubbo)，這里的RPC的client就是HSF中的ConsumerBean。

上文還提到了RPC調(diào)用會引入服務(wù)超時、連接異常的概念。為何要限制超時？是因為不能被單個應(yīng)用的超時占據(jù)了主干應(yīng)用的服務(wù)資源而引起其他服務(wù)和整個應(yīng)用系統(tǒng)受到影響（如大多數(shù)線程阻塞在超時調(diào)用上）。無論是超時異常還是連接異常，在業(yè)務(wù)上也有對應(yīng)的處理策略。在這里，我們定義了三種異常處理策略，通過在配置上設(shè)置相應(yīng)的注解，SWAK框架會自動按照策略來處理異常。這三種策略是：

• IGNORE。 即，直接向上層拋出異常。
• SKIP。對于一個接口有多個tag執(zhí)行的時候，本tag下該擴(kuò)展點將跳過，繼續(xù)執(zhí)行其他tag下該擴(kuò)展點的實現(xiàn)。
• DEFAULT_VALUE。返回默認(rèn)值。默認(rèn)值通過spel表達(dá)式進(jìn)行設(shè)置。

減少擴(kuò)展點數(shù)量

眾所周知，RPC調(diào)用相對于本地調(diào)用會增加一部分的網(wǎng)絡(luò)傳輸和序列化開銷。對于單次調(diào)用來說，增加若干ms并沒有什么問題，但對于調(diào)用10次、20次或更多，這筆開銷就相當(dāng)可觀而應(yīng)該引起重視了。為此，如何降低RPC開銷，是一個必須要考慮的問題。

最可靠的方法就是降低RPC的次數(shù)。

在實踐中我們發(fā)現(xiàn)，很多擴(kuò)展點實際上都是獲取業(yè)務(wù)配置。如在閑魚業(yè)務(wù)中，“是否支持多庫存”就是一種配置，如租房不支持多庫存。這些業(yè)務(wù)配置項是由其業(yè)務(wù)形態(tài)所決定的，基本不會變動。因此可以將一組配置項打包一起調(diào)用，并且可以緩存下來，也可以直接由主干應(yīng)用進(jìn)行維護(hù)。在item應(yīng)用里，這些配置項關(guān)系到主干的通用存儲過程，目前由各業(yè)務(wù)方委托主干開發(fā)人員進(jìn)行維護(hù)，目前配置在主干環(huán)境。可以通過阿里的動態(tài)配置平臺（如Switch、Diamond）進(jìn)行動態(tài)修改。

另外我們對部分鄰接的擴(kuò)展點進(jìn)行了合并。這些相鄰擴(kuò)展點之間的邏輯比較簡單，且不會中斷主流程。通過“配置型接口”和“鄰接擴(kuò)展點合并”這兩種操作，我們將擴(kuò)展點數(shù)量降低由17個降低到了6個。要注意的是，擴(kuò)展點并不是越少越好。擴(kuò)展點越少，越意味著“過度擬合”，可能會對后續(xù)業(yè)務(wù)變更無法適應(yīng)導(dǎo)致主干需要大幅改動，因此需要在數(shù)量和擴(kuò)展性之間找到一個平衡。

另外值得一提的是，SWAK為配置型擴(kuò)展點做了相應(yīng)的小改造，并提供了查看當(dāng)前配置型擴(kuò)展點返回值的可視化界面。開發(fā)人員可以直觀地了解當(dāng)前各個業(yè)務(wù)的配置值。

接口對象定義和細(xì)節(jié)設(shè)計

在閑魚，各種業(yè)務(wù)所需要存儲的東西大同小異，從閑魚的發(fā)布界面上來看就不難發(fā)現(xiàn)這一點，都是在基礎(chǔ)對象（如標(biāo)題、描述、圖片）之外添加一些業(yè)務(wù)相關(guān)的數(shù)據(jù)，如拍賣業(yè)務(wù)中指定拍賣的開拍時間等信息，免費送業(yè)務(wù)中設(shè)置兌換幣值，圖書業(yè)務(wù)上設(shè)置條形碼。即對一本圖書進(jìn)行拍賣當(dāng)然也是允許的，這就出現(xiàn)了拍賣業(yè)務(wù)和圖書業(yè)務(wù)疊加起來的復(fù)合型業(yè)務(wù)。

對于主干應(yīng)用開發(fā)人員來說，應(yīng)該提供單個接口以支持所有業(yè)務(wù)類型，這樣不用每次修改或者新增業(yè)務(wù)時都需要提供新接口。從穩(wěn)定性的角度考慮，這樣的要求很合理。既然是單個接口，那么DO的定義也應(yīng)該統(tǒng)一。以商品DO為例，有以下三種方式：

第一種是繼承型結(jié)構(gòu)，該結(jié)構(gòu)不適用于業(yè)務(wù)疊加的情況。另外主干需要知曉各個業(yè)務(wù)的DO，每次業(yè)務(wù)修改或新增，主干都需要做變動。

第二種是組合型結(jié)構(gòu)，適用于業(yè)務(wù)疊加的情況，但同上一種一樣，主干需要知曉各個業(yè)務(wù)的DO，每次業(yè)務(wù)修改或新增，主干也需要隨之變動。

第三種使用了Map類型類承載各個業(yè)務(wù)（biz）的定義類型。主干完全不知道、也不需要知道各個業(yè)務(wù)DO是如何組成的。這種方式具有最好的擴(kuò)展性（有點無邊界的擴(kuò)展），也分離了主干應(yīng)用和業(yè)務(wù)應(yīng)用，最接近主干和業(yè)務(wù)分離的期望。最終我們選擇了這一種。

使用第三種的對象模型，以新加一種業(yè)務(wù)為例，其開發(fā)流程是：

新業(yè)務(wù)服務(wù)端開發(fā)人員和客戶端開發(fā)人員約定各業(yè)務(wù)的DO，這些DO會存儲到bizMap字段。主干應(yīng)用開發(fā)人員不需要了解這些約定。

主干應(yīng)用新增一份新業(yè)務(wù)的配置，實際上是新業(yè)務(wù)的識別信息和路由信息。

新業(yè)務(wù)應(yīng)用實現(xiàn)主干擴(kuò)展點。

聯(lián)調(diào)、測試和上線。

業(yè)務(wù)應(yīng)用在擴(kuò)展點返回值中設(shè)置需要更新的數(shù)據(jù)，由主干應(yīng)用合并。業(yè)務(wù)應(yīng)用不應(yīng)該也不可以直接修改ItemDO，避免影響其他業(yè)務(wù)的處理邏輯。對于發(fā)布和編輯這種需要持久化存儲的邏輯來說，必須要強(qiáng)控各業(yè)務(wù)對ItemDO的修改，否則理論上來說，各業(yè)務(wù)都有可能將所有的關(guān)鍵字段修改得面目全非。前面提到的“配置型接口”中，就有這樣的配置——該業(yè)務(wù)是否可以修改屬性字段、該業(yè)務(wù)是否可以修改描述字段等配置。

總結(jié)

閑魚的商品發(fā)布和編輯功能基于SWAK框架經(jīng)過了兩次改造升級，第一次升級完成了平臺和業(yè)務(wù)之間的解耦合以及業(yè)務(wù)和業(yè)務(wù)之間的解耦合，第二次升級通過平臺和業(yè)務(wù)間使用RPC調(diào)用完成了系統(tǒng)和系統(tǒng)之間的解耦合。改造之后，能更有效地協(xié)同更多團(tuán)隊更快更穩(wěn)定地支撐各種業(yè)務(wù)。SWAK框架依然在繼續(xù)演進(jìn)，如部分?jǐn)U展點原則上可以通過并行處理或異步化處理來提升性能，但暫時還沒有提供支持。在這兩次改造中， 我們還在測試用例的采集、回放、監(jiān)控告警等方面也有很多積累，敬請期待后續(xù)的文章分享。

?

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的老代码多=过度耦合=if else？阿里巴巴工程师这样捋直老代码的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。