Istio與服務網格
業界比較認同的是William Morgan關於服務網格（Service Mesh）的一段定義，這裏提取和解釋該定義中的幾個關鍵字來講解服務網格的特點。
◎ 基礎設施：服務網格是一種處理服務間通信的基礎設施層。
◎ 雲原生：服務網格尤其適用於在雲原生場景下幫助應用程序在複雜的服務拓撲間可靠地傳遞請求。
◎ 網絡代理：在實際使用中，服務網格一般是通過一組輕量級網絡代理來執行治理邏輯的。
◎ 對應用透明：輕量網絡代理與應用程序部署在一起，但應用感知不到代理的存在，還是使用原來的方式工作。
經典的服務網格示意圖如圖1-8所示。
圖1-8 經典的服務網格示意圖
時代選擇服務網格
在雲原生時代，隨着採用各種語言開發的服務劇增，應用間的訪問拓撲更加複雜，治理需求也越來越多。原來的那種嵌入在應用中的治理功能無論是從形態、動態性還是可擴展性來說都不能滿足需求，迫切需要一種具備雲原生動態、彈性特點的應用治理基礎設施。
首先，從單個應用來看，Sidecar與應用進程的解耦帶來的應用完全無侵入、開發語言無關等特點解除了開發語言的約束，從而極大降低了應用開發者的開發成本。這種方式也經常被稱爲一種應用的基礎設施層，類比TCP/IP網絡協議棧，應用程序像使用TCP/IP一樣使用這個通用代理：TCP/IP 負責將字節碼可靠地在網絡節點間傳遞，Sidecar 則負責將請求可靠地在服務間進行傳遞。TCP/IP 面向的是底層的數據流，Sidecar 則可以支持多種高級協議（HTTP、gRPC、HTTPS 等），以及對服務運行時進行高級控制，使服務變得可監控、可管理。
然後，從全局來看，在多個服務間有複雜的互相訪問時纔有服務治理的需求。即我們關注的是這些 Sidecar 組成的網格，對網格內的服務間訪問進行管理，應用還是按照本來的方式進行互相訪問，每個應用程序的Inbound流量和Outbound流量都要經過Sidecar代理，並在Sidecar上執行治理動作。
最後，Sidecar是網格動作的執行體，全局的管理規則和網格內的元數據維護通過一個統一的控制面實現，如圖 1-9 所示，只有數據面的 Sidecar 和控制面有聯繫，應用感知不到Sidecar，更不會和控制面有任何聯繫，用戶的業務和控制面徹底解耦。
圖1-9 服務網格的統一控制面
當然，正所謂沒有免費的午餐，這種形態在服務的訪問鏈路上多引入的兩跳也是不容迴避的問題。
如圖1-10所示，從forecast服務到recommendation服務的一個訪問必須要經過forecast服務的 Sidecar攔截 Outbound流量執行治理動作；再經過 recommendation服務的 Sidecar攔截Inbound流量，執行治理動作。這就引入兩個問題：
◎ 增加了兩處延遲和可能的故障點；
◎ 多出來的這兩跳對於訪問性能、整體可靠性及整個系統的複雜度都帶來了新的挑戰。
圖1-10 服務網格訪問路徑變長
其中，後者本來就屬於基礎設施層面可維護性、可靠性的範疇，業界的幾個產品都用各自的方式在保證。而前者引入的性能和資源損耗，網格提供商提供的方案一般是這樣解決的：通過保證轉發代理的輕量和高性能降低時延影響，尤其是考慮到後端實際使用的應用程序一般比代理更重，疊加代理並不會明顯影響應用的訪問性能；另外，對於這些高性能的代理，只要消耗足夠的資源總能達到期望的性能，特別是雲原生場景下服務的彈性特點使得服務實例的彈性擴展變得非常方便，通過擴展實例數量總是能得到期望的訪問性能。
所以，對於考慮使用服務網格的用戶來說，事情就會變成一個更簡單的選擇題：是否願意花費額外的資源在這些基礎設施上來換取開發、運維的靈活性、業務的非侵入性和擴展性等便利。相信，在這個計算資源越來越便宜、聰明的程序員越來越貴的時代，對於把程序員從機械的基礎設施就可以搞定的繁雜事務中解放出來，使其專注於更能發揮聰明才智和產生巨大商業價值的業務開發上，我們很容易做出判斷。
目前，華爲、谷歌、亞馬遜等雲服務廠商將這種服務以雲服務形態提供了出來，並和底層的基礎設施相結合，提供了完整的服務治理解決方案。這對於廣大應用開發者來說，更加方便和友好。
服務網格選擇Istio
在多種服務網格項目和產品中，最引人注目的是後來居上的 Istio，它有希望成爲繼Kubernetes之後的又一款重量級產品。
Istio從2017年5月發佈第1個版本0.1開始就被廣泛關注。據Istio官方稱，Istio 1.1解決了生產大規模集羣的性能、資源利用率和可靠性問題，提供了衆多生產中實際應用的新特性，已經達到企業級可用的標準。
首先，在控制面上，Istio作爲一種全新的設計，在功能、形態、架構和擴展性上提供了遠超服務網格的能力範圍。它基於xDS協議提供了一套標準的控制面規範，向數據面傳遞服務信息和治理規則。Istio的早期版本使用Envoy V1版本的API，即Restful方式，其新版本使用Envoy V2版本的API，即gRPC協議。標準的控制面API解耦了控制面和數據面的綁定。Nginx的nginMesh、F5 Networks的Aspen Mesh等多種數據面代理支持Istio的控制面，甚至有些老牌微服務SDK也開始往Istio上集成，雖然其本身的功能定位和功能集合有些“不對齊”，但至少說明了Istio控制面的影響力和認同程度。
然後，在數據面的競爭上，Istio的標準數據面Envoy是由Lyft內部於2016年開發的，比 Linkerd更早。2016年9月，Envoy開源併發布了 1.0.0版本；2017年 9月，Envoy加入CNCF，成爲第2個Service Mesh項目；2018年11月，Envoy從CNCF畢業，這標誌着其趨於成熟。從開發語言上看，Envoy是使用C++開發的，其性能和資源佔用比用Rust開發的 Linkerd Proxy 要更好，更能滿足服務網格中對透明代理的輕量高性能要求；從能力上看，Envoy提供L3/L4過濾器、HTTP L7過濾器，支持HTTP/2、HTTP L7路由及gRPC、MongoDB、DynamoDB等協議，有服務發現、健康檢查、高級LB、前端代理等能力，具有極好的可觀察性、動態配置功能；從架構實現上看，Envoy是一個可高度定製化的程序，通過 Filter機制提供了高度擴展性，還支持熱重啓，其代碼基於模塊化編碼，易於測試。除了在Istio中應用，Envoy在其他Service Mesh框架中也被廣泛應用，漸漸成爲Service Mesh的數據平面標準。
最後，在大廠的支持上，Istio 由谷歌和 IBM 共同推出，從應用場景的分析規劃到本身的定位，從自身架構的設計到與周邊生態的結合，都有着比較嚴密的論證。Istio項目在發起時已經確認了將雲原生生態系統中的容器作爲核心打包和運行時，將Kubernetes作爲管理容器的編排系統，需要一個系統管理在容器平臺上運行的服務之間的交互，包括控制訪問、安全、運行數據收集等，而 Istio 正是爲此而生的；另外，Istio 成爲架構的默認部分，就像容器和Kubernetes已經成爲雲原生架構的默認部分一樣。
雲原生社區的定位與多個雲廠商的規劃也不謀而合。華爲雲已經在 2018 年 8 月率先在其容器服務CCE（Cloud Container Engine）中內置Istio；Google的GKE也在2018年12月宣佈內置 Istio；越來越多的雲廠商也已經選擇將 Istio作爲其容器平臺的一部分提供給用戶，即提供一套開箱即用的容器應用運行治理的全棧服務。正因爲看到了 Istio 在技術和產品上的巨大潛力，各大廠商在社區的投入也在不斷加大，其中包括Google、IBM、華爲、VMware、思科、紅帽等主流廠商。
Istio與Kubernetes
Kubernetes是一款用於管理容器化工作負載和服務的可移植、可擴展的開源平臺，擁有龐大、快速發展的生態系統，它面向基礎設施，將計算、網絡、存儲等資源進行緊密整合，爲容器提供最佳運行環境，並面向應用提供封裝好的、易用的工作負載與服務編排接口，以及運維所需的資源規格、彈性、運行參數、調度等配置管理接口，是新一代的雲原生基礎設施平臺。
從平臺架構而言，Kubernetes的設計圍繞平臺化理念，強調插件化設計與易擴展性，這是它與其他同類系統的最大區別之一，保障了對各種不同客戶應用場景的普遍適應性。另外，Kubernetes與其他容器編排系統的顯著區別是Kubernetes並不把無狀態化、微服務化等條件作爲在其上可運行的工作負載的約束。
如今，容器技術已經進入產業落地期，而Kubernetes作爲容器平臺的標準已經得到了廣泛應用。Kubernetes從2014年6月由Google宣佈開源，到2015年7月發佈1.0這個正式版本並進入CNCF基金會，再到2018年3月從CNCF基金會正式畢業，迅速成爲容器編排領域的標準，是開源歷史上發展最快的項目之一，如圖1-12所示。
圖1-12 Kubernetes的發展歷史
Istio,Kubernetes的好幫手
從場景來看，Kubernetes已經提供了非常強大的應用負載的部署、升級、擴容等運行管理能力。Kubernetes 中的 Service 機制也已經可以做服務註冊、服務發現和負載均衡，支持通過服務名訪問到服務實例。
從微服務的工具集觀點來看，Kubernetes本身是支持微服務的架構，在Pod中部署微服務很合適，也已經解決了微服務的互訪互通問題，但對服務間訪問的管理如服務的熔斷、限流、動態路由、調用鏈追蹤等都不在Kubernetes的能力範圍內。那麼，如何提供一套從底層的負載部署運行到上層的服務訪問治理端到端的解決方案？目前，最完美的答案就是在Kubernetes上疊加Istio這個好幫手，如圖1-13所示。
圖1-13 在Kubernetes上疊加Istio這個好幫手
Kubernetes的Service基於每個節點的Kube-proxy從Kube-apiserver上獲取Service和Endpoint 的信息，並將對 Service 的請求經過負載均衡轉發到對應的 Endpoint 上。但Kubernetes只提供了4層負載均衡能力，無法基於應用層的信息進行負載均衡，更不會提供應用層的流量管理，在服務運行管理上也只提供了基本的探針機制，並不提供服務訪問指標和調用鏈追蹤這種應用的服務運行診斷能力。
Istio複用了Kubernetes Service的定義，在實現上進行了更細粒度的控制。Istio的服務發現就是從 Kube-apiserver中獲取 Service和 Endpoint，然後將其轉換成 Istio服務模型的 Service 和 ServiceInstance，但是其數據面組件不再是 Kube-proxy，而是在每個 Pod 裏部署的 Sidecar，也可以將其看作每個服務實例的 Proxy。這樣，Proxy 的粒度就更細了，和服務實例的聯繫也更緊密了，可以做更多更細粒度的服務治理，如圖 1-14 所示。通過攔截Pod的Inbound流量和Outbound流量，並在Sidecar上解析各種應用層協議，Istio可以提供真正的應用層治理、監控和安全等能力。
總之，Istio和Kubernetes從設計理念、使用體驗、系統架構甚至代碼風格等小細節來看，關係都非常緊密，甚至有人認爲 Istio 就是 Kubernetes團隊開發的 Kubernetes可插拔的增強特性。
圖1-14 更細粒度的Proxy提供更多更細粒度的能力
Kubernetes,Istio的好基座
Istio最大化地利用了Kubernetes這個基礎設施，與之疊加在一起形成了一個更強大的用於進行服務運行和治理的基礎設施，並提供了更透明的用戶體驗。
1.數據面
數據面Sidecar運行在Kubernetes的Pod裏，作爲一個Proxy和業務容器部署在一起。在服務網格的定義中要求應用程序在運行的時候感知不到Sidecar的存在。而基於Kubernetes的一個 Pod 多個容器的優秀設計使得部署運維對用戶透明，用戶甚至感知不到部署 Sidecar的過程。用戶還是用原有的方式創建負載，通過 Istio 的自動注入服務，可以自動給指定的負載注入Proxy。如果在另一種環境下部署和使用Proxy，則不會有這樣的便利。
2.統一服務發現
Istio的服務發現機制非常完美地基於Kubernetes的域名訪問機制構建而成，省去了再搭一個類似 Eureka 的註冊中心的麻煩，更避免了在 Kubernetes 上運行時服務發現數據不一致的問題。
儘管 Istio 強調自己的可擴展性的重要性在於適配各種不同的平臺，也可以對接其他服務發現機制，但在實際場景下，通過深入分析 Istio 幾個版本的代碼和設計，便可以發現其重要的能力都是基於Kubernetes進行構建的。
3.基於Kubernetes CRE描述規則
Istio的所有路由規則和控制策略都是通過 Kubernetes CRD實現的，因此各種規則策略對應的數據也被存儲在 Kube-apiserver 中，不需要另外一個單獨的 APIServer 和後端的配置管理。所以，可以說Istio的APIServer就是Kubernetes的APIServer，數據也自然地被存在了對應Kubernetes的etcd中。
Istio非常巧妙地應用了Kubernetes這個好基座，基於Kubernetes的已有能力來構建自身功能。Kubernetes裏已經有的，絕不再自己搞一套，避免了數據不一致和用戶使用體驗的問題。
如圖1-15所示爲Istio和Kubernetes架構的關係，可以看出，Istio不僅數據面Envoy跑在Kubernetes的Pod裏，其控制面也運行在Kubernetes集羣中，其控制面組件本身存在的形式也是Kubernetes Deployment和Service，基於Kubernetes擴展和構建。
圖1-15 Istio與Kubernetes架構的關係
如表1-2所示爲Istio+Kubernetes的方案與將SDK開發的微服務部署在Kubernetes上的方案的比較。
表1-2 兩種方案的比較
本章總結
如圖1-16所示爲Istio、微服務、容器與Kubernetes的關係。
圖1-16 Istio、微服務、容器與Kubernetes的關係
Kubernetes在容器編排領域已經成爲無可爭辯的事實標準；微服務化的服務與容器在輕量、敏捷、快速部署運維等特徵上匹配，這類服務在容器中的運行也正日益流行；隨着Istio 的成熟和服務網格技術的流行，使用 Istio 進行服務治理的實踐也越來越多，正成爲服務治理的趨勢；而 Istio 與 Kubernetes 的天然融合且基於 Kubernetes 構建，也補齊了Kubernetes的治理能力，提供了端到端的服務運行治理治理平臺。這都使得Istio、微服務、容器及Kubernetes形成一個完美的閉環。
雲原生應用採用 Kubernetes 構建應用編排能力，採用 Istio 構建服務治理能力，將逐漸成爲企業技術轉型的標準配置。