前言

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

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

背景和定義

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

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

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

容器及容器編排

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

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

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

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

云原生

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

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

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

云原生主要包括四個(gè)部分:

• 微服務(wù)

• 容器

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

• DevOps

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

ServiceMesh的定義

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

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

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

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

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

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

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

發(fā)展歷史

主機(jī)直接階段

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

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

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

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

如上圖，由于每個(gè)應(yīng)用所在環(huán)境和機(jī)器配置不一樣，接受流量的能力也不相同，當(dāng)A應(yīng)用發(fā)送的流量大于了B應(yīng)用的接受能力時(shí)，那么無(wú)法接收的數(shù)據(jù)包必定會(huì)被丟棄，這時(shí)就需要對(duì)流量進(jìn)行控制，最開(kāi)始流量的控制需要應(yīng)用自己去實(shí)現(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)和斷路器

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

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

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

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

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

ServiceMesh出現(xiàn)

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

ServiceMesh市場(chǎng)競(jìng)爭(zhēng)

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

Istio介紹

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

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

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

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

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

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

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

• 核心功能包括流量控制、安全控制、可觀測(cè)性、多平臺(tái)支持、可定制化。

Mixer

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

In-process Adapter形式

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

Out-of-process Adapter形式

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

Pilot

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

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

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

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

Galley

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

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

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

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

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

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

Citadel

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

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

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

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

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

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

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

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

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

Istio支持的安全類功能有：

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

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

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

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

原文鏈接

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