Service Mesh 初體驗

前言

計算機(jī)軟件技術(shù)發(fā)展到現(xiàn)在，軟件架構(gòu)的演進(jìn)無不朝著讓開發(fā)者能夠更加輕松快捷地構(gòu)建大型復(fù)雜應(yīng)用的方向發(fā)展。容器技術(shù)最初是為了解決運(yùn)行環(huán)境的不一致問題而產(chǎn)生的，隨著不斷地發(fā)展，圍繞容器技術(shù)衍生出來越來越多的新方向。

最近幾年，云計算領(lǐng)域不斷地出現(xiàn)很多新的軟件架構(gòu)模式，其中有一些很熱門的概念名詞如：云原生、函數(shù)計算、Serverless、ServiceMesh等等，而本文將初窺一下ServiceMesh的面紗。下面結(jié)合自己的理解盡量以通俗的話進(jìn)行敘述。

背景和定義

微服務(wù)及服務(wù)治理

在微服務(wù)之前的軟件開發(fā)中，往往通過一個應(yīng)用的方式將所有的模塊都包括進(jìn)去，并一起編譯、打包、部署、運(yùn)維。這種方式存在很多問題，由于單個應(yīng)用包含的東西太多，其中某個模塊出現(xiàn)問題或者需要更新那么整個應(yīng)用就需要重新部署。這種方式給開發(fā)和運(yùn)維帶來了很大的麻煩。隨著應(yīng)用的逐漸復(fù)雜，單個應(yīng)用涉及的東西就會越來越多，慢慢地大家發(fā)現(xiàn)了其中很多的缺點，開始對服務(wù)進(jìn)行劃分，將一個大的應(yīng)用按照不同的維度進(jìn)行劃分從而產(chǎn)生很多個小的應(yīng)用，各應(yīng)用之間會形成一個調(diào)用關(guān)系，每個小的應(yīng)用由不同的開發(fā)負(fù)責(zé)，大家各自部署和運(yùn)維，這樣微服務(wù)就出現(xiàn)了。

由于微服務(wù)中各應(yīng)用部署在不同的機(jī)器上，服務(wù)之間需要進(jìn)行通信和協(xié)調(diào)，相比單個應(yīng)用來說會麻煩很多。在同一個應(yīng)用內(nèi)不同方法之間的調(diào)用由于在相同的內(nèi)存中，在代碼編譯打包時已經(jīng)進(jìn)行了鏈接，因此調(diào)用是可尋址且快速的。微服務(wù)下不同服務(wù)之間的調(diào)用涉及到不同進(jìn)程或者機(jī)器之間的通信，一般需要通過第三方中間件的方式作為中介和協(xié)調(diào)，由于種種這些，面向微服務(wù)出現(xiàn)了很多中間件包括服務(wù)治理的框架。通過服務(wù)治理工具可以管理其接入的所有應(yīng)用，使得服務(wù)之間的通信和協(xié)調(diào)更加簡單高效。

容器及容器編排

最初容器技術(shù)是為了解決應(yīng)用運(yùn)行環(huán)境不一致的問題而出現(xiàn)的，避免在本地環(huán)境或者測試環(huán)境能夠跑通，等發(fā)到生產(chǎn)環(huán)境卻出現(xiàn)問題。通過容器將程序及其依賴一起打包到鏡像中去，將程序的鏡像在任何安裝并運(yùn)行了容器軟件的機(jī)器上啟動若干的容器，每個容器就是應(yīng)用運(yùn)行時的實例，這些實例一般擁有完全相同的運(yùn)行環(huán)境和參數(shù)。使得不管在任何機(jī)器上應(yīng)用都可以表現(xiàn)出一樣的效果。這給開發(fā)、測試、運(yùn)維帶來了極大的便利，不再需要為不同機(jī)器上構(gòu)建相同的運(yùn)行環(huán)境而頭大。且鏡像可以Push到鏡像倉庫，這使得應(yīng)用可以進(jìn)行很方便的遷移和部署。Docker就是一個應(yīng)用廣泛的容器技術(shù)。目前越來越多的應(yīng)用以微服務(wù)的方式并通過容器進(jìn)行部署，給了軟件開發(fā)極大的活力。

