微服務架構與現有系統並存的主要技術

在現實場景中，從零打造一個微服務架構機會很少，更多的是從一個現有系統出發逐步轉型到微服務架構。對於那些已經處於架構腐化邊緣的現有系統而言，往往正在尋找一種可以替代的架構風格，微服務架構可以是一種潛在的選擇。

與構建一個新系統相比，從現有系統向微服務架構轉型具有一些顯著的特點：

• 業務模型

對於現有系統而言，我們已經具備明確的業務模型。尤其是那些尋找變革的架構，對於業務模型的理解通常很深刻，因爲已經經歷過了業務建模的陣痛期。這點對微服務架構非常重要，也是轉型得以實現的基礎。

• 領域模型

業務模型不等於領域模型。從領域建模的角度出發，現有系統中存在的業務邊界很可能並不滿足界限上下文的定義，也沒有使用實體、聚合等手段在某個界限上下文內對業務對象進行建模。在這種場景下，向微服務架構轉型將面臨挑戰，因爲系統中基於領域的設計方法需要進行調整。

• 遺留代碼

現有系統中存在大量代碼，通常這些代碼的質量都不高，也普遍存在缺少單元測試、部署複雜等典型問題。微服務架構需要解決這些問題，而解決這些問題的有效方法是引入變化。

正因爲現有系統中沒有明確的領域模型、也存在很多問題代碼，直接通過代碼拆分的手段將一個完整的系統分割成多個微服務並不現實。更爲現實的做法是通過微服務架構來補充和增強現有系統。在本文中，我們將介紹幾種在微服務架構與現有系統並存的情況下優化系統架構的方法，包括應用EAI、應用客戶端集成、應用數據複製以及分離服務。

（1）應用EAI

EAI（Enterprise ApplicationIntegration，企業應用集成）是將基於不同平臺、使用不同方案建立的異構應用進行集成的一種方法和技術。同時，它也表現爲一系列可用於系統集成的架構設計模式。

EAI中的核心組件可以分爲兩大類，一類是消息路由（Message Routing），一類是消息轉換（Message Transformation）。

• 消息路由

消息路由用於將消息傳遞到某個微服務，我們可以基於消息路由把某些業務請求轉發到新的微服務，而不是交由原有系統處理。通過這種方式，我們在開始實施微服務架構的過程中不需要完成整個邏輯，而只需提供部分組件的實現即可。

消息路由需要考慮一次處理單條/多條消息、路由結果面向一個/多個目標、路由是否有狀態等問題。圍繞上述三個問題所得出的答案，我們加以排列組合可以得到多種路由器的表現形式，一般可以分爲有狀態路由和無狀態路由。其中有狀態的路由器指的就是需要根據消息傳遞的上下文確定路由結果，通常涉及多個消息，具有較高的複雜性。無狀態路由中最簡單的就是內容路由器（Content-based Router），即通過消息的內容決定路由結果。這裏的消息內容包括輸入消息的消息頭屬性值、消息體類型以及各種針對消息體內容的自定義的業務規則，通過內容路由器可以產生一對一的路由效果。顯然，通過內容路由器，我們可以實現發送消息到某個特定微服務的效果。

•  消息轉換

消息轉換器（Transformer）解決服務與服務之間數據如何在異構系統之間進行適配的問題。現有系統與微服務之間經常需要異構系統之間的交互和集成，通過轉換器可以消除異構系統之間由於數據格式所導致的依賴。最基本的轉換思路就是通過一種自定義轉換機制進行兩種數據結構之間的映射，但有些場景下我們也需要實現基本數據結構轉換，並對輸入的數據結構進行內容的擴充和過濾。

內容擴充器（Content Enricher）就是往消息中擴充新的數據，擴充的數據來源可以來自計算、外部環境和第三方其他系統，擴充的對象可以是消息的消息頭也可以是消息體，所以內容擴充器一般可以分成消息頭擴充器（Header Enricher）和消息體擴充器（Payload Enricher）。內容過濾器（Content Filter）是內容擴充器的對稱操作，內容過濾的目的是去除消息中的某一部分而不是在消息傳遞過程中過濾掉該消息。

下圖展示了一個簡單場景，消息路由器接收請求並把消息轉發到某個微服務或現有系統。在這個場景中，我們可能已經使用《微服務拆分的維度和策略》中介紹的絞殺者模式對系統中的部分功能進行了微服務改造，同時保留了部分原有功能。當業務請求到達系統，可以通過業務請求的屬性進行服務路由，分別轉向已改造完成的微服務以及尚待改造的現有系統

（2）應用客戶端集成

相比通過各種企業應用集成模式來實現微服務架構與現有系統之間的協作，客戶端集成的方式簡單而有效。我們在《微服務架構中服務集成的主要技術》節中已經深入討論過客戶端集成的各項技術，以BackEnd For FrontEnd服務器爲例，我們可以通過該服務器做一層轉發操作，將系統的一部分請求轉發到微服務，而另一部請求則仍然流向現有系統。下圖展示了這種方式的基本結構。

客戶端集成雖然簡單，但如何合理劃分客戶端入口是一項挑戰。如果現有系統的各個客戶端入口規劃比較合理，能夠簡單通過入口劃分就能界定業務邊界，客戶端集成是一項很好的請求轉發機制。當我們把部分業務通過微服務進行實現之後，新的請求就可以完全脫離現有系統轉而由新的微服務處理。但在很多現有系統中，客戶端入口並不是非常獨立，可以針對那些邊界比較清楚的入口採用客戶端集成方式，其餘入口則結合前面的EAI方式進行綜合處理。

（3） 應用數據分離

隨着引入微服務之後部分業務功能的解耦，系統中已經存在一些微服務能夠獨立提供業務功能。這個時候我們就可以逐漸考慮開展數據分離工作。通過從現有系統中剝離部分業務相關的數據，儘量構建獨立而隔離的微服務業務系統，這同樣也是從數據層面對現有系統進行“絞殺”的一種有效方式。數據分離的效果如下圖所示。

數據分離對於一部分業務是可以直接應用的，但對業務邏輯較爲複雜的現有系統而言，數據分離需要花費很大代價所以在向微服務架構轉型的過渡階段，數據複製也是需要採用的一種策略。在上圖中，我們可以在現有系統和微服務之間採用離線批量策略開展數據同步，如果數據同步實時性要求較高，那就只能採用服務接口的方式集成。關於數據複製，我們也在《微服務架構中服務集成的主要技術》中做了詳細討論。

（4） 應用服務分離

這裏服務分離的含義在於我們是否要啓動一個新的服務還是繼續沿用已經存在的老服務。關於這個問題有一些原則可以參考。

• 數據和流程

首先比較明確的一點思路還是來自數據，當我們引入新的數據模型以及相應的數據處理流程時，一般都需要啓用一個新的服務。

• 同步和異步

當系統中同時存在同步和異步處理流程，並且需要把這兩種處理方式混合起來時，我們需要考慮是否應該引入新的服務以簡化這種處理流程。

• 服務切面

在一個現存服務中，當我們發現其具有不同的切面（Aspect）時，例如某些通用機制不斷在業務代碼中重複出現或者說某個功能有多個不同的實現場景時，我們可以從切面的角度出發分析是否需要將這些切面抽取出來形成新服務。

更多內容可以關注我的公衆號：程序員向架構師轉型。