作者簡介：敖小劍，十五年軟件開發經驗，微服務專家，專注于基礎架構，Cloud Native擁護者，敏捷實踐者。曾在亞信、愛立信、唯品會和ppmoney任職, 現任數人云資深架構師，本文由數人云獨家授權發布，歡迎加作者微信（aoxiaojian80）交流。

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

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

今天的內容將會分成三個部分:

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

一、介紹

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

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

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

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

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

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

名字和圖標：

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

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

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

主要特性：

Istio的關鍵功能:

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

為什么要使用Istio

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

微服務的兩面性

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

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

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

開發人員和運維人員在單體應用程序向分布式微服務架構的轉型中， 不得不面臨上述挑戰。

服務網格

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

什么是Service Mesh（服務網格）？

Service Mesh是專用的基礎設施層，輕量級高性能網絡代理。提供安全的、快速的、可靠地服務間通訊，與實際應用部署一起，但對應用透明。

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

圖中應用作為服務的發起方，只需要用最簡單的方式將請求發送給本地的服務網格代理，然后網格代理會進行后續的操作，如服務發現，負載均衡，最后將請求轉發給目標服務。當有大量服務相互調用時，它們之間的服務調用關系就會形成網格，如下圖所示：

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

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

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

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

Istio能做什么?

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

Istio在服務網絡中統一提供了許多關鍵功能(以下內容來自官方文檔)：

• 流量管理：控制服務之間的流量和API調用的流向，使得調用更可靠，并使網絡在惡劣情況下更加健壯。

• 可觀察性：了解服務之間的依賴關系，以及它們之間流量的本質和流向，從而提供快速識別問題的能力。

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

• 服務身份和安全：為網格中的服務提供可驗證身份，并提供保護服務流量的能力，使其可以在不同可信度的網絡上流轉。

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

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

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

這些功能極大的減少了應用程序代碼，底層平臺和策略之間的耦合，使微服務更容易實現。

Istio的真正價值

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

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

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

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

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

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

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

總結:

Istio 大幅降低微服務架構下應用程序的開發難度，勢必極大的推動微服務的普及。個人樂觀估計，隨著isito的成熟，微服務開發領域將迎來一次顛覆性的變革。后面我們在介紹Istio的架構和功能模塊時, 大家可以了解到Istio是如何做到這些的。

開發團隊

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

基于我們為內部和企業客戶構建和運營大規模微服務的常見經驗，Google，IBM和Lyft聯手創建Istio，希望為微服務開發和維護提供可靠的基礎。Google和IBM相信不需要介紹了, 在Istio項目中這兩個公司是絕對主力，舉個例子,下圖是 Istio Working Group的成員列表：

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

Google

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

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

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

IBM

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

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

Lyft

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

最后， 在Isito的介紹完成之后, 我們開始下一節內容，Istio的架構。

二、架構

整體架構

Istio服務網格邏輯上分為數據面板和控制面板。

數據面板由一組智能代理（Envoy）組成，代理部署為邊車，調解和控制微服務之間所有的網絡通信。

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

下圖為Istio的架構詳細分解圖：

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

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

Envory

以下介紹內容來自Istio官方文檔：

Istio 使用Envoy代理的擴展版本，Envoy是以C++開發的高性能代理，用于調解服務網格中所有服務的所有入站和出站流量。

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

Envoy實現了過濾和路由、服務發現、健康檢查，提供了具有彈性的負載均衡。它在安全上支持TLS，在通信方面支持gRPC。

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

• HTTP／1.1
• HTTP/2
• gRPC

• TCP?
  以及網絡通訊直接相關的功能：

• 服務發現：從Pilot得到服務發現信息

• 過濾

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

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

• Metrics

• Logging

• Distribution Trace: 目前支持 Zipkin

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

Istio架構回顧

在繼續介紹Istio其他的模塊之前，我們來回顧一下Istio的架構，前面我們提到, Istio服務網格分為兩大塊：數據面板和控制面板。

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

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

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

Envoy的競爭者

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

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

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

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

Pilot

流量管理

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

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

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

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

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

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

我們還可以玩的更炫一點, 比如根據請求的內容來源將流量發送到特定版本：

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

Pilot的功能概述

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

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

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

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

Pilot負責在Istio服務網格中部署的Envoy實例的生命周期。

Pilot的架構

下圖是Pilot的架構圖：

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

服務規范和實現

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

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

瞄一眼platform.go：

服務規范的定義在modle/service.go中:

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

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

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

Pilot功能

基于上述的架構設計，Pilot提供以下重要功能：

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

Mixer

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

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

Mixer的設計背景

我們的系統通常會基于大量的基礎設施而構建，這些基礎設施的后端服務為業務服務提供各種支持功能。包括訪問控制系統，遙測捕獲系統，配額執行系統，計費系統等。在傳統設計中, 服務直接與這些后端系統集成，容易產生硬耦合。

在Istio中，為了避免應用程序的微服務和基礎設施的后端服務之間的耦合，提供了 Mixer 作為兩者的通用中介層：

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

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

Mixer的設計目標是減少業務系統的復雜性，將策略邏輯從業務的微服務的代碼轉移到Mixer中, 并且改為讓運維人員控制。

Mixer的功能

Mixer 提供三個核心功能：

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

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

• 遙測報告。使服務能夠上報日志和監控。

在Istio內，Envoy重度依賴Mixer。

Mixer的適配器

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

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

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

Mixer的工作方式

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

請求處理過程中，屬性由Envoy收集并發送給Mixer，Mixer中根據運維人員設置的配置來處理屬性。基于這些屬性，Mixer會產生對各種基礎設施后端的調用。?

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

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

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

2、metrics的適配器,將數據報告給Prometheus系統?

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

Istio-Auth

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

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

Auth的架構

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

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

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

未來將推出的功能

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

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

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

三、未來

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

運行環境支持

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

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

另外isito所說的其他環境指的是:

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

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

路線圖

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

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

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

社區支持

雖然Istio初出江湖，乳臭未干，但是憑借google和IBM的金字招牌，還有Istio前衛而實際的設計理念，目前已經有很多公司在開始提供對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: 這個還在爭執中,作為etcd的堅定擁護者, 我對此保持密切關注

存在問題

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

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

結語

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。