與微服務(wù)和服務(wù)治理的關(guān)系類似，越來越多的應(yīng)用通過容器進(jìn)行部署，使得集群上的容器數(shù)量急劇增加，通過人工的管理和運(yùn)維這些容器已經(jīng)變得很艱難且低效，為了解決諸多容器及容器之間的關(guān)系出現(xiàn)了很多編排工具，容器編排工具能夠管理容器的整個生命周期。如Docker官方出的docker-compose和docker swarm，這兩個工具能實現(xiàn)批量容器的啟動和編排，但功能較為簡單，不足以支撐大型的容器集群。Google基于內(nèi)部大量的容器管理經(jīng)驗，開源出了Kubernetes項目，Kubernetes（K8S）是針對Google集群上每周億級別的容器而設(shè)計的，具有很強(qiáng)大的容器編排能力和豐富的功能。K8S通過定義了很多資源，這些資源以聲明式的方式進(jìn)行創(chuàng)建，可以通過JSON或者YAML文件表示一個資源，K8S支持多種容器，但主流的是Docker容器，K8S提供了容器接入的相關(guān)標(biāo)準(zhǔn)，只要容器實現(xiàn)了該標(biāo)準(zhǔn)就可以被K8S所編排。由于K8S的功能較多，不在此一一敘述，有興趣可以參考官方文檔或者ATA上搜索相關(guān)文章。

當(dāng)某個公司的應(yīng)用已經(jīng)完全微服務(wù)化后，選擇以容器的方式部署應(yīng)用，此時可以在集群上部署K8S，通過K8S提供的能力進(jìn)行應(yīng)用容器的管理，運(yùn)維可以也可以面向K8S進(jìn)行工作。由于K8S是目前使用最廣泛的容器編排工具，因此成為了容器編排的一個標(biāo)準(zhǔn)了，目前集團(tuán)內(nèi)部也有自己的容器和容器編排工具。

面向以K8S為代表的容器管理方式衍生出了一些新的技術(shù)。

云原生

最近兩年云原生被炒的很火，可以在各處看到很多大佬對云原生的高談闊論，下面直接拋出CNCF對云原生的定義：

云原生技術(shù)有利于各組織在公有云、私有云和混合云等新型動態(tài)環(huán)境中，構(gòu)建和運(yùn)行可彈性擴(kuò)展的應(yīng)用。云原生的代表技術(shù)包括容器、服務(wù)網(wǎng)格、微服務(wù)、不可變基礎(chǔ)設(shè)施和聲明式API。 這些技術(shù)能夠構(gòu)建容錯性好、易于管理和便于觀察的松耦合系統(tǒng)。結(jié)合可靠的自動化手段，云原生技術(shù)使工程師能夠輕松地對系統(tǒng)作出頻繁和可預(yù)測的重大變更。

在我看來，通過微服務(wù)的方式開發(fā)應(yīng)用，以容器進(jìn)行部署，使用K8S等容器編排工具進(jìn)行容器集群的管理，使得開發(fā)運(yùn)維都面向K8S，這就是云原生。云原生可以方便的構(gòu)建應(yīng)用，并對應(yīng)用進(jìn)行完整的監(jiān)控，以及在應(yīng)用針對不同流量時能進(jìn)行快速的擴(kuò)容和縮容。如下圖：

云原生主要包括四個部分:

• 微服務(wù)

• 容器

• 持續(xù)集成和交付

• DevOps

PS：總是覺得云原生這個叫法太抽象了，很難讓人通過名字想到這是個啥東西。

ServiceMesh的定義

前面講了微服務(wù)、容器、容器編排、云原生等，其實就是為了得出什么是ServiceMesh，自己總結(jié)了一下：SeviceMesh是云原生下的微服務(wù)治理方案。

