企業應用架構演化探討：從微服務到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的訪問地址列表。（參考文檔：https://preliminary.istio.io/...）。

基於上述兩種場景，咱們能夠看出，在 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 爲表明，提供了包括流量管理，安全配置，策略控制以及外圍組件支撐的遙測功能（須要的朋友，能夠參考官方文檔：https://preliminary.istio.io/...），在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 架構下重點作了三件事情：

• 網關層的接入工做，不管是外部請求接入，仍是內部服務請求轉發，均可以基於 Service Mesh 提供的不一樣類型的 gateway 實現，同時還能夠保證策略的統一控制和管理。省略了獨立的網關管理控制檯。
• 針對業務服務，增長了 Sidecar 的代理模型，用來處理全部的入站和出站流量，而且配合支撐服務的控制策略，實現業務服務的旁路控制功能。
• 統一面向網絡的支撐服務，基於控制與數據分離的思想，根據業務的運行狀況，提升企業應用運行過程當中的動態控制能力。

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

最後讓咱們一塊兒討論一下，Service Mesh是如何作到這些的。Service Mesh 本質上並無採用任何技術上的創新，更可能是思想層面的變革。咱們認爲有幾個轉變是須要提出來的：

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

最後的最後須要說明 Service Mesh 還不完善，還有不少問題須要在實際的企業應用過程當中逐步去解決，讓咱們一塊兒拭目以待吧。

本文由博雲研究院原創發表，轉載請註明出處。