Service Mesh在企業(yè)級(jí)應(yīng)用的生存之道

導(dǎo)讀

近期與幾位企業(yè)用戶交流 Service Mesh 及其相關(guān)技術(shù)，大家對(duì)于它所展現(xiàn)的形態(tài)以及未來發(fā)展都表示出極大的興趣。但對(duì)當(dāng)下企業(yè)應(yīng)用現(xiàn)狀如何與 Service Mesh 整合到一起又表現(xiàn)出極大的困惑。本文力圖結(jié)合Service Mesh技術(shù)特性與企業(yè)應(yīng)用的實(shí)際情況，就 Service Mesh 如何應(yīng)對(duì)企業(yè)應(yīng)用給出博云自身的思考，歡迎有興趣的朋友一起討論。

在進(jìn)行詳細(xì)探討之前，我們首先回顧一下 Service Mesh 的定義：服務(wù)網(wǎng)格是一個(gè)用于處理服務(wù)間通信的基礎(chǔ)設(shè)施層，它負(fù)責(zé)為構(gòu)建復(fù)雜的云原生應(yīng)用傳遞可靠的網(wǎng)絡(luò)請(qǐng)求。在實(shí)踐中，服務(wù)網(wǎng)格通常實(shí)現(xiàn)一組與應(yīng)用程序部署在一起的輕量級(jí)的網(wǎng)絡(luò)代理，但對(duì)應(yīng)用程序來說是透明的。

從定義中我們可以清晰地看到 Service Mesh 的技術(shù)定位：“處理服務(wù)間通信的基礎(chǔ)設(shè)施層”。因此我們不能希望它幫我們簡(jiǎn)化開發(fā)測(cè)試場(chǎng)景面臨的挑戰(zhàn)（DevOps 或者應(yīng)用服務(wù)化，當(dāng)然一定程度上可以解耦應(yīng)用與基礎(chǔ)中間件的調(diào)用關(guān)系，稍后會(huì)詳細(xì)說明），或者解決應(yīng)用部署場(chǎng)景的問題（部署問題由容器編排平臺(tái)處理更加合適）。

總體來說，Service Mesh 專注業(yè)務(wù)應(yīng)用部署上線后期的通信領(lǐng)域問題，同時(shí)一定程度上解耦業(yè)務(wù)單元與基礎(chǔ)中間件的調(diào)用關(guān)系（例如服務(wù)注冊(cè)中心）。如圖所示：

圍繞 Service Mesh 所聚焦的領(lǐng)域以及如何服務(wù)于企業(yè)級(jí)應(yīng)用，本文重點(diǎn)探討4個(gè)問題：

· Service Mesh 的技術(shù)特性；
· Service Mesh 與企業(yè)應(yīng)用的整合之道；
· Service Mesh 的部署管理形態(tài)；
· Service Mesh 的遠(yuǎn)景形態(tài)。

Service Mesh技術(shù)特性

考慮到目前 Service Mesh 落地方式集中在以容器化為首的 PaaS 領(lǐng)域之內(nèi)，因此我們也將重點(diǎn)基于容器化方案探討 Service Mesh 所具備的技術(shù)特性。

從 Service Mesh發(fā) 展來看，無論是基礎(chǔ)的 Docker 運(yùn)行環(huán)境，還是以Kubernetes 為“事實(shí)標(biāo)準(zhǔn)”的容器編排環(huán)境，都是 Service Mesh 能夠快速發(fā)展的基石。以 Kubernetes 為例，Service Mesh 并非技術(shù)上的創(chuàng)新，更多是利用 CRD 特性對(duì) Kubernetes 的擴(kuò)展以及傳統(tǒng)技術(shù)的整合（防火墻、DNS服務(wù)發(fā)現(xiàn)等）。以 Isito 為例， Istio 基于引入的標(biāo)準(zhǔn)規(guī)范以及 Kubernetes CRD 特性自定義幾十種自身的資源，并依賴 kubectl CLI 命令工具對(duì)這些 CRD 進(jìn)行統(tǒng)一管理。

我們發(fā)現(xiàn)Service Mesh 的技術(shù)特性主要體現(xiàn)在5個(gè)方面：容器編排環(huán)境；數(shù)據(jù)代理控制；配置管理分發(fā)；服務(wù)鏈路追蹤；服務(wù)通信安全。