當(dāng)我們通過微服務(wù)的方式將應(yīng)用以容器的形式部署在K8S上后，服務(wù)之間調(diào)用和治理其實有新的方案，可以不需要依賴傳統(tǒng)的微服務(wù)治理框架。ServiceMesh通過對每個應(yīng)用在其Pod中啟動一個Sidecar（邊車）實現(xiàn)對應(yīng)用的透明代理，所有出入應(yīng)用的流量都先經(jīng)過該應(yīng)用的Sidecar，服務(wù)之間的調(diào)用轉(zhuǎn)變成了Sidecar之間的調(diào)用，服務(wù)的治理轉(zhuǎn)變成了對Sidecar的治理。在ServiceMesh中Sidecar是透明的，開發(fā)無感知的，之前一直覺得奇怪，總覺得一個應(yīng)用要讓別人發(fā)現(xiàn)它從而調(diào)用它，總得引入一些庫然后進(jìn)行主動的服務(wù)注冊，不然啥都不做，別人咋知道這個應(yīng)用的存在，為什么在ServiceMesh中就可以省去這些，做到對開發(fā)者完全地透明呢？這個的實現(xiàn)依賴于容器編排工具，通過K8S進(jìn)行應(yīng)用的持續(xù)集成和交付時，在啟動應(yīng)用Pod后，其實已經(jīng)通過Yaml文件的形式向K8S注冊了自己的服務(wù)以及聲明了服務(wù)之間的關(guān)系，ServiceMesh通過和K8S進(jìn)行通信獲取集群上所有的服務(wù)信息，通過K8S這個中間者實現(xiàn)了對開發(fā)者的透明。如下圖所示，是ServiceMesh的一個基本結(jié)構(gòu)，包括數(shù)據(jù)平面和控制平面。

這種方式存在很多好處，我們可以發(fā)現(xiàn)在這種模式下應(yīng)用的語言其實不會對整個服務(wù)治理過程有什么影響，對于ServiceMesh來說，它只關(guān)心Pod或者說是Pod中的容器實例，并不需要在乎容器中應(yīng)用的實現(xiàn)語言是啥，Sidecar和其負(fù)責(zé)的容器在同一個Pod中。這樣ServiceMesh就可以實現(xiàn)跨語言，這也是目前很多傳統(tǒng)的服務(wù)治理框架的一大缺點，而且采用傳統(tǒng)的服務(wù)治理，需要對應(yīng)用引入大量的依賴，這樣就會造成依賴之間的各種沖突，集團(tuán)通過Pandora對應(yīng)用的各種依賴進(jìn)行隔離。再者傳統(tǒng)的服務(wù)治理門檻較高，需要開發(fā)者對整個架構(gòu)有一定的了解，且發(fā)現(xiàn)問題排查較為麻煩。這也造成了開發(fā)和運(yùn)維之間的界限不清，在ServiceMesh中開發(fā)只需要交付代碼，運(yùn)維可以基于K8S去維護(hù)整個容器集群。

發(fā)展現(xiàn)狀

通過目前查閱的資料來看，ServiceMesh一詞最早出現(xiàn)在2016年，最近兩年被炒的很火，螞蟻金服已經(jīng)有了自己的一套完整的ServiceMesh服務(wù)框架--SofaMesh，集團(tuán)很多團(tuán)隊也在進(jìn)行相應(yīng)的跟進(jìn)。

從歷史發(fā)展的路線來看，程序的開發(fā)方式經(jīng)歷了很多的變化，但總的方向是變得越來越簡單了，現(xiàn)在我們在集團(tuán)內(nèi)進(jìn)行開發(fā)，可以很簡單的構(gòu)建一個支撐較大QPS的服務(wù)，這得益于集團(tuán)的整個技術(shù)體系的完整和豐富以及強(qiáng)大的技術(shù)積淀。

我們下面來看看應(yīng)用開發(fā)到底經(jīng)歷了啥？

發(fā)展歷史

主機(jī)直接階段

如上圖，這一階段應(yīng)該是最古老的階段，兩臺機(jī)器通過網(wǎng)線直接連接，一個應(yīng)用包含了你能想到的所有的功能，包括兩臺機(jī)器的連接管理，這時還沒有網(wǎng)絡(luò)的概念，畢竟只能和通過網(wǎng)線直接連接在一起的機(jī)器進(jìn)行通信。

網(wǎng)絡(luò)層的出現(xiàn)

如上圖，隨著技術(shù)的發(fā)展，網(wǎng)絡(luò)層出現(xiàn)了，機(jī)器可以和通過網(wǎng)絡(luò)連接的其他所有機(jī)器進(jìn)行通信，不再限制于必須要網(wǎng)線直連兩臺機(jī)器。

