2.1 Istio的設計理念

Istio首先是服務網格（Service Mesh）的一個工程實踐，說到服務網格首先想到的就是Sidecar，它獨立存在于業務邏輯，這使得跨語言調用變簡單——上層業務方完全無須感知復雜的分布式邏輯。同時由于Sidecar與業務部署在同一個資源單元上（如虛擬機或者容器），方便地實現了鏈路流量路由及安全控制。Istio的設計理念核心就是將所有鏈路管理都下沉至協議級別。這樣做不僅能對業務方透明，還能將鏈路管理統一收攏在平臺，可謂一舉多得。

筆者認為，任何一個優秀的產品在開始設計時都需要有一個初心，即我的產品解決什么問題，在什么樣的場景下發揮作用，其適用的用戶群體是什么等，這樣之后的功能才能緊密圍繞初心而不斷強化，否則就會慢慢地偏離自己預設的路線和起初的目標，功能雖然越來越多，優勢卻越來越不明顯。

因此要理解Istio的設計理念，就得從其誕生的大環境說起，以了解在當時的場景下遇到的問題是什么，設計團隊想解決的問題是哪些，這樣就能慢慢理清楚了。

2.1.1 Istio的誕生背景

Istio是Google于2017年5月推出的服務網格（Service Mesh）產品，已于2018年8月推出1.0正式版本。Istio誕生之初，即2017年，正值微服務編排Kubernetes發展的繁盛時期，各大技術論壇都在討論Docker及微服務彈性伸縮，微服務理念得到了空前的發展。微服務本身并不強調語言架構上的統一（使用的RPC都是基于HTTP的，具有很強的跨語言特性）。開發者可以根據需要選擇（盡量一個進程一個服務），唯一需要注意的就是，在微服務中，任何一個服務都只具備單一的功能，因此會產生很多的獨立服務部署。

那么隨之而來的問題便是：這么多的微服務，這么多的調用及系統流量，如何才能有效地管理起來呢？而且同時還需要支持不同的語言及不同的部署平臺。

經過綜合考慮，Istio的設計者們決定它應該是一個提供連接管理、安全控制、負載限流的統一微服務平臺。Istio不僅提供了服務之間的流量控制、訪問控制策略，還集成了各種鏈路服務（例如鏈路跟蹤Zipkin）及相關的擴展接口，這一切都是無須上層業務感知的。

總之，Istio能給用戶帶來：

○針對HTTP、gRPC、WebSocket及TCP等協議的自動負載均衡。

○精細的請求流量控制，支持眾多路由、重試及容災層面上的規則，支持故障模擬。

○模塊化插件擴展支持，可通過API進行訪問、頻率限制及配額方面的控制。

○全自動化的請求遙測（Telemetry）、日志分析及全鏈路跟蹤系統，所有請求都在掌控之內。

○全鏈路安全訪問控制與身份認證。

Istio的核心意義在于：適配多種Pass平臺，把調用鏈路相關工作從業務邏輯中徹底剝離出來。形成“數據平面”，再通過添加“控制平面”進行統一控制，把整個鏈路負載工作都下沉到了PaaS基礎技術棧上層，從此業務開發工程師不再需要關心內部實現，就像使用云服務一樣簡單。簡單來說，Istio提供了服務網絡（Service Mesh）基礎環境。

在Istio的控制平面中，管理員可以通過統一的配置下發給各節點，能非常輕松地對全局進行操控，這些功能以前也許需要幾個甚至十幾個系統，如今都被集成到了一起，1～2個工程師即可輕松維護，降低了整體運維成本。

因此，Istio的核心便是“數據平面”與“控制平面”兩部分，外加“數據平面”衍生出的“安全控制”。接下來筆者便為大家一一介紹。

2.1.2 控制一切的兩個平面

首先來看看Istio的全局模塊，如圖2.1所示。

從圖2.1“Istio官方給出的全局架構圖”可以看出，所有的服務都加裝了一個代理，系統間通信都通過這個代理來進行；如此一來，業務都不需要費力去搞清楚如何到達其他服務了，它們就像在一個應用里一樣，不必去感受復雜的分布式拓撲。

對于這樣功能奇特的代理網關，Istio將之稱為Sidecar，直譯過來就是“跨斗”。邊斗源于一種特殊的摩托車，這種車的最大特點是側邊掛載有一個獨輪小車，與主體可以是一體式的，也可以是掛載式的，如圖2.2所示：

在Istio系統中，Sidecar只是一個概念，它具體是由Envoy這個開源產品實現的。

圖2.1最為明顯的特點便是Istio的所有模塊整體上被劃分成兩層：“數據平面”與“控制平面”。這兩個概念是Istio的核心，也是最基礎的邏輯劃分，其詳細解譯如下。

○數據平面（Data Plane）：由一系列代理網關構成（官方使用的是Envoy，但不強耦合，可以很方便地替換成其他產品），這種代理與Nginx的最大區別是，它們擁有非常強大的擴展接口，可以通過API實時接收配置并生效，以此實現動態化的流量代理。從鏈路上來說，“數據平面”是服務之間的橋梁。

○控制平面（Control Plane）：是對“數據平面”中網關的統一配置與維護平臺，這里的配置不僅包含請求路由，還包括限流降級、熔斷、日志收集、性能監控等各種請求相關信息。其中控制平面又被劃分成了Pilot、Mixer及Citadel三個小模塊。

