企業(yè)應(yīng)用架構(gòu)演化探討：從微服務(wù)到Service Mesh

導(dǎo)讀

當(dāng)下微服務(wù)的實(shí)踐方案中，Spring Cloud，Dubbo作為主流的落地方案，在企業(yè)應(yīng)用架構(gòu)中發(fā)揮越來越重要的作用。本文探討企業(yè)應(yīng)用架構(gòu)如何從微服務(wù)架構(gòu)向Service Mesh架構(gòu)演化，并形成落地方案。需要特別說明：本文討論的架構(gòu)目前適用于普通的企業(yè)級應(yīng)用，其他行業(yè)（例如互聯(lián)網(wǎng)）需要進(jìn)一步擴(kuò)展。

?

在討論之前，我們需要明確一個事實(shí)：企業(yè)應(yīng)用一定是圍繞業(yè)務(wù)進(jìn)行的。無論采用什么的架構(gòu)落地，都是為了更好的為應(yīng)用業(yè)務(wù)進(jìn)行服務(wù)。從企業(yè)應(yīng)用的特性考慮，主要包括：穩(wěn)定性，安全性，擴(kuò)展性，容錯性。

圍繞著企業(yè)應(yīng)用的這些特點(diǎn)，我們來看一個典型的微服務(wù)企業(yè)架構(gòu)模型，如圖所示：

• 服務(wù)接入層：企業(yè)暴露到外部訪問的入口，一般通過防火墻等。

• 網(wǎng)關(guān)層：服務(wù)網(wǎng)關(guān)是介于客戶端和服務(wù)端的中間層，所有的外部請求會先經(jīng)過服務(wù)網(wǎng)關(guān)，為企業(yè)應(yīng)用提供統(tǒng)一的訪問控制入口。服務(wù)網(wǎng)關(guān)是微服務(wù)架構(gòu)下的服務(wù)拆分，聚合，路由，認(rèn)證以及流控綜合體現(xiàn)。

• 支撐服務(wù)層：為企業(yè)應(yīng)用提供運(yùn)行所需的支撐環(huán)境，包括注冊發(fā)現(xiàn)，集中配置，容錯限流，認(rèn)證授權(quán)，日志聚合，監(jiān)測告警，消息服務(wù)等

• 業(yè)務(wù)服務(wù)層：業(yè)務(wù)服務(wù)是企業(yè)應(yīng)用的核心所在，為企業(yè)領(lǐng)域應(yīng)用的具體實(shí)現(xiàn)，一般進(jìn)一步拆分為基礎(chǔ)服務(wù)（基礎(chǔ)功能）和聚合服務(wù)（綜合場景）。

• 平臺服務(wù)層：為企業(yè)應(yīng)用提供運(yùn)行所需的軟件資源，包括應(yīng)用服務(wù)器，應(yīng)用發(fā)布管理，應(yīng)用鏡像包管理，服務(wù)治理。

• 基礎(chǔ)設(shè)施層：為企業(yè)應(yīng)用提供運(yùn)行所需的硬件資源，包括計(jì)算資源，網(wǎng)絡(luò)資源，存儲資源，基本的安全策略控制等。

?

從這個典型的服務(wù)架構(gòu)體系中，能夠清晰的表明層級架構(gòu)以及各層涵蓋的職責(zé)說明。我們暫不考慮基礎(chǔ)設(shè)施層和平臺服務(wù)兩層，重點(diǎn)關(guān)注網(wǎng)關(guān)服務(wù)，業(yè)務(wù)服務(wù)，支撐服務(wù)，突出其中的一些基礎(chǔ)支撐功能組件，這也是我們本篇探討的重點(diǎn)內(nèi)容。如下圖所示：

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

那么如何基于一個平臺來實(shí)現(xiàn)這些企業(yè)應(yīng)用需要的能力呢？經(jīng)過一定階段的技術(shù)調(diào)研，我們認(rèn)為Service Mesh能夠幫助我們初步達(dá)到這個目標(biāo)。

