作者：京東物流 馮志文

前兩篇從服務(wù)粒度和服務(wù)內(nèi)的分層架構(gòu)角度探討，本文繼續(xù)從服務(wù)間代碼復(fù)用角度探討。

背景

在分布式架構(gòu)中，代碼復(fù)用是個(gè)難題。那么如何處理代碼功能共享的問(wèn)題呢？本文結(jié)合日常實(shí)踐中的案例，介紹幾種分布式架構(gòu)中管理代碼復(fù)用性的技術(shù)。包括代碼復(fù)制、共享代碼庫(kù)（jar包）、共享服務(wù)、邊車服務(wù)。對(duì)于每一種技術(shù)，列出優(yōu)缺點(diǎn)、適合場(chǎng)景權(quán)衡。

本文的觀點(diǎn)源自我在學(xué)習(xí)與實(shí)踐過(guò)程中的深思熟慮，尚處于不斷探索和驗(yàn)證的階段。希望能“拋磚引玉”，激發(fā)更多的討論與交流。讓我們共同進(jìn)步，在探討與實(shí)證中尋求真知。

一、代碼復(fù)制

共享的代碼被復(fù)制到每一個(gè)服務(wù)中。這種技術(shù)在服務(wù)早期比較流行。雖然現(xiàn)在代碼復(fù)制比較少見(jiàn)，但它還是解決跨多個(gè)分布式服務(wù)的代碼復(fù)用的有效技術(shù)。但這種缺點(diǎn)很明顯，因?yàn)槿绻诖a中發(fā)現(xiàn)錯(cuò)誤或需要對(duì)代碼進(jìn)行重構(gòu)改造，需要在包含該代碼庫(kù)的所有服務(wù)變更。

這種技術(shù)在一些場(chǎng)景比較有用，比如服務(wù)需要的高度靜態(tài)的一次性代碼。這種類型的代碼非常適合復(fù)制，因?yàn)樗庆o態(tài)的并且不包含任何錯(cuò)誤。比如很多通用的業(yè)務(wù)識(shí)別邏輯就用這種方式，在不同應(yīng)用代碼庫(kù)個(gè)應(yīng)用中編寫(xiě)。

案例1：根據(jù)sendpay標(biāo)位判斷XXX代碼

public static boolean isXXX(String sendpay) {
    boolean flag = false;
    String sendpay_x = Character.toString(sendpay.charAt(x));
    String sendpay_y = Character.toString(sendpay.charAt(y));
    if (("1".equals(sendpay_y) || "2".equals(sendpay_y) || "0".equals(sendpay_y))
            && "1".equals(sendpay_x)) {
        flag = true;
    }
    return flag;
}

案例2：新功能上線DUCC開(kāi)關(guān)

/**
 * XXX功能 控制開(kāi)關(guān)
 */
private boolean enableLargeApplianceSendMsg = false;

public boolean isEnableLargeApplianceSendMsg() {
    return enableLargeApplianceSendMsg;
}

public void setEnableLargeApplianceSendMsg(boolean enableLargeApplianceSendMsg) {
    this.enableLargeApplianceSendMsg = enableLargeApplianceSendMsg;
    log.info("enableLargeApplianceSendMsg: {}", enableLargeApplianceSendMsg);
}

二、共享代碼庫(kù)

共享代碼庫(kù)是共享技術(shù)的常用技術(shù)之一。共享代碼庫(kù)是一個(gè)外部組件（比如JAVA的jar包），共享代碼庫(kù)比代碼復(fù)用更高一層級(jí)。基于功能劃分，提供較為獨(dú)立的功能。比如目前采用了根據(jù)基礎(chǔ)能力和業(yè)務(wù)模塊抽象時(shí)效內(nèi)核JAR包方式，詳見(jiàn)下圖中時(shí)效計(jì)算內(nèi)核jar包。為什么要采用這種方式呢？后文會(huì)說(shuō)明權(quán)衡點(diǎn)。

jar包引入看起來(lái)簡(jiǎn)單，在編譯時(shí)被整合和共享。但其實(shí)也有利弊取舍和復(fù)雜性。其中最重要的是代碼庫(kù)的共享庫(kù)粒度和版本控制。

