企業應用架構演化探討：從微服務到Service Mesh

作者：李寧

來源：博雲技術社群 / 博雲研究院

當下微服務的實踐方案中，Spring Cloud，Dubbo作為主流的落地方案，在企業應用架構中發揮越來越重要的作用。本文探討企業應用架構如何從微服務架構向Service Mesh架構演化，並形成落地方案。需要特別說明：本文討論的架構目前適用於普通的企業級應用，其他行業（例如網際網路）需要進一步擴充套件。

在討論之前，我們需要明確一個事實： 企業應用一定是圍繞業務進行的。無論採用什麼的架構落地，都是為了更好的為應用業務進行服務。從企業應用的特性考慮，主要包括：穩定性，安全性，擴充套件性，容錯性。

圍繞著企業應用的這些特點，我們來看一個典型的微服務企業架構模型，如圖所示：

• 服務接入層：企業暴露到外部訪問的入口，一般透過防火牆等。
• 閘道器層：服務閘道器是介於客戶端和服務端的中間層，所有的外部請求會先經過服務閘道器，為企業應用提供統一的訪問控制入口。服務閘道器是微服務架構下的服務拆分，聚合，路由，認證以及流控綜合體現。
• 支撐服務層：為企業應用提供執行所需的支撐環境，包括註冊發現，集中配置，容錯限流，認證授權，日誌聚合，監測告警，訊息服務等
• 業務服務層：業務服務是企業應用的核心所在，為企業領域應用的具體實現，一般進一步拆分為基礎服務（基礎功能）和聚合服務（綜合場景）。
• 平臺服務層：為企業應用提供執行所需的軟體資源，包括應用伺服器，應用釋出管理，應用映象包管理，服務治理。
• 基礎設施層：為企業應用提供執行所需的硬體資源，包括計算資源，網路資源，儲存資源，基本的安全策略控制等。

從這個典型的服務架構體系中，能夠清晰的表明層級架構以及各層涵蓋的職責說明。我們暫不考慮基礎設施層和平臺服務兩層，重點關注 閘道器服務，業務服務，支撐服務，突出其中的一些 基礎支撐功能元件，這也是我們本篇探討的重點內容。如下圖所示：

根據圖中紅色標識，我們會發現這樣一個事實： 在微服務架構下，無論是哪種落地實現方式，都集中在閘道器服務、支撐服務兩個層面。無論是Spring Cloud“套裝元件”，Dubbo“套件”還是其他開源元件，都為支撐服務的實現提供了數量眾多的選擇。功能完整、選擇性多這是業內喜聞樂見的事情，但是也無形中增加了開發，測試，運維人員的壓力。大家需要掌握越來越多的“使用工具”以更“方便”、“快捷”地應對業務服務。有時候，可能為了實現單一功能，而必須引入一堆元件，這時候我們希望能夠 有一個完整的平臺來為應用業務提供一體化的支撐服務，而不是一系列“套裝元件”與業務的整合。

那麼如何基於一個平臺來實現這些企業應用需要的能力呢？經過一定階段的技術調研，我們認為Service Mesh能夠幫助我們初步達到這個目標。

我們都知道Service Mesh以解決“服務通訊”的問題作為其設計初衷，聚焦基礎設施“網路層”，並以此做技術基礎，解決業務通訊場景面臨的問題。那麼 如何把它應用在企業應用架構中來取代“微服務套裝元件”呢？那接下來讓我們針對閘道器服務，業務服務，支撐服務分別來看一下，如何從原來的微服務“套裝元件”中抽離出來，實現Service Mesh方向的轉變。

閘道器服務

前面提到過：服務閘道器是介於客戶端和服務端的中間層。從功能上不難理解，對內遮蔽內部細節，對外提供統一服務介面。從場景聚焦角度考慮，閘道器根據不同的場景承載不同的職責，包括認證，授權，路由，流控，負載等。（之前我們也聊過閘道器元件的對比及具體實現，感興趣的同學可點選 微服務五種開源API閘道器實現元件對比 ）。

由此可見，服務閘道器是企業應用架構下一些列功能的綜合體現。那麼在Service Mesh情況下如何處理閘道器服務呢？在展開之前首先需要說明一個前提： 目前為止Service Mesh跟真正企業閘道器相比還存在一定的不足之處，例如“協議轉化”，“安全策略”，“效能要求”等方面。在這裡我們也是探討這樣的可能性。下面以Istio為例，我們來看一下，如何提供閘道器層面的服務。