我們都知道Service Mesh以解決“服務(wù)通信”的問題作為其設(shè)計(jì)初衷，聚焦基礎(chǔ)設(shè)施“網(wǎng)絡(luò)層”，并以此做技術(shù)基礎(chǔ)，解決業(yè)務(wù)通信場景面臨的問題。那么如何把它應(yīng)用在企業(yè)應(yīng)用架構(gòu)中來取代“微服務(wù)套裝組件”呢？那接下來讓我們針對網(wǎng)關(guān)服務(wù)，業(yè)務(wù)服務(wù)，支撐服務(wù)分別來看一下，如何從原來的微服務(wù)“套裝組件”中抽離出來，實(shí)現(xiàn)Service Mesh方向的轉(zhuǎn)變。

網(wǎng)關(guān)服務(wù)

前面提到過：服務(wù)網(wǎng)關(guān)是介于客戶端和服務(wù)端的中間層。從功能上不難理解，對內(nèi)屏蔽內(nèi)部細(xì)節(jié)，對外提供統(tǒng)一服務(wù)接口。從場景聚焦角度考慮，網(wǎng)關(guān)根據(jù)不同的場景承載不同的職責(zé)，包括認(rèn)證，授權(quán)，路由，流控，負(fù)載等。（之前我們也聊過網(wǎng)關(guān)組件的對比及具體實(shí)現(xiàn)，感興趣的同學(xué)可點(diǎn)擊微服務(wù)五種開源API網(wǎng)關(guān)實(shí)現(xiàn)組件對比）。

由此可見，服務(wù)網(wǎng)關(guān)是企業(yè)應(yīng)用架構(gòu)下一些列功能的綜合體現(xiàn)。那么在Service Mesh情況下如何處理網(wǎng)關(guān)服務(wù)呢？在展開之前首先需要說明一個前提：目前為止Service Mesh跟真正企業(yè)網(wǎng)關(guān)相比還存在一定的不足之處，例如“協(xié)議轉(zhuǎn)化”，“安全策略”，“性能要求”等方面。在這里我們也是探討這樣的可能性。下面以Istio為例，我們來看一下，如何提供網(wǎng)關(guān)層面的服務(wù)。

Istio在網(wǎng)關(guān)層面提供兩種類型的網(wǎng)關(guān)服務(wù)：Ingress Gateway，Egress。

Ingress Gateway

Ingress Gateway用于接收傳入的HTTP/TCP連接，它配置暴露端口，協(xié)議供外部統(tǒng)一接入，但是自身不提供任何的路由配置，而是完全依賴 Istio 的控制規(guī)則來進(jìn)行流量路由。從而與內(nèi)部服務(wù)請求統(tǒng)一到同一個控制層面上。

Egress

在企業(yè)應(yīng)用與外部應(yīng)用之間，有時候?yàn)榱藰I(yè)務(wù)需要會出現(xiàn)內(nèi)部服務(wù)調(diào)用外部服務(wù)的情況，此時一般會從企業(yè)內(nèi)部接入第三方網(wǎng)關(guān)來獲取服務(wù)數(shù)據(jù)。在 Isito 中你同樣可以基于Egress來達(dá)到目的。Isito中提供兩種方式：一種基于ServiceEntry + VirtualService的配置，實(shí)現(xiàn)第三方服務(wù)的訪問，一種擴(kuò)大sidecar的訪問地址列表。（參考文檔：https://preliminary.istio.io/zh/docs/tasks/traffic-management/egress/）。

基于上述兩種場景，我們可以看出，在 Service Mesh 的體系下，網(wǎng)關(guān)層面變成一個可以動態(tài)生成和銷毀的組件，能夠通過控制層面實(shí)現(xiàn)統(tǒng)一規(guī)則管理，并且實(shí)時生效。

基于Service Mesh的網(wǎng)關(guān)服務(wù)如下圖所示：