1、依賴管理和變更控制

如果粗粒度共享庫(kù)中任何類文件發(fā)生變更，都需要每個(gè)服務(wù)變更、測(cè)試、部署。這極大的增加了共享庫(kù)更改的整體測(cè)試范圍。粗粒度共享庫(kù)的變更會(huì)影響多個(gè)服務(wù)，但會(huì)減少依賴關(guān)系。

將共享庫(kù)分解為更小的基于功能的共享庫(kù)（比如拆分為 ABCDE等），這樣有利于變更控制和整體可維護(hù)性。但這會(huì)造成依賴管理的混亂。如下圖，業(yè)務(wù)根據(jù)不同業(yè)務(wù)域拆分不同 jar包，導(dǎo)致jar包依賴復(fù)雜。

共享庫(kù)對(duì)少量的應(yīng)用可能并不重要，但隨著服務(wù)數(shù)量增加，變更管理和依賴管理相關(guān)的問(wèn)題也會(huì)增加。

建議：避免大的粗粒度的共享庫(kù)，盡可能爭(zhēng)取更小的、功能分區(qū)的庫(kù)，有利于變更控制而不是依賴管理。

2、版本控制策略

對(duì)于共享庫(kù)來(lái)說(shuō)，版本控制需要向后兼容（后退、考慮舊版本兼容），同時(shí)也需要高度敏捷性。比如a.jar包變更升級(jí)版本為1.1，只需要1個(gè)服務(wù)上線，其他N個(gè)服務(wù)不會(huì)有任何影響。這雖然看起來(lái)版本控制很簡(jiǎn)單，但同樣存在權(quán)衡和隱藏的復(fù)雜性。比如下次N個(gè)應(yīng)用也需要上線。并且依賴管理混亂（服務(wù)ABC依賴a.jar版本1.1，服務(wù)DEF依賴a.jar版本1.0），復(fù)雜性不僅體現(xiàn)在版本變更的通知，也存在舊版本棄用的情況。

為什么時(shí)效內(nèi)核需要采用jar包給下單前下單后各應(yīng)用這種方式呢？結(jié)合上面的優(yōu)缺點(diǎn)，主要權(quán)衡核心點(diǎn)如下

1.應(yīng)用場(chǎng)景相關(guān)：XX是下單前商詳結(jié)算等高并發(fā)場(chǎng)景，下單后訂單生產(chǎn)節(jié)奏控制。

2.降本：預(yù)估降低了服務(wù)器硬件成本XXX核左右

3.性能：通過(guò)JAR包的依賴的方式來(lái)較少RPC調(diào)用，提升了接口性能TP99，尤其是用戶在商詳、結(jié)算提單頁(yè)面

4.更新頻率低：由于時(shí)效內(nèi)核更新頻率較低，一年1-2次左右的改動(dòng)點(diǎn)

三、共享服務(wù)

共享服務(wù)技術(shù)通過(guò)將共享功能服務(wù)化來(lái)避免重復(fù)使用。對(duì)應(yīng)上面改造，把時(shí)效內(nèi)核jar包進(jìn)行服務(wù)化時(shí)效內(nèi)核應(yīng)用，具體架構(gòu)圖如下：

共享服務(wù)是分布式中常見(jiàn)的共享服務(wù)的方法，但也需要權(quán)衡，比如變更風(fēng)險(xiǎn)、性能、可伸縮性、容錯(cuò)性。

1、變更風(fēng)險(xiǎn)

使用共享服務(wù)變更共享代碼是一把雙刃劍。 只需要共享服務(wù)部署上線，但共享服務(wù)的變更可能在運(yùn)行時(shí)破壞其他服務(wù)。那必須牽扯版本控制、共享代碼庫(kù)是在編譯的時(shí)候綁定版本控制，降低更改風(fēng)險(xiǎn)。但如何在共享服務(wù)中版本化變更呢？使用API版本控制。但使用API版本控制有個(gè)問(wèn)題，很多服務(wù)協(xié)議不是restful api，而是rpc或者消息mq，這樣會(huì)使得版本控制復(fù)雜。

