作者簡介：敖小劍，十五年軟件開發(fā)經(jīng)驗(yàn)，微服務(wù)專家，專注于基礎(chǔ)架構(gòu)，Cloud Native擁護(hù)者，敏捷實(shí)踐者。曾在亞信、愛立信、唯品會(huì)和ppmoney任職, 現(xiàn)任數(shù)人云資深架構(gòu)師，本文由數(shù)人云獨(dú)家授權(quán)發(fā)布，歡迎加作者微信（aoxiaojian80）交流。

Service Mesh新秀，初出茅廬便聲勢浩蕩，前有Google，IBM和Lyft傾情奉獻(xiàn)，后有業(yè)界大佬俯首膜拜，這就是今天將要介紹的主角，扛起Service Mesh大旗，掀起新一輪微服務(wù)開發(fā)浪潮的Istio！

今天的主角名叫 Istio，估計(jì)很多同學(xué)在此之前可能完全沒有聽過這個(gè)名字。請不必介意，沒聽過很正常，因?yàn)镮stio的確是一個(gè)非常新的東西，出世也才四個(gè)月而已。

今天的內(nèi)容將會(huì)分成三個(gè)部分:

• 介紹： 讓大家了解Istio是什么，以及有什么好處，以及Istio背后的開發(fā)團(tuán)隊(duì)
• 架構(gòu)： 介紹Istio的整體架構(gòu)和四個(gè)主要功能模塊的具體功能，這塊內(nèi)容會(huì)比較偏技術(shù)
• 展望： 介紹Istio的后續(xù)開發(fā)計(jì)劃，探討未來的發(fā)展預(yù)期

一、介紹

Istio是什么：Istio是Google/IBM/Lyft聯(lián)合開發(fā)的開源項(xiàng)目，2017年5月發(fā)布第一個(gè)release 0.1.0， 官方定義為:

Istio：一個(gè)連接，管理和保護(hù)微服務(wù)的開放平臺(tái)。

按照isito文檔中給出的定義:

Istio提供一種簡單的方式來建立已部署的服務(wù)的網(wǎng)絡(luò)，具備負(fù)載均衡，服務(wù)到服務(wù)認(rèn)證，監(jiān)控等等功能，而不需要改動(dòng)任何服務(wù)代碼。

簡單的說，有了Istio，你的服務(wù)就不再需要任何微服務(wù)開發(fā)框架（典型如Spring Cloud，Dubbo），也不再需要自己動(dòng)手實(shí)現(xiàn)各種復(fù)雜的服務(wù)治理的功能（很多是Spring Cloud和Dubbo也不能提供的，需要自己動(dòng)手）。只要服務(wù)的客戶端和服務(wù)器可以進(jìn)行簡單的直接網(wǎng)絡(luò)訪問，就可以通過將網(wǎng)絡(luò)層委托給Istio，從而獲得一系列的完備功能。

可以近似的理解為：Istio = 微服務(wù)框架 + 服務(wù)治理

名字和圖標(biāo)：

Istio來自希臘語，英文意思是”Sail”， 翻譯為中文是“啟航”。它的圖標(biāo)如下:

可以類比Google的另外一個(gè)相關(guān)產(chǎn)品：Kubernetes，名字也是同樣起源于古希臘，是船長或者駕駛員的意思。下圖是Kubernetes的圖標(biāo)：

后面會(huì)看到，Istio和Kubernetes的關(guān)系，就像它們的名字和圖標(biāo)一樣， 可謂”一脈相傳”。

主要特性：

Istio的關(guān)鍵功能:

• HTTP/1.1，HTTP/2，gRPC和TCP流量的自動(dòng)區(qū)域感知負(fù)載平衡和故障切換。
• 通過豐富的路由規(guī)則，容錯(cuò)和故障注入，對流行為的細(xì)粒度控制。
• 支持訪問控制，速率限制和配額的可插拔策略層和配置API。
• 集群內(nèi)所有流量的自動(dòng)量度，日志和跟蹤，包括集群入口和出口。
• 安全的服務(wù)到服務(wù)身份驗(yàn)證，在集群中的服務(wù)之間具有強(qiáng)大的身份標(biāo)識(shí)。?
  這些特性在稍后的架構(gòu)章節(jié)時(shí)會(huì)有介紹。

為什么要使用Istio

在深入Istio細(xì)節(jié)之前，先來看看，為什么要使用Istio？它可以幫我們解決什么問題?

微服務(wù)的兩面性

最近兩三年來微服務(wù)方興未艾， 可以看到越來越多的公司和開發(fā)人員陸陸續(xù)續(xù)投身到微服務(wù)架構(gòu)， 讓一個(gè)一個(gè)的微服務(wù)項(xiàng)目落地。

但是，在這一片叫好的喧鬧中， 我們還是發(fā)覺一些普遍存在的問題：雖然微服務(wù)對開發(fā)進(jìn)行了簡化，通過將復(fù)雜系統(tǒng)切分為若干個(gè)微服務(wù)來分解和降低復(fù)雜度，使得這些微服務(wù)易于被小型的開發(fā)團(tuán)隊(duì)所理解和維護(hù)。但是，復(fù)雜度并非從此消失。微服務(wù)拆分之后，單個(gè)微服務(wù)的復(fù)雜度大幅降低，但是由于系統(tǒng)被從一個(gè)單體拆分為幾十甚至更多的微服務(wù)， 就帶來了另外一個(gè)復(fù)雜度：微服務(wù)的連接、管理和監(jiān)控。