容器編排環(huán)境

結(jié)合 Service Mesh 落地的幾個(gè)方案來看，容器編排環(huán)境是 Service Mesh 能夠落地的必備要素之一（這里暫時(shí)不深入討論容器化采用的技術(shù)原理，如namespace，AUFS等）。容器化編排環(huán)境的特性能夠?qū)⑵髽I(yè)應(yīng)用或者業(yè)務(wù)實(shí)例組織成方便管理和尋址的業(yè)務(wù)單元，方便系統(tǒng)化的方式訪問這些單元。這里同樣暫時(shí)忽略 Mesh 外圍對(duì)接的各種 Adapter。

數(shù)據(jù)代理控制

從 Service Mesh 定義中可知，其本身是一個(gè)與應(yīng)用綁定在一起的輕量級(jí)網(wǎng)絡(luò)代理，該代理攔截所有服務(wù)請(qǐng)求的出站和入站流量，并依賴控制層面標(biāo)準(zhǔn)化接口提供的規(guī)則信息（最終轉(zhuǎn)化成防火墻內(nèi)的路由配置）進(jìn)行流量的轉(zhuǎn)發(fā)和控制，同時(shí)對(duì)調(diào)用日志、調(diào)用鏈路、響應(yīng)時(shí)長(zhǎng)進(jìn)行記錄和匯報(bào)。

配置管理分發(fā)

Service Mesh 為了保證數(shù)據(jù)代理功能的獨(dú)立性，將配置與數(shù)據(jù)代理進(jìn)行解耦。配置也稱作控制層面，負(fù)責(zé)從容器環(huán)境搜集服務(wù)信息，并且以高度抽象化的標(biāo)準(zhǔn)接口提供給數(shù)據(jù)代理服務(wù)，為流量轉(zhuǎn)發(fā)提供可靠的路由依賴。同時(shí)控制層面面向用戶提供“聲明式”的規(guī)則定義，這些規(guī)則會(huì)存儲(chǔ)在容器平臺(tái)中，同時(shí)生成路由轉(zhuǎn)發(fā)的流量控制規(guī)則，并且以接口的形式提供給數(shù)據(jù)代理服務(wù)，為路由轉(zhuǎn)發(fā)的流量控制提供管理依據(jù)。例如在 Istio 中規(guī)則定義表現(xiàn)為 Istio 定義的 CRD 資源，規(guī)則生效接口表現(xiàn)為 Policy 提供的 XDS 接口。

服務(wù)鏈路追蹤

服務(wù)鏈路在 Service Mesh 中是基礎(chǔ)必備的功能。它的實(shí)現(xiàn)依賴兩部分：數(shù)據(jù)采集和鏈路呈現(xiàn)。數(shù)據(jù)采集主要依賴數(shù)據(jù)代理服務(wù)進(jìn)行服務(wù)請(qǐng)求攔截或者轉(zhuǎn)發(fā)時(shí)記錄服務(wù)請(qǐng)求的源IP地址、目的IP地址和對(duì)應(yīng)的服務(wù)名稱等有效信息；鏈路呈現(xiàn)依賴于分布式跟蹤系統(tǒng)，將采集的服務(wù)調(diào)用鏈路信息存儲(chǔ)在分布式跟蹤系統(tǒng)中，做集中呈現(xiàn)，例如 Zipkin 等。

服務(wù)通信安全

安全是企業(yè)應(yīng)用必然關(guān)注的因素之一，那么 Service Mesh 在安全領(lǐng)域提供哪些技術(shù)特性呢？Service Mesh 作為 PaaS 的擴(kuò)展實(shí)現(xiàn)，主要從3個(gè)層面為企業(yè)應(yīng)用安全保駕護(hù)航：

第一：基于TLS的雙向通行加密。例如Isito中可以在部署時(shí)打開TLS雙向認(rèn)證配置，并且依賴獨(dú)立的證書管理功能，實(shí)現(xiàn)服務(wù)通信過程的加密。

第二：權(quán)限控制訪問。Service Mesh為了保證服務(wù)調(diào)用的合法性，提供了權(quán)限訪問控制。例如Isito中基于RBAC的權(quán)限訪問控制；

第三：基于策略的黑白名單訪問控制以及服務(wù)熔斷控制。