集成到應(yīng)用程序內(nèi)部的流量控制

如上圖，由于每個應(yīng)用所在環(huán)境和機(jī)器配置不一樣，接受流量的能力也不相同，當(dāng)A應(yīng)用發(fā)送的流量大于了B應(yīng)用的接受能力時，那么無法接收的數(shù)據(jù)包必定會被丟棄，這時就需要對流量進(jìn)行控制，最開始流量的控制需要應(yīng)用自己去實現(xiàn)，網(wǎng)絡(luò)層只負(fù)責(zé)接收應(yīng)用下發(fā)的數(shù)據(jù)包并進(jìn)行傳輸。

流量控制轉(zhuǎn)移到網(wǎng)絡(luò)層

如上圖，慢慢地大家發(fā)應(yīng)用中的網(wǎng)絡(luò)流量控制是可以轉(zhuǎn)移到網(wǎng)絡(luò)層的，所以網(wǎng)絡(luò)層中的流量控制出現(xiàn)了，我想大概就是指TCP的流量控制吧，這樣還能保證可靠的網(wǎng)絡(luò)通信。

應(yīng)用程序的中集成服務(wù)發(fā)現(xiàn)和斷路器

如上圖，開發(fā)者通過在自己的代碼模塊中實現(xiàn)服務(wù)發(fā)現(xiàn)和斷路器。

專門用于服務(wù)發(fā)現(xiàn)和斷路器的軟件包/庫

如上圖，開發(fā)者通過引用第三方依賴去實現(xiàn)服務(wù)發(fā)現(xiàn)和斷路器。

出現(xiàn)了專門用于服務(wù)發(fā)現(xiàn)和斷路器的開源軟件

如上圖，基于各種中間件去實現(xiàn)服務(wù)發(fā)現(xiàn)和斷路器。

ServiceMesh出現(xiàn)

最終到了現(xiàn)在，ServiceMesh大法誕生，進(jìn)一步解放了生產(chǎn)力，提高了軟件整個生命周期的效率。

ServiceMesh市場競爭

雖然直到2017年底，ServiceMesh才開始較大規(guī)模被世人了解，這場微服務(wù)市場之爭也才顯現(xiàn)，但是其實ServiceMesh這股微服務(wù)的新勢力，早在 2016年初就開始萌芽： 2016年1月，離開Twitter的基礎(chǔ)設(shè)施工程師William Morgan和Oliver Gould，在github上發(fā)布了Linkerd 0.0.7版本，業(yè)界第一個ServiceMesh項目就此誕生。Linkerd基于Twitter的Finagle開源項目，大量重用了Finagle的類庫，但是實現(xiàn)了通用性，成為了業(yè)界第一個ServiceMesh項目。而Envoy是第二個ServiceMesh項目，兩者的開發(fā)時間差不多，在2017年都相繼成為CNCF項目。2017年5月24日，Istio 0.1 release版本發(fā)布，Google和IBM高調(diào)宣講，社區(qū)反響熱烈，很多公司在這時就紛紛站隊表示支持Istio。Linkerd的風(fēng)光瞬間被蓋過，從意氣風(fēng)發(fā)的少年一夜之間變成過氣網(wǎng)紅。當(dāng)然，從產(chǎn)品成熟度上來說，linkerd作為業(yè)界僅有的兩個生產(chǎn)級ServiceMesh實現(xiàn)之一，暫時還可以在Istio成熟前繼續(xù)保持市場。但是，隨著Istio的穩(wěn)步推進(jìn)和日益成熟，外加第二代ServiceMesh的天然優(yōu)勢，Istio取代第一代的Linkerd只是個時間問題。自從在2016年決定委身于Istio之后，Envoy就開始了一條波瀾不驚的平穩(wěn)發(fā)展之路，和Linkerd的跌宕起伏完全不同。在功能方面，由于定位在數(shù)據(jù)平面，因此Envoy無需考慮太多，很多工作在Istio的控制平面完成就好，Envoy從此專心于將數(shù)據(jù)平面做好，完善各種細(xì)節(jié)。在市場方面，Envoy和Linkerd性質(zhì)不同，不存在生存和發(fā)展的戰(zhàn)略選擇，也沒有正面對抗生死大敵的巨大壓力。 從Google和IBM聯(lián)手決定推出Istio開始，Istio就注定永遠(yuǎn)處于風(fēng)頭浪尖，無論成敗，Istio面世之后，贊譽(yù)不斷，尤其是ServiceMesh技術(shù)的愛好者，可以說是為之一振：以新一代ServiceMesh之名橫空出世的Istio，對比Linkerd，優(yōu)勢明顯。同時產(chǎn)品路線圖上有一大堆令人眼花繚亂的功能。假以時日，如果Istio能順利地完成開發(fā)，穩(wěn)定可靠，那么這會是一個非常美好、值得憧憬的大事件，