從實(shí)現(xiàn)原理上分析，傳統(tǒng)的網(wǎng)關(guān)實(shí)現(xiàn)基于 Servlet 的 filter 的模式，實(shí)現(xiàn)服務(wù)請求轉(zhuǎn)移過程中的層層過濾和處理。區(qū)別在于采用同步或者異步處理機(jī)制，用來解決網(wǎng)關(guān)的性能瓶頸。而Service Mesh的網(wǎng)關(guān)完全是基于網(wǎng)絡(luò)代理的請求轉(zhuǎn)發(fā)與控制，本質(zhì)上作用在服務(wù)的 Iptables 上，通過對 Iptables 的規(guī)則控制達(dá)到同樣的效果。

?

業(yè)務(wù)服務(wù)

業(yè)務(wù)是企業(yè)應(yīng)用的“重中之重”，無論哪種企業(yè)架構(gòu)，最終都是為了更好地為業(yè)務(wù)提供服務(wù)，那么我們?nèi)绾卧赟ervice Mesh的體系下，重構(gòu)業(yè)務(wù)服務(wù)呢？我們以兩個簡化的服務(wù)調(diào)用來說明整個架構(gòu)的轉(zhuǎn)變過程。

假如要實(shí)現(xiàn)服務(wù)A，服務(wù)B的相互調(diào)用，最原始的方式是服務(wù)A基于協(xié)議層直接調(diào)用服務(wù)B（這里暫時忽略高可用，多副本，負(fù)載均衡的方式），如圖所示：

由圖可見，服務(wù)A基于某種協(xié)議完成對服務(wù)B的請求，相對比較簡單。但是我們知道這樣雖然能夠快速完成業(yè)務(wù)關(guān)聯(lián)，但是無法確保業(yè)務(wù)正常穩(wěn)定的運(yùn)行，因此我們需要引入更多的服務(wù)來保證業(yè)務(wù)的穩(wěn)定，可靠，可控。此時我們最容易想到的是引入微服務(wù)的支撐組件來達(dá)到目標(biāo)。

以Spring Cloud方案為例，我們來說明當(dāng)前微服務(wù)架構(gòu)的實(shí)現(xiàn)方式。為了滿足企業(yè)應(yīng)用對服務(wù)A，服務(wù)B的管理控制，需要額外引入“注冊中心”，“網(wǎng)關(guān)”，“配置中心”，“服務(wù)監(jiān)測”，“事件消息”，“鏈路跟蹤”，“日志服務(wù)”等眾多與直接業(yè)務(wù)無關(guān)的“旁路保障服務(wù)”，簡化一下，如下圖所示：

?

從圖中可以看出，每個服務(wù)都引入了大量與業(yè)務(wù)無關(guān)的“保障服務(wù)”，這些“旁路保障服務(wù)”消耗的資源，與比業(yè)務(wù)本身消耗的資源成“倍數(shù)關(guān)系”。隨著服務(wù)數(shù)目的增多，業(yè)務(wù)服務(wù)本身占用的資源比會越來越少，此時開發(fā)人員會把大量的精力花費(fèi)在維護(hù)這些“旁路保障服務(wù)”上，而忽略業(yè)務(wù)本身。這對于企業(yè)應(yīng)用而言，有些本末倒置的意思。

我們再來看一下 Service Mesh 體系下，我們?nèi)绾谓鉀Q上述問題。Service Mesh為了解決企業(yè)應(yīng)用的“通信問題”重點(diǎn)做了四個方面的工作，以 Istio 為代表，提供了包括流量管理，安全配置，策略控制以及外圍組件支撐的遙測功能（需要的朋友，可以參考官方文檔：https://preliminary.istio.io/zh/docs），在Service Mesh的架構(gòu)下，服務(wù)A調(diào)用服務(wù)B的架構(gòu)會變成下圖所示：

通過上圖我們可以發(fā)現(xiàn)，與Spring Cloud的實(shí)現(xiàn)方式相比，似乎簡單了很多，我們不再需要在業(yè)務(wù)服務(wù)中引入眾多的“旁路保障服務(wù)”，而是保障了業(yè)務(wù)服務(wù)本身的簡單化。那么Service Mesh是如何處理的呢？