Istio在閘道器層面提供兩種型別的閘道器服務：Ingress Gateway，Egress。

Ingress Gateway

Ingress Gateway用於接收傳入的HTTP/TCP連線，它配置暴露埠，協議供外部統一接入，但是自身不提供任何的路由配置，而是完全依賴 Istio 的控制規則來進行流量路由。從而與內部服務請求統一到同一個控制層面上。

Egress

在企業應用與外部應用之間，有時候為了業務需要會出現內部服務呼叫外部服務的情況，此時一般會從企業內部接入第三方閘道器來獲取服務資料。在 Isito 中你同樣可以基於Egress來達到目的。Isito中提供兩種方式：一種基於ServiceEntry + VirtualService的配置，實現第三方服務的訪問，一種擴大sidecar的訪問地址列表。（參考文件： ）。

基於上述兩種場景，我們可以看出， 在 Service Mesh 的體系下，閘道器層面變成一個可以動態生成和銷燬的元件，能夠透過控制層面實現統一規則管理，並且實時生效。

基於Service Mesh的閘道器服務如下圖所示：

從實現原理上分析，傳統的閘道器實現基於 Servlet 的 filter 的模式，實現服務請求轉移過程中的層層過濾和處理。區別在於採用同步或者非同步處理機制，用來解決閘道器的效能瓶頸。而Service Mesh的閘道器完全是基於網路代理的請求轉發與控制，本質上作用在服務的 Iptables 上，透過對 Iptables 的規則控制達到同樣的效果。

業務服務

業務是企業應用的“重中之重”，無論哪種企業架構，最終都是為了更好地為業務提供服務，那麼我們如何在Service Mesh的體系下，重構業務服務呢？我們以兩個簡化的服務呼叫來說明整個架構的轉變過程。

假如要實現服務A，服務B的相互呼叫，最原始的方式是服務A基於協議層直接呼叫服務B（這裡暫時忽略高可用，多副本，負載均衡的方式），如圖所示：

由圖可見，服務A基於某種協議完成對服務B的請求，相對比較簡單。但是我們知道這樣雖然能夠快速完成業務關聯，但是無法確保業務正常穩定的執行，因此我們需要引入更多的服務來保證業務的穩定，可靠，可控。此時我們最容易想到的是引入微服務的支撐元件來達到目標。

以Spring Cloud方案為例，我們來說明當前微服務架構的實現方式。為了滿足企業應用對服務A，服務B的管理控制，需要額外引入“註冊中心”，“閘道器”，“配置中心”，“服務監測”，“事件訊息”，“鏈路跟蹤”，“日誌服務”等眾多與直接業務無關的“旁路保障服務”，簡化一下，如下圖所示：

從圖中可以看出，每個服務都引入了大量與業務無關的“保障服務”，這些“旁路保障服務”消耗的資源，與比業務本身消耗的資源成“倍數關係”。隨著服務數目的增多，業務服務本身佔用的資源比會越來越少，此時開發人員會把大量的精力花費在維護這些“旁路保障服務”上，而忽略業務本身。這對於企業應用而言，有些本末倒置的意思。

我們再來看一下 Service Mesh 體系下，我們如何解決上述問題。Service Mesh為了解決企業應用的“通訊問題”重點做了四個方面的工作，以 Istio 為代表，提供了包括流量管理，安全配置，策略控制以及外圍元件支撐的遙測功能（需要的朋友，可以參考官方文件： ），在Service Mesh的架構下，服務A呼叫服務B的架構會變成下圖所示：

透過上圖我們可以發現，與Spring Cloud的實現方式相比，似乎簡單了很多，我們不再需要在業務服務中引入眾多的“旁路保障服務”，而是保障了業務服務本身的簡單化。那麼Service Mesh是如何處理的呢？

第一，引入了Sidecar代理模型，作為服務流量控制的入口和出口，保證能夠對網路層面資料做實時監控和調整；
第二，控制器根據具體業務情況，分發控制狀態和控制指令，Sidecar獲取控制資訊後，及時更新快取資訊，保證策略有效性。
第三，Sidecar由於能夠攔截所有請求的流量資訊，定期把收集的資料向控制層進行上報，從而完成服務狀態和應用鏈路的監測。
第四，所有的這些都是在應用部署階段完成，在開發層面不需要花費大量的精力。