當(dāng)然僅僅依靠 Service Mesh 保證企業(yè)應(yīng)用的安全是不夠的，同樣需要借助其他軟硬件手段，例如防火墻、網(wǎng)絡(luò)安全監(jiān)控、內(nèi)部異常檢測(cè)等，具體不在本文討論范圍。

Service Mesh與企業(yè)級(jí)應(yīng)用整合之道

在了解 Service Mesh 技術(shù)特性以后，我們重點(diǎn)來聊一下 Service Mesh 如何與企業(yè)級(jí)應(yīng)用整合。

在具體展開之前，首先我們說一下企業(yè)應(yīng)用的現(xiàn)狀與特性：根據(jù) Gartner 對(duì)當(dāng)前 PaaS 市場(chǎng)的統(tǒng)計(jì)調(diào)研結(jié)果，大部分企業(yè)處于傳統(tǒng)應(yīng)用（物理或者虛擬化）向容器化轉(zhuǎn)型的階段，不同行業(yè)都期望能夠把自己的應(yīng)用合理地遷移到云端（重點(diǎn)考慮 PaaS 領(lǐng)域）。但對(duì)于遺留的企業(yè)系統(tǒng)，尤其是核心系統(tǒng)上 PaaS 多多少少有一定的顧慮，因此我們把企業(yè)應(yīng)用的部署形態(tài)分為三個(gè)等級(jí)（等級(jí)沒有先后之分）：

第一：核心系統(tǒng)，短期（未來幾年）不會(huì)考慮容器化處理，例如金融行業(yè)的核心數(shù)據(jù)庫和核心系統(tǒng)等；

第二：支撐系統(tǒng)，當(dāng)下以虛擬化居多，可能會(huì)嘗試服務(wù)容器化；

第三：外部系統(tǒng)，虛擬化為主，期望遷移到 PaaS 平臺(tái)；而目前無論是項(xiàng)目交付還是產(chǎn)品自研，絕大多數(shù)圍繞第三類應(yīng)用系統(tǒng)展開，這也是我們當(dāng)下考慮的重點(diǎn)。

其次我們來分析一下企業(yè)應(yīng)用的特性：企業(yè)應(yīng)用在大多數(shù)情況下是以業(yè)務(wù)為驅(qū)動(dòng)的。按照這個(gè)層面考慮，構(gòu)建業(yè)務(wù)系統(tǒng)時(shí)存在兩種情況：一體化應(yīng)用和服務(wù)化應(yīng)用。

針對(duì)一體化應(yīng)用，與 Service Mesh 進(jìn)行整合時(shí)，并不能發(fā)揮 Service Mesh 的功效（由于業(yè)務(wù)集中處理，所有功能及非功能系統(tǒng)全部集中在代碼本身，一定程度上 Service Mesh 集成意義不大）。因此我們重點(diǎn)考慮服務(wù)化應(yīng)用與 Service Mesh 的整合。這樣考慮的緣由是基于微服務(wù)或者云原生應(yīng)用是構(gòu)建系統(tǒng)的趨勢(shì)所在，也更符合應(yīng)用形態(tài)的發(fā)展規(guī)律。

結(jié)合企業(yè)級(jí)應(yīng)用的現(xiàn)狀以及特性，我們把 Service Mesh 與企業(yè)應(yīng)用的整合劃分為四個(gè)階段，如下圖所示：

應(yīng)用服務(wù)化

應(yīng)用服務(wù)化與大家所說的微服務(wù)構(gòu)建有一些不同之處。整體來講，應(yīng)用服務(wù)化還是利用微服務(wù)拆分原則，對(duì)應(yīng)用業(yè)務(wù)單元進(jìn)行服務(wù)拆分，同時(shí)確定服務(wù)間交互依賴的支撐組件。

不同的地方在于服務(wù)直接的交互組件的選型，不再采用 Spring Cloud、Dubbo 或者其他組件提供的支撐功能（如服務(wù)注冊(cè)與發(fā)現(xiàn)，服務(wù)鏈路跟蹤，負(fù)載均衡等），而是依賴容器平臺(tái)（如 kubernetes 提供的服務(wù)注冊(cè)發(fā)現(xiàn)，負(fù)載均衡）和 Service Mesh。此種做法的目的是將應(yīng)用支撐組件下沉，幫助客戶從技術(shù)調(diào)研與選型的細(xì)節(jié)中解脫出來，完全從業(yè)務(wù)角度考慮問題。業(yè)務(wù)之外的事情交由 PaaS 平臺(tái)、Service Mesh 統(tǒng)一處理。