試想， 對于一個(gè)大型系統(tǒng)， 需要對多達(dá)上百個(gè)甚至上千個(gè)微服務(wù)的管理、部署、版本控制、安全、故障轉(zhuǎn)移、策略執(zhí)行、遙測和監(jiān)控等，談何容易。更不要說更復(fù)雜的運(yùn)維需求，例如A/B測試，金絲雀發(fā)布，限流，訪問控制和端到端認(rèn)證。

開發(fā)人員和運(yùn)維人員在單體應(yīng)用程序向分布式微服務(wù)架構(gòu)的轉(zhuǎn)型中， 不得不面臨上述挑戰(zhàn)。

服務(wù)網(wǎng)格

Service Mesh，服務(wù)網(wǎng)格，也有人翻譯為”服務(wù)嚙合層”。這貌似是今年才出來的新名詞？在2017年之前沒有聽過，雖然類似的產(chǎn)品已經(jīng)存在挺長時(shí)間。

什么是Service Mesh（服務(wù)網(wǎng)格）？

Service Mesh是專用的基礎(chǔ)設(shè)施層，輕量級(jí)高性能網(wǎng)絡(luò)代理。提供安全的、快速的、可靠地服務(wù)間通訊，與實(shí)際應(yīng)用部署一起，但對應(yīng)用透明。

為了幫助理解， 下圖展示了服務(wù)網(wǎng)格的典型邊車部署方式：

圖中應(yīng)用作為服務(wù)的發(fā)起方，只需要用最簡單的方式將請求發(fā)送給本地的服務(wù)網(wǎng)格代理，然后網(wǎng)格代理會(huì)進(jìn)行后續(xù)的操作，如服務(wù)發(fā)現(xiàn)，負(fù)載均衡，最后將請求轉(zhuǎn)發(fā)給目標(biāo)服務(wù)。當(dāng)有大量服務(wù)相互調(diào)用時(shí)，它們之間的服務(wù)調(diào)用關(guān)系就會(huì)形成網(wǎng)格，如下圖所示：

在上圖中綠色方塊為服務(wù)，藍(lán)色方塊為邊車部署的服務(wù)網(wǎng)格，藍(lán)色線條為服務(wù)間通訊。可以看到藍(lán)色的方塊和線條組成了整個(gè)網(wǎng)格，我們將這個(gè)圖片旋轉(zhuǎn)90°，就更加明顯了：服務(wù)網(wǎng)格呈現(xiàn)出一個(gè)完整的支撐態(tài)勢，將所有的服務(wù)”架”在網(wǎng)格之上：

服務(wù)網(wǎng)格的細(xì)節(jié)我們今天不詳細(xì)展開， 詳細(xì)內(nèi)容大家可以參考網(wǎng)上資料。或者稍后我將會(huì)推出一個(gè)服務(wù)網(wǎng)格的專題，單獨(dú)深入介紹服務(wù)網(wǎng)格。

Istio也可以視為是一種服務(wù)網(wǎng)格， 在Istio網(wǎng)站上詳細(xì)解釋了這一概念：

如果我們可以在架構(gòu)中的服務(wù)和網(wǎng)絡(luò)間透明地注入一層，那么該層將賦予運(yùn)維人員對所需功能的控制，同時(shí)將開發(fā)人員從編碼實(shí)現(xiàn)分布式系統(tǒng)問題中解放出來。通常將這個(gè)統(tǒng)一的架構(gòu)層與服務(wù)部署在一起，統(tǒng)稱為“服務(wù)嚙合層”。由于微服務(wù)有助于分離各個(gè)功能團(tuán)隊(duì)，因此服務(wù)嚙合層有助于將運(yùn)維人員從應(yīng)用特性開發(fā)和發(fā)布過程中分離出來。通過系統(tǒng)地注入代理到微服務(wù)間的網(wǎng)絡(luò)路徑中，Istio將迥異的微服務(wù)轉(zhuǎn)變成一個(gè)集成的服務(wù)嚙合層。

Istio能做什么?

Istio力圖解決前面列出的微服務(wù)實(shí)施后需要面對的問題。Istio 首先是一個(gè)服務(wù)網(wǎng)絡(luò)，但是Istio又不僅僅是服務(wù)網(wǎng)格: 在 Linkerd， Envoy 這樣的典型服務(wù)網(wǎng)格之上，Istio提供了一個(gè)完整的解決方案，為整個(gè)服務(wù)網(wǎng)格提供行為洞察和操作控制，以滿足微服務(wù)應(yīng)用程序的多樣化需求。

Istio在服務(wù)網(wǎng)絡(luò)中統(tǒng)一提供了許多關(guān)鍵功能(以下內(nèi)容來自官方文檔)：

• 流量管理：控制服務(wù)之間的流量和API調(diào)用的流向，使得調(diào)用更可靠，并使網(wǎng)絡(luò)在惡劣情況下更加健壯。

• 可觀察性：了解服務(wù)之間的依賴關(guān)系，以及它們之間流量的本質(zhì)和流向，從而提供快速識(shí)別問題的能力。

• 策略執(zhí)行：將組織策略應(yīng)用于服務(wù)之間的互動(dòng)，確保訪問策略得以執(zhí)行，資源在消費(fèi)者之間良好分配。策略的更改是通過配置網(wǎng)格而不是修改應(yīng)用程序代碼。

• 服務(wù)身份和安全：為網(wǎng)格中的服務(wù)提供可驗(yàn)證身份，并提供保護(hù)服務(wù)流量的能力，使其可以在不同可信度的網(wǎng)絡(luò)上流轉(zhuǎn)。

除此之外，Istio針對可擴(kuò)展性進(jìn)行了設(shè)計(jì)，以滿足不同的部署需要：