共享服務(wù)雖然版本控制可以幫助降低這風(fēng)險(xiǎn)，但它的應(yīng)用和管理更復(fù)雜。

2、性能

共享功能服務(wù)必須進(jìn)行服務(wù)間調(diào)用，存在網(wǎng)絡(luò)延遲開(kāi)銷而影響性能。

3、可伸縮性

共享服務(wù)一定要隨著調(diào)用服務(wù)的規(guī)模進(jìn)行伸縮

四、邊車和ServiceMesh服務(wù)網(wǎng)格

"邊車服務(wù)"（Sidecar Pattern）這個(gè)術(shù)語(yǔ)來(lái)源于摩托車的邊車（sidecar），這是一種附加在摩托車旁邊的一輪車廂，可以搭載乘客或貨物，但它不是摩托車本身的核心部分。

邊車服務(wù)（Sidecar Pattern）在微服務(wù)架構(gòu)中用于將一些與業(yè)務(wù)邏輯不直接相關(guān)的控制面（如注冊(cè)發(fā)現(xiàn)、熔斷限流、pfinder鏈路追蹤監(jiān)控、DUCC配置管理等）從應(yīng)用程序中分離出來(lái)。這樣，應(yīng)用程序可以專注于業(yè)務(wù)邏輯，而邊車服務(wù)則負(fù)責(zé)處理其他方面的問(wèn)題。

邊車服務(wù)的關(guān)鍵特點(diǎn)包括：

?復(fù)用性：由于邊車服務(wù)可以被多個(gè)主應(yīng)用共享，因此一些通用的功能（如服務(wù)發(fā)現(xiàn)、斷路器、限流器等）可以在不同的服務(wù)之間重用，減少了代碼的冗余。

?隔離性：邊車為主應(yīng)用提供了一個(gè)清晰的隔離層，使得主應(yīng)用可以專注于業(yè)務(wù)邏輯，而不必關(guān)心其他非功能性的問(wèn)題。 邊車服務(wù)是主應(yīng)用程序的附屬，為主應(yīng)用提供支持和增強(qiáng)功能。

?易于維護(hù)：邊車的引入使得對(duì)于共享功能的更新和維護(hù)變得更加簡(jiǎn)單，因?yàn)檫@些功能被集中到單獨(dú)的服務(wù)中，不需要在每個(gè)應(yīng)用中單獨(dú)進(jìn)行修改。

?透明性：對(duì)于主應(yīng)用程序來(lái)說(shuō)，邊車的存在應(yīng)該是透明的，主應(yīng)用不需要知道邊車的具體實(shí)現(xiàn)細(xì)節(jié)。

?獨(dú)立性：邊車服務(wù)可以獨(dú)立于主應(yīng)用程序更新和維護(hù)，無(wú)需修改主應(yīng)用程序的代碼。

通過(guò)使用邊車模式，開(kāi)發(fā)人員可以將關(guān)注點(diǎn)分離，使主應(yīng)用程序更加簡(jiǎn)潔，只關(guān)注業(yè)務(wù)邏輯的實(shí)現(xiàn)，而將服務(wù)治理等通用性問(wèn)題交給邊車服務(wù)處理。

如果每個(gè)服務(wù)都包含邊車組件，那么它就形成了服務(wù)網(wǎng)格。每個(gè)服務(wù)右邊的盒子都互相連接，形成一個(gè)“網(wǎng)格”

服務(wù)架構(gòu)是圍繞各自領(lǐng)域組織的，但服務(wù)治理運(yùn)維耦合需要橫切這些領(lǐng)域

五、總結(jié)

技術(shù)最終是要服務(wù)于業(yè)務(wù)，每種技術(shù)選擇沒(méi)有絕對(duì)的好壞，各有優(yōu)缺點(diǎn)，適合場(chǎng)景。具體應(yīng)該用哪一種，需要根據(jù)成本、團(tuán)隊(duì)技能、系統(tǒng)的未來(lái)發(fā)展綜合考慮，目前團(tuán)隊(duì)系統(tǒng)中上面幾種情況都存在。正如軟件架構(gòu)定律：軟件架構(gòu)中的一切都是在權(quán)衡，架構(gòu)背后的原因比方法更重要。

審核編輯 黃宇