第一，引入了Sidecar代理模型，作為服務(wù)流量控制的入口和出口，保證能夠?qū)W(wǎng)絡(luò)層面數(shù)據(jù)做實(shí)時監(jiān)控和調(diào)整；

第二，控制器根據(jù)具體業(yè)務(wù)情況，分發(fā)控制狀態(tài)和控制指令，Sidecar獲取控制信息后，及時更新緩存信息，保證策略有效性。

第三，Sidecar由于能夠攔截所有請求的流量信息，定期把收集的數(shù)據(jù)向控制層進(jìn)行上報(bào)，從而完成服務(wù)狀態(tài)和應(yīng)用鏈路的監(jiān)測。

第四，所有的這些都是在應(yīng)用部署階段完成，在開發(fā)層面不需要花費(fèi)大量的精力。

基于以上四點(diǎn)我們可以發(fā)現(xiàn)，Service Mesh 僅僅通過方式轉(zhuǎn)變就達(dá)到了同樣的效果，還極大的解放了開發(fā)人員。

通過業(yè)務(wù)服務(wù)調(diào)用方式的實(shí)現(xiàn)轉(zhuǎn)變，我們發(fā)現(xiàn)這樣一個事實(shí)：Service Mesh在保證業(yè)務(wù)簡化有效的同時，進(jìn)一步屏蔽了多種開發(fā)語言帶來的障礙。它完全基于網(wǎng)絡(luò)層面和協(xié)議層面作為出發(fā)點(diǎn)，達(dá)到“以不變應(yīng)萬變”的效果。

?

支撐服務(wù)

從企業(yè)業(yè)務(wù)的價值角度考慮，其實(shí)支撐服務(wù)更多屬于“資源消耗”品，雖然如此，它卻是企業(yè)應(yīng)用架構(gòu)不可或缺的一部分。從單一的業(yè)務(wù)調(diào)用--->微服務(wù)體系業(yè)務(wù)調(diào)用--->Service Mesh 體系業(yè)務(wù)調(diào)用的轉(zhuǎn)變方式中，可以看出支撐服務(wù)處于一個層級不斷下降的過程。而依賴于ServiceMesh的定位，最終一些支撐服務(wù)會作為基礎(chǔ)設(shè)施的形態(tài)呈現(xiàn)出來，這也是未來發(fā)展的趨勢所在。支撐服務(wù)在企業(yè)架構(gòu)的形態(tài)轉(zhuǎn)變?nèi)鐖D所示：

• 傳統(tǒng)架構(gòu)：傳統(tǒng)架構(gòu)下，支撐服務(wù)，業(yè)務(wù)服務(wù)基本上沒有明確的邊界區(qū)分，實(shí)現(xiàn)方式上都通過代碼雜糅在一起。

• 微服務(wù)架構(gòu)：微服務(wù)架構(gòu)下，支撐服務(wù)，業(yè)務(wù)服務(wù)能夠初步分離，但是需要保證代碼框架的統(tǒng)一性和依賴性，跨語言受限比較嚴(yán)重。

• Service Mesh架構(gòu)：Service Mesh架構(gòu)下，支撐服務(wù)，業(yè)務(wù)服務(wù)能夠徹底分離，不收語言限制，唯一需要考慮的是不同協(xié)議的支持情況。

通過支撐服務(wù)的轉(zhuǎn)變形態(tài)可以看出，支撐服務(wù)與業(yè)務(wù)服務(wù)分離是必然趨勢，而最終的受限取決于多元化的網(wǎng)絡(luò)協(xié)議的處理分析能力。當(dāng)然我們需要明確一個事實(shí)：就Service Mesh目前的發(fā)展趨勢和定位而言，并不能夠完全取代所有的支撐服務(wù)，例如事件消息，配置管理等。我們更多期望它能夠幫助解決應(yīng)用服務(wù)在網(wǎng)絡(luò)層面需要面對的場景和問題。這也是它發(fā)揮價值的地方所在。