• 平臺(tái)支持：Istio旨在在各種環(huán)境中運(yùn)行，包括跨云， 預(yù)置，Kubernetes，Mesos等。最初專注于Kubernetes，但很快將支持其他環(huán)境。

• 集成和定制：策略執(zhí)行組件可以擴(kuò)展和定制，以便與現(xiàn)有的ACL，日志，監(jiān)控，配額，審核等解決方案集成。

這些功能極大的減少了應(yīng)用程序代碼，底層平臺(tái)和策略之間的耦合，使微服務(wù)更容易實(shí)現(xiàn)。

Istio的真正價(jià)值

上面摘抄了Istio官方的大段文檔說明，洋洋灑灑的列出了Istio的大把大把高大上的功能。但是這些都不是重點(diǎn)！理論上說，任何微服務(wù)框架，只要愿意往上面堆功能，早晚都可以實(shí)現(xiàn)這些。那，關(guān)鍵在哪里？

不妨設(shè)想一下，在平時(shí)理解的微服務(wù)開發(fā)過程中，在沒有Istio這樣的服務(wù)網(wǎng)格的情況下，要如何開發(fā)我們的應(yīng)用程序，才可以做到前面列出的這些豐富多彩的功能? 這數(shù)以幾十記的各種特性，如何才可以加入到應(yīng)用程序?

無外乎，找個(gè)Spring Cloud或者Dubbo的成熟框架，直接搞定服務(wù)注冊，服務(wù)發(fā)現(xiàn)，負(fù)載均衡，熔斷等基礎(chǔ)功能。然后自己開發(fā)服務(wù)路由等高級(jí)功能， 接入Zipkin等Apm做全鏈路監(jiān)控，自己做加密、認(rèn)證、授權(quán)。 想辦法搞定灰度方案，用Redis等實(shí)現(xiàn)限速、配額。 諸如此類，一大堆的事情， 都需要自己做，無論是找開源項(xiàng)目還是自己操刀，最后整出一個(gè)帶有一大堆功能的應(yīng)用程序，上線部署。然后給個(gè)配置說明到運(yùn)維，告訴他說如何需要灰度，要如何如何， 如果要限速，配置哪里哪里。

這些工作，相信做微服務(wù)落地的公司，基本都跑不掉，需求是現(xiàn)實(shí)存在的，無非能否實(shí)現(xiàn)，以及實(shí)現(xiàn)多少的問題，但是毫無疑問的是，要做到這些，絕對不是一件容易的事情。

問題是，即使費(fèi)力做到這些事情到這里還沒有完：運(yùn)維跑來提了點(diǎn)要求，在他看來很合理的要求，比如說：簡單點(diǎn)的加個(gè)黑名單， 復(fù)雜點(diǎn)的要做個(gè)特殊的灰度：將來自iPhone的用戶流量導(dǎo)1%到Stagging環(huán)境的2.0新版本……

這里就有一個(gè)很嚴(yán)肅的問題， 給每個(gè)業(yè)務(wù)程序的開發(fā)人員: 你到底想往你的業(yè)務(wù)程序里面塞多少管理和運(yùn)維的功能? 就算你hold的住技術(shù)和時(shí)間，你有能力一個(gè)一個(gè)的滿足各種運(yùn)維和管理的需求嗎？ 當(dāng)你發(fā)現(xiàn)你開始疲于響應(yīng)各種非功能性的需求時(shí)，就該開始反省了: 我們開發(fā)的是業(yè)務(wù)程序，它的核心價(jià)值在業(yè)務(wù)邏輯的處理和實(shí)現(xiàn)，將如此之多的時(shí)間精力花費(fèi)在這些非業(yè)務(wù)功能上， 這真的合理嗎? 而且即使是在實(shí)現(xiàn)層面，微服務(wù)實(shí)施時(shí)，最重要的是如何劃分微服務(wù)，如何制定接口協(xié)議，你該如何分配你有限的時(shí)間和資源？

Istio 超越 spring cloud和dubbo 等傳統(tǒng)開發(fā)框架之處， 就在于不僅僅帶來了遠(yuǎn)超這些框架所能提供的功能， 而且也不需要應(yīng)用程序?yàn)榇俗龃罅康母膭?dòng)， 開發(fā)人員也不必為上面的功能實(shí)現(xiàn)進(jìn)行大量的知識(shí)儲(chǔ)備。

總結(jié):

Istio 大幅降低微服務(wù)架構(gòu)下應(yīng)用程序的開發(fā)難度，勢必極大的推動(dòng)微服務(wù)的普及。個(gè)人樂觀估計(jì)，隨著isito的成熟，微服務(wù)開發(fā)領(lǐng)域?qū)⒂瓉硪淮晤嵏残缘淖兏铩：竺嫖覀冊诮榻BIstio的架構(gòu)和功能模塊時(shí), 大家可以了解到Istio是如何做到這些的。

開發(fā)團(tuán)隊(duì)

在開始介紹Istio的架構(gòu)之前, 我們再詳細(xì)介紹一下Istio的開發(fā)團(tuán)隊(duì), 看看背后的大佬。首先，Istio的開發(fā)團(tuán)隊(duì)主要來自 Google， IBM和Lyft，摘抄一段官方八股：

基于我們?yōu)閮?nèi)部和企業(yè)客戶構(gòu)建和運(yùn)營大規(guī)模微服務(wù)的常見經(jīng)驗(yàn)，Google，IBM和Lyft聯(lián)手創(chuàng)建Istio，希望為微服務(wù)開發(fā)和維護(hù)提供可靠的基礎(chǔ)。Google和IBM相信不需要介紹了, 在Istio項(xiàng)目中這兩個(gè)公司是絕對主力，舉個(gè)例子,下圖是 Istio Working Group的成員列表：

