剖析Service Mesh-服務網格新生代 Istio

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”， 翻譯為中文是“啟航”。它的圖標如下:

image

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

image

後面會看到，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兩個面板的功能和合作：

image

以下分別介紹 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：

image

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

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

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

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

Pilot功能

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

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

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後面的一些開發計劃和發展預期。

閱讀更多 隨一暢想 的文章

關鍵字: IBM 新生代 通信