在微服務大行其到的當下，究竟哪些代碼應該放在具體的某一個微服務中一直是一個值得探討的話題。本文不對這個主題展開討論，而是關注於助於調整現有微服務架構中代碼結構的相關技術，包括共享庫、共享服務、代碼轉移、代碼冗餘、提取新服務和重寫服務。這些對於如何重構現有的服務體系有一定的參考意義。
1. 共享庫
如果兩個服務想要共用一些代碼，那麼這些代碼就可以被提取並放到一個共享庫中。共享庫體現的是一種代碼複用思想，公共代碼從某一個服務移到共享庫就可以被其他服務所使用。共享庫技術的示意圖見下圖。
共享庫實施過程中的主要挑戰在於如何判斷某些代碼應該移到共享庫而不是放在本地服務中。微服務架構實際上並不是非常關注代碼複用，因爲代碼複用會導致服務與服務之間產生新的依賴。微服務架構崇尚服務獨立性，過多的把代碼提取到共享庫可能會引來一些不必要的問題。而且，共享庫也會對服務部署結構產生一定影響。
當然，共享庫的優勢也很明顯。本來存在bug或不合理設計的代碼通過在共享庫中的一次修正就能完成所有場景下的代碼升級。通過合理管理共享庫的版本可以降低代碼錯誤率。
2. 共享服務
共享服務的思路與共享庫類似，只不過在共享服務中，被提取的代碼並不是放到一個獨立的公共庫中，而是直接轉移給了另一個服務（見下圖）。與共享庫相比，共享服務的優勢在於不用產生新的依賴關係，因爲服務與服務之間的交互方式並沒有任何改變，而服務內部的任何調整並不會產生架構上的影響。
共享服務是保持服務大小合理性的一種手段，藉助共享服務機制，我們可以對規模比較大的服務進行“瘦身”。但是共享服務在不增加服務依賴關係的同時卻會轉移服務與服務之間的交互需求。當我們把部分代碼從一個服務轉移到另一個服務時，本來只需要依賴一個服務的場景，就可能變成需要依賴幾個服務。
3. 代碼轉移
從一個微服務中抽取一部分代碼放到另一個微服務中的做法稱之爲代碼轉移。通常，我們進行代碼轉移的主要目的是爲了降低兩個微服務之間的耦合，提高單個服務的內聚度。當一個微服務需要依賴另一個微服務完成某個功能時，我們認爲兩者具有一定耦合度，當把兩者之間的交互部分代碼進行轉移之後，這種耦合度就能得到緩解。代碼轉移的示意圖如下圖所示。
代碼轉移與前面提到的共享庫有點類似，但被轉移的代碼往往到不了高度複用的程度，所以沒有必要提取爲共享組件。另一方面，共享庫的提取具有技術約束性，即使用共享庫的幾個微服務一般都需要採用同一種技術實現體系。而代碼轉移則可以更加靈活，我們完全可以採用另一種技術實現方式重寫這些需要轉移的代碼。微服務一般規模都不大，而需要轉移的代碼通常只是其中的一小部分，所以基於代碼重寫的實現方案成本可控。
4. 代碼冗餘
與其把代碼轉移到另一個微服務，有時候我們也會選擇代碼冗餘的方式降低服務與服務之間的耦合度。在主流的方法論中，普遍認爲代碼冗餘是一項反模式，因爲當代碼被冗餘在兩個地方時，一旦有問題就需要同時修正這兩個地方。這是一個架構腐化的危險信號，所以我們一般都儘量避免重複代碼的產生。但在微服務架構中，代碼冗餘有一個非常明顯的優勢，即兩個微服務之間能夠保證高度的獨立性，從而實現微服務架構所提倡的獨立部署。
針對獨立部署，我們有時候不禁要問一個問題：現實中真的存在一個完成獨立的系統或組件嗎？很多時候，我們花了很大代價提取代碼到共享庫或共享框架，會發現這些共享庫或共享框架用起來也有很多問題。這時候，冗餘部分代碼可能是一個更好的選擇。代碼冗餘的方式見下圖所示。
5. 提取新服務
當然，我們也可以通過提取部分代碼的方式創建一個新服務（見下圖）。提取新服務具有與共享服務同樣的優點和缺點，但是兩者具有不同的初衷。當一個服務的規模逐漸增大，提取新服務的目的在於通過減小服務的規模從而降低服務的維護成本，或者把該服務所承載的一部分職責轉移到另一個團隊。這時候，這個新服務就不會像共享服務那樣被多個服務所共同依賴。
舉個例子，假如在移動醫療系統中，註冊流程可能非常複雜，因爲需要依賴就診卡等醫療媒介，也需要區分不同的用戶羣體，因此我們可以把註冊服務拆分成幾個服務，分別處理不同的用戶註冊場景。這種拆分在降低服務複雜度的同時，也會從組織架構上推動團隊結構的優化和業務的聚焦。
6.重寫服務
最後，如果我們認爲一個微服務的結構已經不再合適，我們就只能重寫它。相較其他的架構設計方法，微服務架構中的重寫並不是一件非常困難的事情，因爲微服務的規模較小，同時具備明確的服務契約。
我們有時候會鼓勵重寫服務，一方面可能來自於技術體系的發展和演進，使用新技術重寫一個老服務會帶來更好的發展前景。另一個更重要的方面，重寫服務驅使我們再次審視服務背後的領域模型，從而爲該領域模型提供一種嶄新的、更好的實現。
更多內容可以關注我的公衆號：程序員向架構師轉型。