數(shù)一下, 總共18人，10個(gè)google，8個(gè)IBM。注意這里沒有Lyft出現(xiàn)，因?yàn)長yft的貢獻(xiàn)主要集中在Envoy。

Google

Istio來自鼎鼎大名的GCP/Google Cloud Platform, 這里誕生了同樣大名鼎鼎的 App Engine, Cloud Engine等重量級(jí)產(chǎn)品。

Google為Istio帶來了Kubernetes和gRPC, 還有和Envoy相關(guān)的特性如安全，性能和擴(kuò)展性。

八卦: 負(fù)責(zé)Istio的GCP產(chǎn)品經(jīng)理Varun Talwar， 同時(shí)也負(fù)責(zé)gRPC項(xiàng)目, 所以關(guān)注gRPC的同學(xué)（比如我自己）可以不用擔(dān)心：Istio對gRPC的支持必然是沒有問題的。

IBM

IBM的團(tuán)隊(duì)同來來自IBM云平臺(tái), IBM的貢獻(xiàn)是:

除了開發(fā)Istio控制面板之外, 還有和Envoy相關(guān)的其他特性如跨服務(wù)版本的流量切分, 分布式請求追蹤(Zipkin)和失敗注入。

Lyft

Lyft的貢獻(xiàn)主要集中在Envoy代理，這是Lyft開源的服務(wù)網(wǎng)格，基于C++。據(jù)說Envoy在Lyft可以管理超過100個(gè)服務(wù)，跨越10000個(gè)虛擬機(jī)，每秒處理2百萬請求。本周最新消息，Envoy剛剛加入CNCF，成為該基金會(huì)的第十一個(gè)項(xiàng)目。

最后， 在Isito的介紹完成之后, 我們開始下一節(jié)內(nèi)容，Istio的架構(gòu)。

二、架構(gòu)

整體架構(gòu)

Istio服務(wù)網(wǎng)格邏輯上分為數(shù)據(jù)面板和控制面板。

數(shù)據(jù)面板由一組智能代理（Envoy）組成，代理部署為邊車，調(diào)解和控制微服務(wù)之間所有的網(wǎng)絡(luò)通信。

控制面板負(fù)責(zé)管理和配置代理來路由流量，以及在運(yùn)行時(shí)執(zhí)行策略。

下圖為Istio的架構(gòu)詳細(xì)分解圖：

這是宏觀視圖，可以更形象的展示Istio兩個(gè)面板的功能和合作：

以下分別介紹 Istio 中的主要模塊 Envoy/Mixer/Pilot/Auth。

Envory

以下介紹內(nèi)容來自Istio官方文檔：

Istio 使用Envoy代理的擴(kuò)展版本，Envoy是以C++開發(fā)的高性能代理，用于調(diào)解服務(wù)網(wǎng)格中所有服務(wù)的所有入站和出站流量。

Istio利用了Envoy的許多內(nèi)置功能，例如動(dòng)態(tài)服務(wù)發(fā)現(xiàn)，負(fù)載均衡，TLS termination，HTTP/2&gRPC代理，熔斷器，健康檢查，基于百分比流量拆分的分段推出，故障注入和豐富的metrics。

Envoy實(shí)現(xiàn)了過濾和路由、服務(wù)發(fā)現(xiàn)、健康檢查，提供了具有彈性的負(fù)載均衡。它在安全上支持TLS，在通信方面支持gRPC。

概括說，Envoy提供的是服務(wù)間網(wǎng)絡(luò)通訊的能力，包括(以下均可支持TLS)：

• HTTP／1.1
• HTTP/2
• gRPC

• TCP?
  以及網(wǎng)絡(luò)通訊直接相關(guān)的功能：

• 服務(wù)發(fā)現(xiàn)：從Pilot得到服務(wù)發(fā)現(xiàn)信息

• 過濾

• 負(fù)載均衡
• 健康檢查
• 執(zhí)行路由規(guī)則(Rule): 規(guī)則來自Polit,包括路由和目的地策略

• 加密和認(rèn)證: TLS certs來自 Istio-Auth?
  此外, Envoy 也吐出各種數(shù)據(jù)給Mixer:

• Metrics

• Logging

• Distribution Trace: 目前支持 Zipkin

總結(jié): Envoy是Istio中負(fù)責(zé)”干活”的模塊,如果將整個(gè)Istio體系比喻為一個(gè)施工隊(duì),那么 Envoy 就是最底層負(fù)責(zé)搬磚的民工，所有體力活都由Envoy完成。所有需要控制，決策，管理的功能都是其他模塊來負(fù)責(zé)，然后配置給Envoy。

Istio架構(gòu)回顧

在繼續(xù)介紹Istio其他的模塊之前，我們來回顧一下Istio的架構(gòu)，前面我們提到, Istio服務(wù)網(wǎng)格分為兩大塊：數(shù)據(jù)面板和控制面板。

剛剛介紹的Envoy，在Istio中扮演的就是數(shù)據(jù)面板，而其他我們下面將要陸續(xù)介紹的Mixer、Pilot和Auth屬于控制面板。上面我給出了一個(gè)類比：Istio中Envoy (或者說數(shù)據(jù)面板)扮演的角色是底層干活的民工，而該讓這些民工如何工作，由包工頭控制面板來負(fù)責(zé)完成。