?

通過對網(wǎng)關(guān)服務(wù)，業(yè)務(wù)服務(wù)，支撐服務(wù)在不同體系架構(gòu)下的轉(zhuǎn)變，我們清晰的認(rèn)識到Service Mesh能夠幫助我們重點(diǎn)解決微服務(wù)體系下繁瑣的“旁路支撐”服務(wù)，保證業(yè)務(wù)服務(wù)的簡單有效性。通過演化分析，最終基于Service Mesh的企業(yè)應(yīng)用架構(gòu)如下圖：

?

從圖中可以看到 Service Mesh 架構(gòu)下重點(diǎn)做了三件事情：

1. 網(wǎng)關(guān)層的接入工作，無論是外部請求接入，還是內(nèi)部服務(wù)請求轉(zhuǎn)發(fā)，都可以基于 Service Mesh 提供的不同類型的 gateway 實(shí)現(xiàn)，同時還可以保證策略的統(tǒng)一控制和管理。省略了獨(dú)立的網(wǎng)關(guān)管理控制臺。

   
   

2. 針對業(yè)務(wù)服務(wù)，增加了 Sidecar 的代理模型，用來處理所有的入站和出站流量，并且配合支撐服務(wù)的控制策略，實(shí)現(xiàn)業(yè)務(wù)服務(wù)的旁路控制功能。

   
   

3. 統(tǒng)一面向網(wǎng)絡(luò)的支撐服務(wù)，基于控制與數(shù)據(jù)分離的思想，根據(jù)業(yè)務(wù)的運(yùn)行情況，提高企業(yè)應(yīng)用運(yùn)行過程中的動態(tài)控制能力。

同樣我們也意識到，利用 Service Mesh 處理服務(wù)通信的能力，替換需要不同組件支撐的“注冊發(fā)現(xiàn)”，“容錯限流”“認(rèn)證授權(quán)”“日志搜集”，“監(jiān)控告警”“流量控制”等功能。在減少組件代碼開銷的同時，將企業(yè)應(yīng)用的支撐服務(wù)進(jìn)一步下移。無論是開發(fā)人員，還是領(lǐng)域?qū)＜?，可以集中精力用來處理?yīng)用業(yè)務(wù)，而不用在維護(hù)第三方的不同的功能組件上“浪費(fèi)時間”。而業(yè)務(wù)運(yùn)維人員，通過 Service Mesh 的控制平臺，能夠?qū)崟r監(jiān)測企業(yè)服務(wù)的運(yùn)行狀態(tài)，而不需要向之前那樣花費(fèi)精力維護(hù)不同的工具和組件。

?

最后讓我們一起討論一下，Service Mesh是如何做到這些的。Service Mesh 本質(zhì)上并沒有采用任何技術(shù)上的創(chuàng)新，更多是思想層面的變革。我們認(rèn)為有幾個轉(zhuǎn)變是需要提出來的：

• 層級轉(zhuǎn)變：Service Mesh在設(shè)計(jì)思路上，把自己不再定位成企業(yè)應(yīng)用組件，而是把自己下沉到基礎(chǔ)設(shè)施層，成為基礎(chǔ)設(shè)施的一部分，這樣層級的轉(zhuǎn)變就與企業(yè)業(yè)務(wù)本身劃清楚界限。

  
  

• 方式轉(zhuǎn)變：Service Mesh在實(shí)現(xiàn)思路上，高度抽象，聚焦于通信鏈路本身，而不是聚焦于組件功能上，從網(wǎng)絡(luò)層入手，抓住了服務(wù)通信交互的本質(zhì)。

  
  

• 控制轉(zhuǎn)變：Service Mesh將控制和實(shí)現(xiàn)分離，提供統(tǒng)一，靈活的控制入口，能夠快速方便的針對業(yè)務(wù)場景進(jìn)行自定義處理。

?

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

?

本文由博云研究院原創(chuàng)發(fā)表，轉(zhuǎn)載請注明出處。