Istio介紹

Istio是目前最熱的ServiceMesh開源項目，Istio主要分為兩個部分：數(shù)據(jù)平面和控制平面。Istio實現(xiàn)了云原生下的微服務(wù)治理，能實現(xiàn)服務(wù)發(fā)現(xiàn)，流量控制，監(jiān)控安全等。Istio通過在一個Pod里啟動一個應(yīng)用和Sidecar方式實現(xiàn)透明代理。Istio是一個拓展性較高的框架，其不僅可以支持K8S，還可以支持其他如Mesos等資源調(diào)度器。如下圖所示，為Istio的整體架構(gòu)：

• 邏輯上分為數(shù)據(jù)平面（上圖中的上半部分）和控制平面（上圖中的下半部分）。

• 數(shù)據(jù)平面由一組以 Sidecar 方式部署的智能代理（Envoy）組成。這些代理可以調(diào)節(jié)和控制微服務(wù)及 Mixer 之間所有的網(wǎng)絡(luò)通信。

• 控制平面負(fù)責(zé)管理和配置代理來路由流量。此外控制平面配置 Mixer 以實施策略和收集遙測數(shù)據(jù)。

• Pilot是整個架構(gòu)中的抽象層，將對接K8S等資源調(diào)度器的步驟進(jìn)行抽象并以適配器的形式展現(xiàn)，并和用戶以及Sidecar交互。

• Galley負(fù)責(zé)資源配置為驗證。

• Citadel用于生成身份，及密鑰和證書管理

• 核心功能包括流量控制、安全控制、可觀測性、多平臺支持、可定制化。

Mixer

Mixer同樣是一個可拓展的模塊，其負(fù)責(zé)遙感數(shù)據(jù)的采集以及集成了一些后端服務(wù)（BAAS），Sidecar會不斷向Mixer報告自己的流量情況，Mixer對流量情況進(jìn)行匯總，以可視化的形式展現(xiàn)，此外Sidecar可以調(diào)用Mixer提供的一些后端服務(wù)能力，例如鑒權(quán)、登錄、日志等等，Mixer通過適配器的方式對接各種后端服務(wù)。

In-process Adapter形式

之前版本的Isito采用這種將后端服務(wù)適配器集成在Mixer內(nèi)部的形式，這種方式會有一個問題，就是某個后端服務(wù)適配器出現(xiàn)問題即會影響整個Mixer模塊，但由于適配器和Mixer集成在一起，在同一個進(jìn)程內(nèi)，方法的調(diào)用會很快。

Out-of-process Adapter形式

目前版本的Istio將Adapter移到Mixer外部，這樣可以實現(xiàn)Mixer與Adapter的解耦，當(dāng)Adapter出現(xiàn)問題并不會影響Mixer，但這種方式同樣也存在問題，即Adapter在Mixer外，是兩個不同的進(jìn)程，二者之間的調(diào)用是通過RPC的方式，這種方式比同進(jìn)程內(nèi)部的方法調(diào)用會慢很多，因此性能會受到影響。

Pilot

• Envoy API負(fù)責(zé)和Envoy的通訊, 主要是發(fā)送服務(wù)發(fā)現(xiàn)信息和流量控制規(guī)則給Envoy。

• Abstract Model 是 Pilot 定義的服務(wù)的抽象模型, 以從特定平臺細(xì)節(jié)中解耦, 為跨平臺提供基礎(chǔ)。

