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

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

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

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

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

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

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

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

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

• 代碼邏輯清晰，可變和不可變一目了然。
• 代碼復(fù)用度變高。
• 可變邏輯按照標(biāo)簽進(jìn)行隔離，單個(gè)標(biāo)簽的實(shí)現(xiàn)不會(huì)影響到其他標(biāo)簽的實(shí)現(xiàn)，降低開發(fā)和測(cè)試成本。無論是按照“類型”分還是按照類目分，對(duì)應(yīng)的開發(fā)和測(cè)試同學(xué)只需要關(guān)注對(duì)應(yīng)的邏輯即可。

新接手的開發(fā)人員能夠快速理解，輕松上手。

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

以租房為例——租房業(yè)務(wù)的同學(xué)需要在item應(yīng)用中維護(hù)一套租房發(fā)布編輯相關(guān)的邏輯(如校驗(yàn)地小區(qū)數(shù)據(jù)、地鐵數(shù)據(jù)真實(shí)性等);租房業(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àn)是非常糟糕的，有極大的可能性接手一個(gè)簡(jiǎn)單業(yè)務(wù)就需要修改和發(fā)布四五個(gè)應(yīng)用。

另一方面，從主干開發(fā)人員的角度來說，其應(yīng)用不僅僅由自己或自己的小團(tuán)隊(duì)來維護(hù)，還有很多業(yè)務(wù)開發(fā)人員也在修改和發(fā)布此應(yīng)用，且頻率會(huì)遠(yuǎn)遠(yuǎn)超過主干開發(fā)任務(wù)的發(fā)布和部署頻次(否則就是主干擴(kuò)展點(diǎn)邏輯抽取得不好了)。這不利于整個(gè)應(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ǎn)而言之就是人員組織結(jié)構(gòu)和系統(tǒng)結(jié)構(gòu)之間的一致性。而完成系統(tǒng)之間的解耦合又恰恰是符合康威定律的。這一輪的改造，我們稱之為“業(yè)務(wù)服務(wù)化”。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ***種是繼承型結(jié)構(gòu)，該結(jié)構(gòu)不適用于業(yè)務(wù)疊加的情況。另外主干需要知曉各個(gè)業(yè)務(wù)的DO，每次業(yè)務(wù)修改或新增，主干都需要做變動(dòng)。
• 第二種是組合型結(jié)構(gòu)，適用于業(yè)務(wù)疊加的情況，但同上一種一樣，主干需要知曉各個(gè)業(yè)務(wù)的DO，每次業(yè)務(wù)修改或新增，主干也需要隨之變動(dòng)。
• 第三種使用了Map類型類承載各個(gè)業(yè)務(wù)(biz)的定義類型。主干完全不知道、也不需要知道各個(gè)業(yè)務(wù)DO是如何組成的。這種方式具有***的擴(kuò)展性(有點(diǎn)無邊界的擴(kuò)展)，也分離了主干應(yīng)用和業(yè)務(wù)應(yīng)用，最接近主干和業(yè)務(wù)分離的期望。最終我們選擇了這一種。

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

1. 新業(yè)務(wù)服務(wù)端開發(fā)人員和客戶端開發(fā)人員約定各業(yè)務(wù)的DO，這些DO會(huì)存儲(chǔ)到bizMap字段。主干應(yīng)用開發(fā)人員不需要了解這些約定。
2. 主干應(yīng)用新增一份新業(yè)務(wù)的配置，實(shí)際上是新業(yè)務(wù)的識(shí)別信息和路由信息。
3. 新業(yè)務(wù)應(yīng)用實(shí)現(xiàn)主干擴(kuò)展點(diǎn)。
4. 聯(lián)調(diào)、測(cè)試和上線。

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

總結(jié)

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