應(yīng)用服務(wù)化，有兩個(gè)目的：拆分應(yīng)用業(yè)務(wù)單元和梳理業(yè)務(wù)單元調(diào)用鏈。(需要進(jìn)一步說明：摒棄服務(wù)注冊(cè)與發(fā)現(xiàn)組件，并非拋棄其能力，而是更換一種更方便的實(shí)現(xiàn)方式。開發(fā)環(huán)境下，各個(gè)服務(wù)聯(lián)調(diào)直接利用 HTTP 或者其他協(xié)議的調(diào)用框架進(jìn)行遠(yuǎn)程服務(wù)調(diào)用即可；測(cè)試或者生產(chǎn)環(huán)境中，將服務(wù)地址替換為容器平臺(tái)注冊(cè)的 Service 地址，從而具備服務(wù)注冊(cè)發(fā)現(xiàn)，服務(wù)負(fù)載的能力)。

當(dāng)然針對(duì)之前已經(jīng)基于 Spring Cloud 或者 Dubbo 開發(fā)的業(yè)務(wù)系統(tǒng)，在不改變?cè)屑軜?gòu)的基礎(chǔ)上同樣可以與 Service Mesh 進(jìn)行整合，但是在服務(wù)治理層面會(huì)存在一定沖突，目前來看，最有效的解法是把支撐能力交給平臺(tái)本身，將業(yè)務(wù)與支撐解耦，實(shí)現(xiàn)徹底的服務(wù)化。

應(yīng)用容器化

上面已經(jīng)提到過，在當(dāng)下的落地實(shí)踐中容器化是 Service Mesh 能夠存在的必要條件（當(dāng)然可以非容器化，但代價(jià)無疑是巨大的）。應(yīng)用服務(wù)拆分后的容器化改造，目前有多種實(shí)現(xiàn)的方式。最直接的是利用 DevOps 工具鏈，構(gòu)建應(yīng)用服務(wù)容器鏡像。當(dāng)然針對(duì)不同平臺(tái)或者語言也可以進(jìn)行獨(dú)立實(shí)現(xiàn)，例如 Maven 的 docker 插件，github 提供的 CI 流程，Jenkins 提供的 pipeline 等都能夠很好的實(shí)現(xiàn)服務(wù)容器化操作，這里不展開討論。需要指出的是，服務(wù)容器化的重點(diǎn)在于構(gòu)建一套符合企業(yè)制度與風(fēng)格的控制流程規(guī)范，這其中技術(shù)因素不是主導(dǎo)因素，需要結(jié)合企業(yè)自身情況決定。

應(yīng)用Mesh整合

應(yīng)用服務(wù)化和應(yīng)用容器化能夠解決應(yīng)用向 PaaS 平臺(tái)遷移的絕大多數(shù)場(chǎng)景。但是前兩者僅僅解決了服務(wù)編排部署問題，并沒有對(duì)服務(wù)上線后的管理支撐提供更多的功能，而 Service Mesh 恰恰定位于這一領(lǐng)域。那么應(yīng)用如何與 Mesh 進(jìn)行整合呢？可以分四步進(jìn)行，如圖所示：

第一步，Service Mesh 與 PaaS 基礎(chǔ)設(shè)施整合。利用 PaaS 平臺(tái)強(qiáng)大的編排部署能力，部署Service Mesh（具體項(xiàng)目例如Isito）的控制層面，各個(gè)組件在啟動(dòng)時(shí)會(huì)自動(dòng)初始化 Mesh 所需的環(huán)境以及從 PaaS 平臺(tái)中搜集需要的信息，必要的時(shí)候，可以把 Mesh 作為 PaaS 平臺(tái)基礎(chǔ)設(shè)施的一部分。

第二步，配置 PaaS 平臺(tái)。使其具備Mesh中代理程序自動(dòng)注入的功能（例如 Istio 自動(dòng)注入Sidecar的配置），當(dāng)然該步驟可以省略，后續(xù)由用戶手動(dòng)注入，目的在于攔截服務(wù)請(qǐng)求與轉(zhuǎn)發(fā)流量。