基於以上四點我們可以發現，Service Mesh 僅僅透過方式轉變就達到了同樣的效果，還極大的解放了開發人員。

透過業務服務呼叫方式的實現轉變，我們發現這樣一個事實：Service Mesh在保證業務簡化有效的同時，進一步遮蔽了多種開發語言帶來的障礙。它完全基於網路層面和協議層面作為出發點，達到“以不變應萬變”的效果。

支撐服務

從企業業務的價值角度考慮，其實支撐服務更多屬於“資源消耗”品，雖然如此，它卻是企業應用架構不可或缺的一部分。從 單一的業務呼叫--->微服務體系業務呼叫--->Service Mesh 體系業務呼叫的轉變方式中，可以看出支撐服務處於一個層級不斷下降的過程。而依賴於ServiceMesh的定位， 最終一些支撐服務會作為基礎設施的形態呈現出來，這也是未來發展的趨勢所在。支撐服務在企業架構的形態轉變如圖所示：

• 傳統架構：傳統架構下，支撐服務，業務服務基本上沒有明確的邊界區分，實現方式上都透過程式碼雜糅在一起。
• 微服務架構：微服務架構下，支撐服務，業務服務能夠初步分離，但是需要保證程式碼框架的統一性和依賴性，跨語言受限比較嚴重。
• Service Mesh架構：Service Mesh架構下，支撐服務，業務服務能夠徹底分離，不收語言限制，唯一需要考慮的是不同協議的支援情況。

透過支撐服務的轉變形態可以看出， 支撐服務與業務服務分離是必然趨勢，而最終的受限取決於多元化的網路協議的處理分析能力。當然我們需要明確一個事實：就Service Mesh目前的發展趨勢和定位而言，並不能夠完全取代所有的支撐服務，例如事件訊息，配置管理等。我們更多期望它能夠幫助解決應用服務在網路層面需要面對的場景和問題。這也是它發揮價值的地方所在。

透過對閘道器服務，業務服務，支撐服務在不同體系架構下的轉變，我們清晰的認識到Service Mesh能夠幫助我們重點解決微服務體系下繁瑣的“旁路支撐”服務，保證業務服務的簡單有效性。透過演化分析，最終基於Service Mesh的企業應用架構如下圖：

從圖中可以看到 Service Mesh 架構下重點做了三件事情：

1.閘道器層的接入工作，無論是外部請求接入，還是內部服務請求轉發，都可以基於 Service Mesh 提供的不同型別的 gateway 實現，同時還可以保證策略的統一控制和管理。省略了獨立的閘道器管理控制檯。

2.針對業務服務，增加了 Sidecar 的代理模型，用來處理所有的入站和出站流量，並且配合支撐服務的控制策略，實現業務服務的旁路控制功能。

3.統一面向網路的支撐服務，基於控制與資料分離的思想，根據業務的執行情況，提高企業應用執行過程中的動態控制能力。

同樣我們也意識到，利用 Service Mesh 處理服務通訊的能力，替換需要不同元件支撐的“註冊發現”，“容錯限流”“認證授權”“日誌蒐集”，“監控告警”“流量控制”等功能。在減少元件程式碼開銷的同時，將企業應用的支撐服務進一步下移。無論是開發人員，還是領域專家，可以集中精力用來處理應用業務，而不用在維護第三方的不同的功能元件上“浪費時間”。而業務運維人員，透過 Service Mesh 的控制平臺，能夠實時監測企業服務的執行狀態，而不需要向之前那樣花費精力維護不同的工具和元件。

最後讓我們一起討論一下，Service Mesh是如何做到這些的。 Service Mesh 本質上並沒有採用任何技術上的創新，更多是思想層面的變革。我們認為有幾個轉變是需要提出來的：

• 層級轉變：Service Mesh在設計思路上，把自己不再定位成企業應用元件，而是把自己下沉到基礎設施層，成為基礎設施的一部分，這樣層級的轉變就與企業業務本身劃清楚界限。
  
• 方式轉變：Service Mesh在實現思路上，高度抽象，聚焦於通訊鏈路本身，而不是聚焦於元件功能上，從網路層入手，抓住了服務通訊互動的本質。
  
• 控制轉變：Service Mesh將控制和實現分離，提供統一，靈活的控制入口，能夠快速方便的針對業務場景進行自定義處理。

最後的最後需要說明 Service Mesh 還不完善，還有很多問題需要在實際的企業應用過程中逐步去解決，讓我們一起拭目以待吧。