作者：李寧
來源：博雲技術社區 / 博雲研究院
當下微服務的實踐方案中，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/zh/docs/tasks/traffic-management/egress/）。
基於上述兩種場景，我們可以看出，在 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/zh/docs），在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 還不完善，還有很多問題需要在實際的企業應用過程中逐步去解決，讓我們一起拭目以待吧。
點擊【閱讀】，立即體驗微服務平臺
歡迎點擊“京東雲”瞭解更多精彩內容
