作者：京東物流 馮志文

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

背景

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

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

一、代碼復制

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

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

案例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開關

/**
 * XXX功能 控制開關
 */
private boolean enableLargeApplianceSendMsg = false;

public boolean isEnableLargeApplianceSendMsg() {
    return enableLargeApplianceSendMsg;
}

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

二、共享代碼庫

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

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

1、依賴管理和變更控制

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

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

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

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

2、版本控制策略

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

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

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

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

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

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

三、共享服務

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

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

1、變更風險

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

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

2、性能

共享功能服務必須進行服務間調用，存在網絡延遲開銷而影響性能。

3、可伸縮性

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

四、邊車和ServiceMesh服務網格

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

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

邊車服務的關鍵特點包括：

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

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

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

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

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

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

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

服務架構是圍繞各自領域組織的，但服務治理運維耦合需要橫切這些領域

五、總結

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

審核編輯 黃宇