原來使用的istio對應的版本為0.8，還只是在kubernetes沒有落地的環境下使用，可以解決現在微服務框架下的服務註冊與發現、身份驗證與授權，熔斷（過載保護），降級，流量控制等功能。

有人說“有了ISTIO，你的服務就不再需要任務微服務開發框架（springcloud ,dubbo的框架對服務治理，需要自己手動寫程式處理）了！”

現在已釋出了istio v1.0版本，並且官方說可以直接使用於生產環境，又基於我使用的是kubernetes環境，並且一直以為它是對kubernetes支援最好的，真是欣喜甚慰！

istio = 微服務框架 + 服務治理

istio的關鍵特性：

• HTTP/1.1,HTTP/2,gRPC和TCP流量的自動區域感知和故障切換；
• 路由規則豐富，容錯和故障注入，對流行為提供細粒度控制；
• 支援訪問控制，速率限制和配額的可插拔和配置API；
• 叢集內所有流量的自動量度，日誌和跟蹤，包括 叢集INGRESS和ENGRESS;
• 安全的服務到服務身份驗證；

沒有service mesh前，微服務對運維帶來了什麼？

解耦的各個服務，可能多達幾十上百個，怎麼管理各個服務之間的連線，部署，版本控制，安全，故障轉移，微略執行，遙測和和監控等，更不說常見的A/B測試。金絲雀釋出 ，限流，訪問控制，端對端認證。

痛點：

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

service mesh是基礎設施層，輕量級高效能網路代理，對應用透明。

然，Istio也可以視為是一種服務網格。

• 資料面板由一組智慧代理（Envoy）組成，代理部署為邊車（sidecar），調解和控制微服務之間所有的網路通訊。
• 控制面板負責管理和配置代理來路由流量，以及在執行時執行策略。

istio的架構圖如下：

它讓開發專注於業務邏輯的處理和實現！

關於對envoy,pilot,mixer,auth的各個模組的介紹，可去數人云瞭解。