第三步，利用 PaaS 平臺(tái)直接部署業(yè)務(wù)應(yīng)用。此時(shí)應(yīng)用已經(jīng)與Mesh綁定在一起共享整個(gè)網(wǎng)絡(luò)棧資源，實(shí)現(xiàn)應(yīng)用與 Service Mesh 的初步整合。

第四步，利用第二步中部署的 Service Mesh 控制層面入口，設(shè)置服務(wù)通信規(guī)則，從而控制服務(wù)之間的通信，最終完成應(yīng)用與 Mesh 的整合。

Mesh管理控制

Service Mesh 管理控制是客戶介入服務(wù)間通信的唯一入口。而 Service Mesh 基于“聲明式”規(guī)則的控制將決定企業(yè)管理過程中更多的是規(guī)則的設(shè)定者，卻不具備對(duì)規(guī)則的有效性進(jìn)行實(shí)時(shí)校驗(yàn)的條件。因此需要結(jié)合其他外圍組件對(duì)當(dāng)前服務(wù)是否符合預(yù)期進(jìn)行監(jiān)測(cè)。例如對(duì)接 Prometheus，獲取服務(wù)的運(yùn)行數(shù)據(jù)（包括 tcp 連接數(shù)，請(qǐng)求成功數(shù)，請(qǐng)求鏈路時(shí)長(zhǎng)等），并且基于 AlterManager 進(jìn)行告警策略的管理；或者對(duì)接 ELK 日志平臺(tái)，對(duì)服務(wù)調(diào)用的日志進(jìn)行統(tǒng)一分析管理。當(dāng)然還有其他系統(tǒng)，統(tǒng)一稱為 Adapter。

總體而言，應(yīng)用是數(shù)據(jù)的產(chǎn)生源頭，Service Mesh 負(fù)責(zé)服務(wù)通信控制，服務(wù)數(shù)據(jù)收集以及服務(wù)數(shù)據(jù)上報(bào)，其他平臺(tái)負(fù)責(zé)數(shù)據(jù)處理，三者通力合作，才能將 Service Mesh 切實(shí)和企業(yè)應(yīng)用整合在一起，發(fā)揮它最大的功效。

Service Mesh部署管理形態(tài)

Service Mesh部署形態(tài)從當(dāng)下的技術(shù)實(shí)現(xiàn)考慮，需要緊緊依賴 PaaS 平臺(tái)的底層實(shí)現(xiàn)，尤其是對(duì)容器化環(huán)境的依賴。無論是單集群還是夸集群的部署，官方文檔都提供了詳盡的部署方案，這里不過多說明，可以參考 Istio 的實(shí)現(xiàn)（https://preliminary.istio.io/zh/docs/concepts/multicluster-deployments/）。

Servie Mesh 的管理形態(tài)最好的方式是與 PaaS 整合在一起，在 PaaS 自身的能力之上，增加服務(wù)治理的各種功能，有助于幫助 PaaS 平臺(tái)更好的整合資源。Service Mesh 同樣是對(duì)于 PaaS 的補(bǔ)充，從而形成全套的 PaaS 解決方案：包括 DevOps 工具形態(tài)，PaaS 編排部署形態(tài)，以及 Mesh 的服務(wù)治理形態(tài)。這時(shí)就具備了對(duì)應(yīng)用生命周期各個(gè)階段的集中控制能力。

Service Mesh遠(yuǎn)景形態(tài)

這個(gè)是大膽的預(yù)測(cè)了，無論從技術(shù)角度考慮，還是行業(yè)發(fā)展趨勢(shì)，Service Mesh 在未來必然會(huì)成為服務(wù)治理的主要工具之一。它對(duì)于企業(yè)應(yīng)用最大的優(yōu)勢(shì)是解耦應(yīng)用業(yè)務(wù)，企業(yè)能夠徹底從業(yè)務(wù)角度考慮問題。相比純粹的微服務(wù)架構(gòu)，又向前邁了一步，同時(shí)與容器編排部署平臺(tái)的集成，最終有可能成為企業(yè)級(jí)應(yīng)用編排部署和服務(wù)治理的標(biāo)準(zhǔn)形態(tài)。