作者：京東物流 馮志文

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

背景

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

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

一、代碼復制

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

這種技術(shù)在一些場景比較有用，比如服務(wù)需要的高度靜態(tài)的一次性代碼。這種類型的代碼非常適合復制，因為它是靜態(tài)的并且不包含任何錯誤。比如很多通用的業(yè)務(wù)識別邏輯就用這種方式，在不同應用代碼庫個應用中編寫。

案例1：根據(jù)sendpay標位判斷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開關(guān)

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

public boolean isEnableLargeApplianceSendMsg() {
    return enableLargeApplianceSendMsg;
}

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

二、共享代碼庫

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

jar包引入看起來簡單，在編譯時被整合和共享。但其實也有利弊取舍和復雜性。其中最重要的是代碼庫的共享庫粒度和版本控制。

1、依賴管理和變更控制

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

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

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

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

2、版本控制策略

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

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

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

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

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

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

三、共享服務(wù)

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

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

1、變更風險

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

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

2、性能

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

3、可伸縮性

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

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

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

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

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

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

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

?易于維護：邊車的引入使得對于共享功能的更新和維護變得更加簡單，因為這些功能被集中到單獨的服務(wù)中，不需要在每個應用中單獨進行修改。

?透明性：對于主應用程序來說，邊車的存在應該是透明的，主應用不需要知道邊車的具體實現(xiàn)細節(jié)。

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

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

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

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

五、總結(jié)

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

審核編輯 黃宇