在Istio的架構(gòu)中，這兩個(gè)模塊的分工非常的清晰，體現(xiàn)在架構(gòu)上也是經(jīng)緯分明： Mixer，Pilot和Auth這三個(gè)模塊都是Go語言開發(fā)，代碼托管在Github上，三個(gè)倉庫分別是 Istio/mixer, Istio/pilot/auth。而Envoy來自Lyft，編程語言是c++ 11，代碼托管在Github但不是Istio下。從團(tuán)隊(duì)分工看，Google和IBM關(guān)注于控制面板中的Mixer，Pilot和Auth，而Lyft繼續(xù)專注于Envoy。

Istio的這個(gè)架構(gòu)設(shè)計(jì)，將底層Service Mesh的具體實(shí)現(xiàn)，和Istio核心的控制面板拆分開。從而使得Istio可以借助成熟的Envoy快速推出產(chǎn)品，未來如果有更好的Service Mesh方案也方便集成。

Envoy的競爭者

談到這里，聊一下目前市面上Envoy之外的另外一個(gè)Service Mesh成熟產(chǎn)品：基于Scala的Linkerd。 Linkerd的功能和定位和Envoy非常相似，而且就在今年上半年成功進(jìn)入CNCF。而在 Istio 推出之后，Linkerd做了一個(gè)很有意思的動(dòng)作：Linkerd推出了和Istio的集成，實(shí)際為替換Envoy作為Istio的數(shù)據(jù)面板，和Istio的控制面板對接。

回到Istio的架構(gòu)圖，將這幅圖中的Envoy字樣替換為Linkerd即可。另外還有不在圖中表示的Linkerd Ingress / Linkerd Egress用于替代Envoy實(shí)現(xiàn) k8s的Ingress/Egress。

本周最新消息： Nginx推出了自己的服務(wù)網(wǎng)格產(chǎn)品Nginmesh，功能類似，比較有意思的地方是Ngxinmesh一出來就直接宣布要和Istio集成，替換Envoy。

下面開始介紹 Istio 中最核心的控制面板。

Pilot

流量管理

Istio最核心的功能是流量管理，前面我們看到的數(shù)據(jù)面板，由Envoy組成的服務(wù)網(wǎng)格，將整個(gè)服務(wù)間通訊和入口/出口請求都承載于其上。

使用Istio的流量管理模型，本質(zhì)上將流量和基礎(chǔ)設(shè)施擴(kuò)展解耦，讓運(yùn)維人員通過Pilot指定它們希望流量遵循什么規(guī)則，而不是哪些特定的pod/VM應(yīng)該接收流量。

對這段話的理解, 可以看下圖：假定我們原有服務(wù)B，部署在Pod1/2/3上，現(xiàn)在我們部署一個(gè)新版本在Pod4在，希望實(shí)現(xiàn)切5%的流量到新版本。

如果以基礎(chǔ)設(shè)施為基礎(chǔ)實(shí)現(xiàn)上述5%的流量切分，則需要通過某些手段將流量切5%到Pod4這個(gè)特定的部署單位，實(shí)施時(shí)就必須和ServiceB的具體部署還有ServiceA訪問ServiceB的特定方式緊密聯(lián)系在一起. 比如如果兩個(gè)服務(wù)之間是用Nginx做反向代理，則需要增加Pod4的IP作為Upstream，并調(diào)整Pod1/2/3/4的權(quán)重以實(shí)現(xiàn)流量切分。

如果使用Istio的流量管理功能, 由于Envoy組成的服務(wù)網(wǎng)絡(luò)完全在Istio的控制之下,因此要實(shí)現(xiàn)上述的流量拆分非常簡單. 假定原版本為1.0，新版本為2.0，只要通過Polit 給Envoy發(fā)送一個(gè)規(guī)則：2.0版本5%流量，剩下的給1.0。

這種情況下，我們無需關(guān)注2.0版本的部署，也無需改動(dòng)任何技術(shù)設(shè)置, 更不需要在業(yè)務(wù)代碼中為此提供任何配置支持和代碼修改。一切由 Pilot 和智能Envoy代理搞定。

我們還可以玩的更炫一點(diǎn), 比如根據(jù)請求的內(nèi)容來源將流量發(fā)送到特定版本：

后面我們會(huì)介紹如何從請求中提取出User-Agent這樣的屬性來配合規(guī)則進(jìn)行流量控制。

Pilot的功能概述

我們在前面有強(qiáng)調(diào)說，Envoy在其中扮演的負(fù)責(zé)搬磚的民工角色，而指揮Envoy工作的民工頭就是Pilot模塊。

官方文檔中對Pilot的功能描述：

Pilot負(fù)責(zé)收集和驗(yàn)證配置并將其傳播到各種Istio組件。它從Mixer和Envoy中抽取環(huán)境特定的實(shí)現(xiàn)細(xì)節(jié)，為他們提供獨(dú)立于底層平臺(tái)的用戶服務(wù)的抽象表示。此外，流量管理規(guī)則（即通用4層規(guī)則和7層HTTP/gRPC路由規(guī)則）可以在運(yùn)行時(shí)通過Pilot進(jìn)行編程。

每個(gè)Envoy實(shí)例根據(jù)其從Pilot獲得的信息以及其負(fù)載均衡池中的其他實(shí)例的定期健康檢查來維護(hù) 負(fù)載均衡信息，從而允許其在目標(biāo)實(shí)例之間智能分配流量，同時(shí)遵循其指定的路由規(guī)則。

Pilot負(fù)責(zé)在Istio服務(wù)網(wǎng)格中部署的Envoy實(shí)例的生命周期。

Pilot的架構(gòu)

下圖是Pilot的架構(gòu)圖：

