萬字解讀:Service Mesh服務網格新生代--Istio

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

講師簡介：

敖小劍，十五年軟件開發經驗，微服務專家，專一於基礎架構，cloud native擁護者，敏捷實踐者。曾在亞信，愛立信，惟品會和ppmoney任職, 現任數人云資深架構師。

如下內容爲敖小劍在9月21號晚上進行的線上分享實錄。

今天的主角名叫 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作了一個頗有意思的動做：Istio推出了和Istio的集成，實際爲替換Envoy做爲Istio的數據面板，和Istio的控制面板對接。

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

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

繼續八卦：一出小三上位原配出局的狗血劇情貌似正在醞釀中。 結局如何我等不妨拭目以待，仍是那句話: 沒有挖不倒的牆角，只有不努力的小三! Linkerd，Nginmesh，加油！

下面開始介紹 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的架構圖：

1. Envoy API負責和Envoy的通信, 主要是發送服務發現信息和流量控制規則給Envoy
2. Envoy提供服務發現，負載均衡池和路由表的動態更新的API。這些API將Istio和Envoy的實現解耦。(另外，也使得Linkerd之類的其餘服務網絡實現得以平滑接管Envoy)
3. Polit定了一個抽象模型，以從特定平臺細節中解耦，爲跨平臺提供基礎
4. Platform Adapter則是這個抽象模型的現實實現版本, 用於對接外部的不一樣平臺
5. 最後是 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，實現相似黑名單或者白名單的功能：

1. 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版本，畢竟纔出來四個月，所以仍是存在大量的問題，集中表現爲：

1. 只支持k8s，並且要求k8s 1.7.4+，由於使用到k8s的 CustomResourceDefinitions
2. 性能較低，從目前的測試狀況看，0.1版本很糟糕，0.2版本有改善
3. 不少功能還沒有完成
   給你們的建議：能夠密切關注Istio的動向，提早作好技術儲備。可是，最起碼在年末的1.0版本出來以前，別急着上生產環境。

結語

感謝你們在今天參與此次的Istio分享，因爲時間有限，不少細節沒法在今天給你們盡情展開。若是你們對 Istio 感興趣，能夠以後自行瀏覽 Istio 的官方網站，我也預期會在以後陸陸續續的給出Istio相關的文章和分享。

最後推薦給你們幾個資料：

1. Istio的中文資料: Istio.doczh.cn, 這是目前我和其餘社區朋友正在一塊兒翻譯的Istio官方文檔, 進度大概30%左右, 其中最適合入門瞭解的 concept 部分已經翻譯完成.做爲目前市面上惟一的一份Istio中文資料，推薦給你們閱讀。
2. Service Mesh的微信技術羣，因爲服務網格的內容實在太新，不容易找到人交流，因此若是對這個技術有興趣打算深刻研究的，歡迎加入。請聯繫個人微信：id(aoxiaojian80)加羣，請備註服務網格。今天的分享到此結束，感謝你們的全程參與，下次再會！