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

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

今天的主角名叫 Istio，估計很多同學在此之前可能完全沒有聽過這個名字。請不必介意，沒聽過很正常，因為Istio的確是一個非常新的東西，出世也才四個月而已。

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

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

一、介紹

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

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

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

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

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

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

名字和圖標：

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

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

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

主要特性：

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

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

為什么要使用Istio

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

微服務(wù)的兩面性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Istio能做什么?

Istio力圖解決前面列出的微服務(wù)實施后需要面對的問題。Istio 首先是一個服務(wù)網(wǎng)絡(luò)，但是Istio又不僅僅是服務(wù)網(wǎng)格: 在 Linkerd， Envoy 這樣的典型服務(wù)網(wǎng)格之上，Istio提供了一個完整的解決方案，為整個服務(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ì)和流向，從而提供快速識別問題的能力。

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

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

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

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

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

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

Istio的真正價值

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

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

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

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

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

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

Istio 超越 spring cloud和dubbo 等傳統(tǒng)開發(fā)框架之處， 就在于不僅僅帶來了遠超這些框架所能提供的功能， 而且也不需要應(yīng)用程序為此做大量的改動， 開發(fā)人員也不必為上面的功能實現(xiàn)進行大量的知識儲備。

總結(jié):

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

開發(fā)團隊

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

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

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

Google

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

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

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

IBM

IBM的團隊同來來自IBM云平臺, IBM的貢獻是:

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

Lyft

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

最后， 在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ò)通信。

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

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

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

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

Envory

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

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

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

Envoy實現(xiàn)了過濾和路由、服務(wù)發(fā)現(xiàn)、健康檢查，提供了具有彈性的負載均衡。它在安全上支持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)信息

• 過濾

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

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

• Metrics

• Logging

• Distribution Trace: 目前支持 Zipkin

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

Istio架構(gòu)回顧

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

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

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

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

Envoy的競爭者

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

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

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

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

Pilot

流量管理

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

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

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

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

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

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

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

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

Pilot的功能概述

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

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

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

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

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

Pilot的架構(gòu)

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

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

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

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

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

瞄一眼platform.go：

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

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

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

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

Pilot功能

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

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

Mixer

Mixer翻譯成中文是混音器, 下面是它的圖標：

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

Mixer的設(shè)計背景

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

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

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

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

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

Mixer的功能

Mixer 提供三個核心功能：

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

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

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

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

Mixer的適配器

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

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

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

Mixer的工作方式

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

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

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

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

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

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

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

Istio-Auth

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

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

Auth的架構(gòu)

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

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

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

未來將推出的功能

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

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

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

三、未來

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

運行環(huán)境支持

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

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

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

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

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

路線圖

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

• 0.1 版本2017年5月發(fā)布,只支持Kubernetes
• 0.2 即將發(fā)布,當前是0.2.1 pre-release, 也只支持Kubernetes
• 0.3 roadmap上說要支持k8s之外的平臺, “Support for Istio meshes without Kubernetes.”, 但是具體哪些特性會放在0.3中,還在討論中
• 1.0 版本預計今年年底發(fā)布?
  注: 1.0版本的發(fā)布時間官方?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直接當成 1.0 發(fā)布。

社區(qū)支持

雖然Istio初出江湖，乳臭未干，但是憑借google和IBM的金字招牌，還有Istio前衛(wèi)而實際的設(shè)計理念，目前已經(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: 這個還在爭執(zhí)中,作為etcd的堅定擁護者, 我對此保持密切關(guān)注

存在問題

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

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

結(jié)語

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

總結(jié)

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

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