• Envoy API負(fù)責(zé)和Envoy的通訊, 主要是發(fā)送服務(wù)發(fā)現(xiàn)信息和流量控制規(guī)則給Envoy
• Envoy提供服務(wù)發(fā)現(xiàn)，負(fù)載均衡池和路由表的動(dòng)態(tài)更新的API。這些API將Istio和Envoy的實(shí)現(xiàn)解耦。(另外，也使得Linkerd之類的其他服務(wù)網(wǎng)絡(luò)實(shí)現(xiàn)得以平滑接管Envoy)
• Polit定了一個(gè)抽象模型，以從特定平臺(tái)細(xì)節(jié)中解耦，為跨平臺(tái)提供基礎(chǔ)
• Platform Adapter則是這個(gè)抽象模型的現(xiàn)實(shí)實(shí)現(xiàn)版本, 用于對接外部的不同平臺(tái)
• 最后是 Rules API，提供接口給外部調(diào)用以管理Pilot，包括命令行工具Istioctl以及未來可能出現(xiàn)的第三方管理界面

服務(wù)規(guī)范和實(shí)現(xiàn)

Pilot架構(gòu)中, 最重要的是Abstract Model和Platform Adapter，我們詳細(xì)介紹。

• Abstract Model：是對服務(wù)網(wǎng)格中”服務(wù)”的規(guī)范表示, 即定義在istio中什么是服務(wù)，這個(gè)規(guī)范獨(dú)立于底層平臺(tái)。
• Platform Adapter：這里有各種平臺(tái)的實(shí)現(xiàn)，目前主要是Kubernetes，另外最新的0.2版本的代碼中出現(xiàn)了Consul和Eureka。?
  來看一下Pilot 0.2的代碼，pilot/platform 目錄下:

瞄一眼platform.go：

服務(wù)規(guī)范的定義在modle/service.go中:

由于篇幅有限，代碼部分這里不深入, 只是通過上面的兩段代碼來展示Pilot中對服務(wù)的規(guī)范定義和目前的幾個(gè)實(shí)現(xiàn)。

暫時(shí)而言(當(dāng)前版本是0.1.6, 0.2版本尚未正式發(fā)布)，目前 Istio 只支持K8s一種服務(wù)發(fā)現(xiàn)機(jī)制。

備注: Consul的實(shí)現(xiàn)據(jù)說主要是為了支持后面將要支持的Cloud Foundry，Eureka沒有找到資料。Etcd3 的支持還在Issue列表中，看Issue記錄爭執(zhí)中。

Pilot功能

基于上述的架構(gòu)設(shè)計(jì)，Pilot提供以下重要功能：

• 請求路由
• 服務(wù)發(fā)現(xiàn)和負(fù)載均衡
• 故障處理
• 故障注入
• 規(guī)則配置?
  由于篇幅限制，今天不逐個(gè)展開詳細(xì)介紹每個(gè)功能的詳情。大家通過名字就大概可以知道是什么，如果希望了解詳情可以關(guān)注之后的分享。或者查閱官方文檔的介紹。

Mixer

Mixer翻譯成中文是混音器, 下面是它的圖標(biāo)：

功能概括：Mixer負(fù)責(zé)在服務(wù)網(wǎng)格上執(zhí)行訪問控制和使用策略，并收集Envoy代理和其他服務(wù)的遙測數(shù)據(jù)。

Mixer的設(shè)計(jì)背景

我們的系統(tǒng)通常會(huì)基于大量的基礎(chǔ)設(shè)施而構(gòu)建，這些基礎(chǔ)設(shè)施的后端服務(wù)為業(yè)務(wù)服務(wù)提供各種支持功能。包括訪問控制系統(tǒng)，遙測捕獲系統(tǒng)，配額執(zhí)行系統(tǒng)，計(jì)費(fèi)系統(tǒng)等。在傳統(tǒng)設(shè)計(jì)中, 服務(wù)直接與這些后端系統(tǒng)集成，容易產(chǎn)生硬耦合。

在Istio中，為了避免應(yīng)用程序的微服務(wù)和基礎(chǔ)設(shè)施的后端服務(wù)之間的耦合，提供了 Mixer 作為兩者的通用中介層：

Mixer 設(shè)計(jì)將策略決策從應(yīng)用層移出并用配置替代，并在運(yùn)維人員控制下。應(yīng)用程序代碼不再將應(yīng)用程序代碼與特定后端集成在一起，而是與Mixer進(jìn)行相當(dāng)簡單的集成，然后 Mixer 負(fù)責(zé)與后端系統(tǒng)連接。

特別提醒: Mixer不是為了在基礎(chǔ)設(shè)施后端之上創(chuàng)建一個(gè)抽象層或者可移植性層。也不是試圖定義一個(gè)通用的Logging API，通用的Metric API，通用的計(jì)費(fèi)API等等。

Mixer的設(shè)計(jì)目標(biāo)是減少業(yè)務(wù)系統(tǒng)的復(fù)雜性，將策略邏輯從業(yè)務(wù)的微服務(wù)的代碼轉(zhuǎn)移到Mixer中, 并且改為讓運(yùn)維人員控制。

Mixer的功能

Mixer 提供三個(gè)核心功能：

• 前提條件檢查。允許服務(wù)在響應(yīng)來自服務(wù)消費(fèi)者的傳入請求之前驗(yàn)證一些前提條件。前提條件包括認(rèn)證，黑白名單，ACL檢查等等。

• 配額管理。使服務(wù)能夠在多個(gè)維度上分配和釋放配額。典型例子如限速。

• 遙測報(bào)告。使服務(wù)能夠上報(bào)日志和監(jiān)控。

在Istio內(nèi)，Envoy重度依賴Mixer。