對于“數據平面”，筆者將在2.2節為大家做比較全面的介紹。“數據平面”主要是由邊界網關（IngressGateway與EngressGateway）及服務之間的Sidecar兩部分組成，目前具體實現都是Envoy，只是職責不同而已。

設計兩個平面的好處在于能讓Istio專注于其中一個而將另一個交給其他團隊。例如，數據平面就可以交給比較成熟的Envoy或者Nginmesh之類的產品，如此一來就形成明顯的責任劃分，有利于生態化。這就是說，只要按兩個平面的思想，大家都可以選擇一個而投入其中，將焦點進一步縮小。例如A團隊專注于數據平面，B團隊則專注于控制平面，不同的數據平面產品與控制平面產品可以根據使用的實際生產情況隨意搭配，讓整個服務網格生態更加豐富。

2.1.3 接口與平臺化

如果只是單純地實現“數據平面”與“控制平面”這兩個功能，那么Istio充其量只能算一個產品。然而，作為一個誕生就被定位成生態的產品，Google當然希望其是引領時代的標準，就像Android一樣，用戶都按照自己設計的規范來使用。

為此Istio在“數據平面”與“控制平面”上都做了豐富的擴展支持，并設計成不依賴具體服務平臺。這一切都依賴于“適配器”這個重要的理念。例如，Istio為了不強依賴于某種“數據平面”，對所有的鏈路路由及管控邏輯進行了統一的抽象，使用標準的yaml配置模板，然后再將其翻譯成各數據平面認識的配置（例如Envoy的xDS配置）。再例如Istio的Pilot本身并不實現服務注冊與服務發現功能，僅僅是提供了對接接口，這樣不管是Eureka、Consul，還是Kubernetes，都可以接入Istio體系。

所以，Istio的野心可謂巨大，是想做服務網格的生態基石，通過接口將現有的產品都接入，幫助業界快速過渡到Service Mesh中。如果這真的得以實現，那么Kubernetes的地位將會愈加穩固，當然也順水推舟完善了GCP（Google Cloud Platform）云計算環境，戰略思路是非常明確的。

筆者將在2.2及2.3節中對“數據平面”及“控制平面”進行詳細的分析，并進一步闡釋Istio的擴展功能及原理。

2.1.4 中心化與分散化的抉擇

Istio的設計原則是要做到盡量少的業務侵入、方便快捷的系統維護以及超高的可用性。所以Istio將整體鏈路下沉至協議級別，雖然對于業務是完全透明的，但這就要求設計實現本身具有非常高的穩定性，也就是出了問題首先應該想到不是下層的支撐性問題，而是自己使用錯了或者業務本身的代碼邏輯有問題。

這種穩定性要求與TCP/IP協議一樣，即在網絡通信出現問題時，不會有人質疑“擁塞控制”與“流量控制”的邏輯——它們已誕生幾十年了，時間已經證明了它們的穩定性，大家都淡忘了其存在，除少數據情況或者特殊場景外，在應用層沒有工程師會去留意TCP/IP協議里的傳輸內容。只有達到這樣的穩定性，才能為透明無侵入這種設計帶來優秀的用戶體驗。

這就是Istio的難點，設計初衷雖然聽上去美好——與上層業務完全解耦，鏈路邏輯與業務分享——但實現上卻有非常高的操作難度。因為Istio對業務是一個黑盒，如果不夠穩定，排查問題涉及下沉邏輯時，根本無從下手。特別是大型企業，對穩定性都有相當高的要求，中間件這類的基礎設施推一個新版至少都需要1年的時間（阿里巴巴為了解決中間件客戶端升級，還專門推出一個叫潘多拉的類隔離容器方案），像Istio的Sidecar這種普遍型的中間件，每個應用都會部署一套，其升級難度可想而知。

為了最大限度地緩解以上問題，Istio的工程師們想出了一個思路：將架構重心盡量向中心傾斜，即將邏輯統一地放置了在Mixer中，數據平面僅僅是做簡單的轉發。這樣，如果我們對鏈路邏輯做了升級，比如增加鏈路跟蹤等，只需要對中心模塊加以擴展即可，否則需要逐一去升級前端的Sidecar，不僅風險高，而且非常麻煩。

對于Mixer緩存的設計，也有人持不同的觀點。螞蟻金服的工程師們就認為Mixer的中心化設計也不能完全滿足其生產場景，主要原因便是存在流量集中的現象，即由于中心節點Mixer的存在，鏈路的認證、鑒權、統計等信息都需要請求中心來實現，在大規模微服務體系中，確實有很大的吞吐量壓力。

螞蟻金服的工程師們為了規避上述問題，將Mixer的部分邏輯（比如內存、Redis配額邏輯）移到了Sidecar中（螞蟻金服使用的Sidecar并不是官方的Envoy），如圖2.3所示。這確實可以大幅度提高性能，不過可就與Istio的設計哲學有些沖突了，所以各有取舍。筆者個人認為，螞蟻金服須面對流量與系統的超復雜性，同時擁有對整個業務基礎的控制能力，這種設計也未嘗不是一個好的設計；相對地，Istio想要實現的畢竟是面向全世界的一個大而全的解決方案，其需要做的就是盡量地解耦，貫徹零侵入這一特性，讓大家盡量地忘記其存在，成為橫向的支撐服務網格平面，這就是Istio的設計哲學。

至此，我們已經大體了解了Istio的設計思想。在接下來的一節中，筆者將會依次向讀者介紹Istio架構中的三個方面：“數據平面”“控制平面”及“安全控制”，即從局部理解Istio的設計。