• Platform Adapter則是這個抽象模型的實現(xiàn)版本, 用于對接外部的不同平臺如k8s/mesos等。

• Rules API提供接口給外部調(diào)用以管理 Pilot, 包括命令行工具Istioctl以及未來可能出現(xiàn)的第三方管理界面。

Galley

Galley 原來僅負(fù)責(zé)進(jìn)行配置驗證, 1.1 后升級為整個控制面的配置管理中心, 除了繼續(xù)提供配置驗證功能外, Galley還負(fù)責(zé)配置的管理和分發(fā), Galley 使用 網(wǎng)格配置協(xié)議(Mesh Configuration Protocol) 和其他組件進(jìn)行配置的交互.

Istio 創(chuàng)造了50多個CRD, 其復(fù)雜度可見一斑, 所以有人說面向k8s編程近似于面向yaml編程.早期的Galley 僅僅負(fù)責(zé)對配置進(jìn)行運(yùn)行時驗證, Istio 控制面各個組件各自去list/watch 各自關(guān)注的配置。越來越多且復(fù)雜的配置給Istio用戶帶來了諸多不便, 主要體現(xiàn)在:

• 配置的缺乏統(tǒng)一管理, 組件各自訂閱, 缺乏統(tǒng)一回滾機(jī)制, 配置問題難以定位。

• 配置可復(fù)用度低, 比如在1.1之前, 每個Mixer adpater 就需要定義個新的CRD。

• 配置的隔離, ACL 控制, 一致性, 抽象程度, 序列化等等問題都還不太令人滿意

隨著Istio功能的演進(jìn), 可預(yù)見的Istio CRD數(shù)量還會繼續(xù)增加, 社區(qū)計劃將Galley 強(qiáng)化為Istio配置控制層, Galley 除了繼續(xù)提供配置驗證功能外, 還將提供配置管理流水線, 包括輸入, 轉(zhuǎn)換, 分發(fā), 以及適合Istio控制面的配置分發(fā)協(xié)議(MCP)。

Citadel

將服務(wù)拆分為微服務(wù)之后，在帶來各種好處的同時，在安全方面也帶來了比單體時代更多的需求，畢竟不同功能模塊之間的調(diào)用方式從原來單體架構(gòu)中的方法調(diào)用變成了微服務(wù)之間的遠(yuǎn)程調(diào)用：

• 加密：為了不泄露信息，為了抵御中間人攻擊，需要對服務(wù)間通訊進(jìn)行加密。

• 訪問控制：不是每個服務(wù)都容許被任意訪問，因此需要提供靈活的訪問控制，如雙向 TLS 和細(xì)粒度的訪問策略。

• 審計：如果需要審核系統(tǒng)中哪些用戶做了什么，則需要提供審計功能。

Citadel 是 Istio 中負(fù)責(zé)安全性的組件，但是 Citadel 需要和其他多個組件配合才能完成工作：

• Citadel：用于密鑰管理和證書管理，下發(fā)到Envoy等負(fù)責(zé)通訊轉(zhuǎn)發(fā)的組件。

• Envoy：使用從Citadel下發(fā)而來的密鑰和證書，實現(xiàn)服務(wù)間通訊的安全，注意在應(yīng)用和Envoy之間是走Localhost，通常不用加密。

• Pilot：將授權(quán)策略和安全命名信息分發(fā)給Envoy。

• Mixer：負(fù)責(zé)管理授權(quán)，完成審計等。

Istio支持的安全類功能有：

• 流量加密：加密服務(wù)間的通訊流量。

• 身份認(rèn)證：通過內(nèi)置身份和憑證管理可以提供強(qiáng)大的服務(wù)間和最終用戶身份驗證，包括傳輸身份認(rèn)證和來源身份認(rèn)證，支持雙向TLS。

• 授權(quán)和鑒權(quán)：提供基于角色的訪問控制（RBAC），提供命名空間級別，服務(wù)級別和方法級別的訪問控制。

作者信息：彭家浩，花名毅忻，阿里巴巴淘系技術(shù)部開發(fā)工程師，熱愛云計算。

原文鏈接

本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載