Mixer的適配器

Mixer是高度模塊化和可擴(kuò)展的組件。其中一個(gè)關(guān)鍵功能是抽象出不同策略和遙測后端系統(tǒng)的細(xì)節(jié)，允許Envoy和基于Istio的服務(wù)與這些后端無關(guān)，從而保持他們的可移植。

Mixer在處理不同基礎(chǔ)設(shè)施后端的靈活性是通過使用通用插件模型實(shí)現(xiàn)的。單個(gè)的插件被稱為適配器，它們允許Mixer與不同的基礎(chǔ)設(shè)施后端連接，這些后臺(tái)可提供核心功能，例如日志，監(jiān)控，配額，ACL檢查等。適配器使Mixer能夠暴露一致的API，與使用的后端無關(guān)。在運(yùn)行時(shí)通過配置確定確切的適配器套件，并且可以輕松指向新的或定制的基礎(chǔ)設(shè)施后端。

這個(gè)圖是官網(wǎng)給的，列出的功能不多，我從Github的代碼中抓個(gè)圖給大家展示一下目前已有的Mixer Adapter：

Mixer的工作方式

Istio使用屬性來控制在服務(wù)網(wǎng)格中運(yùn)行的服務(wù)的運(yùn)行時(shí)行為。屬性是描述入口和出口流量的有名稱和類型的元數(shù)據(jù)片段，以及此流量發(fā)生的環(huán)境。Istio屬性攜帶特定信息片段，例如：

請求處理過程中，屬性由Envoy收集并發(fā)送給Mixer，Mixer中根據(jù)運(yùn)維人員設(shè)置的配置來處理屬性。基于這些屬性，Mixer會(huì)產(chǎn)生對各種基礎(chǔ)設(shè)施后端的調(diào)用。?

Mixer設(shè)計(jì)有一套強(qiáng)大(也很復(fù)雜, 堪稱Istio中最復(fù)雜的一個(gè)部分)的配置模型來配置適配器的工作方式，設(shè)計(jì)有適配器、切面、屬性表達(dá)式，選擇器、描述符，manifests 等一堆概念.

由于篇幅所限，今天不展開這塊內(nèi)容，這里給出兩個(gè)簡單的例子讓大家對Mixer的配置有個(gè)感性的認(rèn)識(shí):

1、這是一個(gè)IP地址檢查的Adapter，實(shí)現(xiàn)類似黑名單或者白名單的功能：?

2、metrics的適配器,將數(shù)據(jù)報(bào)告給Prometheus系統(tǒng)?

3、定義切面, 使用前面定義的 myListChecker 這個(gè)adapter 對屬性 source.ip 進(jìn)行黑名單檢查。

Istio-Auth

Istio-Auth提供強(qiáng)大的服務(wù)到服務(wù)和終端用戶認(rèn)證，使用交互TLS，內(nèi)置身份和憑據(jù)管理。它可用于升級(jí)服務(wù)網(wǎng)格中的未加密流量，并為運(yùn)維人員提供基于服務(wù)身份而不是網(wǎng)絡(luò)控制實(shí)施策略的能力。

Istio的未來版本將增加細(xì)粒度的訪問控制和審計(jì)，以使用各種訪問控制機(jī)制（包括基于屬性和角色的訪問控制以及授權(quán)鉤子）來控制和監(jiān)視訪問您的服務(wù)，API或資源的人員。

Auth的架構(gòu)

下圖展示Istio Auth架構(gòu)，其中包括三個(gè)組件：身份，密鑰管理和通信安全。

在這個(gè)例子中, 服務(wù)A以服務(wù)帳戶“foo”運(yùn)行, 服務(wù)B以服務(wù)帳戶“bar”運(yùn)行, 他們之間的通訊原來是沒有加密的. 但是Istio在不修改代碼的情況, 依托Envoy形成的服務(wù)網(wǎng)格, 直接在客戶端Envoy和服務(wù)器端Envoy之間進(jìn)行通訊加密。

目前在Kubernetes上運(yùn)行的 Istio，使用Kubernetes service account/服務(wù)帳戶來識(shí)別運(yùn)行該服務(wù)的人員。

未來將推出的功能

Auth在目前的Istio版本(0.1.6和即將發(fā)布的0.2)中，功能還不是很全，未來則規(guī)劃有非常多的特性：

• 細(xì)粒度授權(quán)和審核
• 安全I(xiàn)stio組件（Mixer, Pilot等）
• 集群間服務(wù)到服務(wù)認(rèn)證
• 使用JWT/OAuth2/OpenID_Connect終端到服務(wù)的認(rèn)證
• 支持GCP服務(wù)帳戶和AWS服務(wù)帳戶
• 非http流量（MySql，Redis等）支持
• Unix域套接字，用于服務(wù)和Envoy之間的本地通信
• 中間代理支持
• 可插拔密鑰管理組件
• 需要提醒的是：這些功能都是不改動(dòng)業(yè)務(wù)應(yīng)用代碼的前提下實(shí)現(xiàn)的。

回到我們前面的曾經(jīng)討論的問題，如果自己來做，完成這些功能大家覺得需要多少工作量？要把所有的業(yè)務(wù)模塊都遷移到具備這些功能的框架和體系中，需要改動(dòng)多少？而Istio，未來就會(huì)直接將這些東西擺上我們的餐桌。

三、未來

前面我們介紹了Istio的基本情況，還有Istio的架構(gòu)和主要組件。相信大家對Istio應(yīng)該有了一個(gè)初步的認(rèn)識(shí)。需要提醒的是，Istio是一個(gè)今年5月才發(fā)布 0.1.0 版本的新鮮出爐的開源項(xiàng)目，目前該項(xiàng)目也才發(fā)布到0.1.6正式版本和 0.2.2 pre release版本. 很多地方還不完善，希望大家可以理解，有點(diǎn)類似于最早期階段的Kubernetes。在接下來的時(shí)間，我們將簡單介紹一下Istio后面的一些開發(fā)計(jì)劃和發(fā)展預(yù)期。

運(yùn)行環(huán)境支持

Istio目前只支持Kubernetes, 這是令人比較遺憾的一點(diǎn). 不過 istio 給出的解釋是istio未來會(huì)支持在各種環(huán)境中運(yùn)行，只是目前在 0.1/0.2 這樣的初始階段暫時(shí)專注于Kubernetes，但很快會(huì)支持其他環(huán)境。

注意: Kubernetes平臺(tái)，除了原生Kubernetes, 還有諸如 IBM Bluemix Container Service和RedHat OpenShift這樣的商業(yè)平臺(tái)。 以及google自家的 Google Container Engine。這是自家的東西, 而且現(xiàn)在k8s/istio/gRPC都已經(jīng)被劃歸到 Google cloud platform部門, 自然會(huì)優(yōu)先支持.

另外isito所說的其他環(huán)境指的是:

• Mesos: 這個(gè)估計(jì)是大多人非K8s的Docker使用者最關(guān)心的了, 暫時(shí)從Github上的代碼中未見到有開工跡象, 但是Istio的文檔和官方聲明都明顯說會(huì)支持, 估計(jì)還是希望很大的.?
  Cloud foundry: 這個(gè)東東我們國內(nèi)除了私有云外玩的不多, Istio對它的支持似乎已經(jīng)啟動(dòng). 比如我看到代碼中已經(jīng)有了Consul這個(gè)服務(wù)注冊的支持, 從Issue討論上看到是說為上Cloud foundry做準(zhǔn)備, 因?yàn)镃loud foundry沒有k8s那樣的原生服務(wù)注冊機(jī)制。
• VM: 這塊沒有看到介紹, 但是有看到Istio的討論中提到會(huì)支持容器和非容器的混合(Hybrid)支持

值得特別指出的是，目前我還沒有看到Istio有對Docker家的Swarm有支持的計(jì)劃或者討論, 目前我找到的任何Istio的資料中都不存在Swarm這個(gè)東東。我只能不負(fù)責(zé)任的解讀為：有人的地方就有江湖，有江湖就自然會(huì)有江湖恩怨。

路線圖

按照Istio的說法，他們計(jì)劃每3個(gè)月發(fā)布一次新版本，我們看一下目前得到的一些信息：

• 0.1 版本2017年5月發(fā)布,只支持Kubernetes
• 0.2 即將發(fā)布,當(dāng)前是0.2.1 pre-release, 也只支持Kubernetes
• 0.3 roadmap上說要支持k8s之外的平臺(tái), “Support for Istio meshes without Kubernetes.”, 但是具體哪些特性會(huì)放在0.3中,還在討論中
• 1.0 版本預(yù)計(jì)今年年底發(fā)布?
  注: 1.0版本的發(fā)布時(shí)間官方?jīng)]有明確給出，我只是看到官網(wǎng)資料里面有信息透露如下:

“we invite the community to join us in shaping the project as we work toward a 1.0 release later this year.”?
按照上面給的信息，簡單推算：應(yīng)該是9月發(fā)0.2, 然后12月發(fā)0.3, 但是這就已經(jīng)是年底了, 所以不排除1.0推遲發(fā)布的可能，或者0.3直接當(dāng)成 1.0 發(fā)布。

社區(qū)支持

雖然Istio初出江湖，乳臭未干，但是憑借google和IBM的金字招牌，還有Istio前衛(wèi)而實(shí)際的設(shè)計(jì)理念，目前已經(jīng)有很多公司在開始提供對Istio的支持或者集成，這是Istio官方頁面有記載的：

• Red Hat：Openshift and OpenShift Application Runtimes
• Pivotal：Cloud Foundry
• Weaveworks：Weave Cloud and Weave Net 2.0
• Tigera：Project Calico Network Policy Engine

• Datawire：Ambassador project?
  然后一些其他外圍支持, 從代碼中看到的:

• eureka

• consul
• etcd v3: 這個(gè)還在爭執(zhí)中,作為etcd的堅(jiān)定擁護(hù)者, 我對此保持密切關(guān)注

存在問題

Istio畢竟目前才是0.2.2 pre release版本，畢竟才出來四個(gè)月，因此還是存在大量的問題，集中表現(xiàn)為：

• 只支持k8s，而且要求k8s 1.7.4+，因?yàn)槭褂玫絢8s的 CustomResourceDefinitions
• 性能較低，從目前的測試情況看，0.1版本很糟糕，0.2版本有改善
• 很多功能尚未完成?
  給大家的建議：可以密切關(guān)注Istio的動(dòng)向，提前做好技術(shù)儲(chǔ)備。但是，最起碼在年底的1.0版本出來之前，別急著上生產(chǎn)環(huán)境。

結(jié)語

感謝大家在今天參與這次的Istio分享，由于時(shí)間有限，很多細(xì)節(jié)無法在今天給大家盡情展開。如果大家對 Istio 感興趣，可以之后自行瀏覽 Istio 的官方網(wǎng)站，我也預(yù)期會(huì)在之后陸陸續(xù)續(xù)的給出Istio相關(guān)的文章和分享。

總結(jié)

以上是生活随笔為你收集整理的深度剖析Service Mesh服务网格新生代Istio的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。