Service Mesh 化繁為簡(jiǎn)：基于 Istiod 回歸單體設(shè)計(jì)

作為 Service Mesh 領(lǐng)域最具權(quán)威的控制面，Istio 從 2017 年發(fā)布第一個(gè)版本后，就有著一個(gè)堪稱“非常優(yōu)雅”的架構(gòu)設(shè)計(jì)。但在推出近 3 年后，其開發(fā)團(tuán)隊(duì)卻“意外”推翻之前的架構(gòu)，重新用上“復(fù)古的”單體應(yīng)用設(shè)計(jì)。這里面究竟遇到什么不可逾越的鴻溝？ 筆者從幾個(gè)簡(jiǎn)單問(wèn)題（Why、What、When）出發(fā)，為大家揭開這次算是 Istio 誕生以來(lái)最大一次“自我革命”的來(lái)龍去脈。

背景

“Premature optimizationComplexity is the root of all evil or: How I Learned to Stop Worrying and Love the Monolith”

這是 istiod 長(zhǎng)達(dá) 21 頁(yè)設(shè)計(jì)文檔的開篇引用語(yǔ)，原文出自 Donald Knuth 1974 年在 ACM Journal 上發(fā)表的文章《Structured Programming with go to Statements》，意思是在沒(méi)有量化的性能測(cè)試檢測(cè)出真正存在的性能問(wèn)題前，各種在代碼層面的“炫技式”優(yōu)化，可能不僅提升不了性能，反而會(huì)導(dǎo)致更多 bug。

而 Istiod 的設(shè)計(jì)提出者把 “Premature optimization” 換成了 “Complexity”，并且補(bǔ)充一句，“How I Learned to Stop Worrying and Love the Monolith”，簡(jiǎn)單翻譯過(guò)來(lái)就是 —— “復(fù)雜性是萬(wàn)惡之源，停止焦慮，愛上單體”。顯然，今天我們要討論的不是軟件優(yōu)化相關(guān)的事情，而是一個(gè)關(guān)于 Istio 架構(gòu)調(diào)整的問(wèn)題。

lstio 作為 Service Mesh（服務(wù)網(wǎng)格）領(lǐng)域最具權(quán)威的控制面，基本上提到服務(wù)網(wǎng)格，所有人都會(huì)不自覺(jué)地想到它，如網(wǎng)易杭州研究院的輕舟微服務(wù)平臺(tái)，也是基于 lstio 提供服務(wù)網(wǎng)格的支持。

從 2017 年發(fā)布第一個(gè)版本以來(lái)，lstio 就有著一個(gè)堪稱非常優(yōu)雅的架構(gòu)設(shè)計(jì)。服務(wù)網(wǎng)格整個(gè)系統(tǒng)分為數(shù)據(jù)面和控制面，前者通過(guò)同樣是開源的智能代理組件 Envoy 負(fù)責(zé)進(jìn)行流量處理。而之所以稱之為智能，是因?yàn)?Envoy 相對(duì)比其它代理比如 Nginx 有著更豐富的治理能力和靈活的配置方式，并且支持各種插件可用于擴(kuò)展流量治理能力；而控制面在網(wǎng)格系統(tǒng)里則根據(jù)功能職能的不同，被劃分成以下 5 個(gè)核心組件：

Pilot
控制面的核心組件，負(fù)責(zé)對(duì)接 Envoy 數(shù)據(jù)面，也可以解析上層抽象出來(lái)的 lstio 配置，轉(zhuǎn)換成數(shù)據(jù)面可以識(shí)別的 xDS 協(xié)議配置并分發(fā)到各個(gè) Envoy；

Galley
為更好的解耦職責(zé)，它在 lstio 1.1 后由僅負(fù)責(zé)配置驗(yàn)證升級(jí)成了控制面的配置管理中心，可以對(duì)接不同注冊(cè)中心，用于為服務(wù)網(wǎng)格提供配置輸入能力；

Injector
在 K8s 體系里負(fù)責(zé)數(shù)據(jù)面的初始化相關(guān)工作，其中 lstio 的核心特性之一 Sidecar 自動(dòng)注入正是依賴該組件；

Mixer
是 ilstio 里負(fù)責(zé)提供策略控制和遙測(cè)收集的組件，內(nèi)部包含兩個(gè)子組件 —— Telemetry 和 Policy，其中 Telemetry 前者負(fù)責(zé)監(jiān)控相關(guān)的采集信息的數(shù)據(jù)聚合以用于對(duì)接各種監(jiān)控后端，而 Policy 負(fù)責(zé)在服務(wù)相互調(diào)用過(guò)程中對(duì)請(qǐng)求進(jìn)行策略檢查，例如鑒權(quán)；

Citadel
負(fù)責(zé)服務(wù)網(wǎng)格里安全相關(guān)功能，為服務(wù)和用戶提供認(rèn)證和鑒權(quán)、管理憑據(jù)和 RBAC 等相關(guān)能力；

服務(wù)網(wǎng)格控制面各個(gè)組件被定義得清楚了然，設(shè)計(jì)之初就已經(jīng)考慮到各種組件職責(zé)解耦、擴(kuò)展性、安全性等，架構(gòu)上看起來(lái)也非常清晰優(yōu)雅。

那么，在這個(gè)架構(gòu)設(shè)計(jì)中，究竟存在著什么樣的難解之題，迫使 istio 開發(fā)團(tuán)隊(duì)在 istio 推出將近 3 年之時(shí)，決定推翻這個(gè)架構(gòu)設(shè)計(jì)，重新用起“復(fù)古的”單體應(yīng)用設(shè)計(jì)？

下面我從幾個(gè)簡(jiǎn)單問(wèn)題（WHY、WHAT、WHEN）出發(fā)，試圖為讀者分析這次可以算得上是 istio 從誕生以來(lái)最大的一次“自我革命”的來(lái)龍去脈，不足之處，歡迎指正。

??

Why — 為什么要回歸單體 ?

如果有人問(wèn) lstio 在回歸單體架構(gòu)設(shè)計(jì)后，誰(shuí)最應(yīng)該開香檳慶祝的話，我可能會(huì)不假思索的說(shuō)是服務(wù)網(wǎng)格的運(yùn)維人員，如果還要再加一類人，那必須算上 lstio 的開發(fā)人員。

長(zhǎng)期以來(lái)，服務(wù)網(wǎng)格的運(yùn)維人員飽受折磨，而這種難言之苦，估計(jì)也只有 lstio 的開發(fā)同學(xué)才能感同深受，試想一下如下場(chǎng)景：

正常非服務(wù)網(wǎng)格的環(huán)境下，當(dāng)用戶部署的一個(gè)應(yīng)用出現(xiàn)調(diào)用異常時(shí)，只需要簡(jiǎn)單排查下這個(gè)應(yīng)用自身以及被調(diào)用服務(wù)端即可，排除網(wǎng)絡(luò)等基礎(chǔ)組件異常的話，問(wèn)題基本上跑不出這兩個(gè)應(yīng)用，原因自然也很容易被定位出來(lái)；

現(xiàn)在當(dāng)用戶的應(yīng)用接入服務(wù)網(wǎng)格后，眾所周知，在服務(wù)網(wǎng)格里的調(diào)用模型應(yīng)該是如下圖所示的：

此時(shí)，如果業(yè)務(wù)出現(xiàn)調(diào)用異常，由于接入服務(wù)網(wǎng)格，問(wèn)題處理人員要確認(rèn) lstio 系統(tǒng)是否正常工作，還記得之前介紹過(guò)的控制面組件嗎，首先需要檢查 pilot 是否正常工作，配置是否能下發(fā)到 sidecar，然后可能還要檢查 galley 組件是否正常同步到服務(wù)實(shí)例信息，也有可能是 sidecar 注入問(wèn)題，還需要檢查 injector 組件是否正常工作…… 這還只是控制面的排查，涉及到數(shù)據(jù)面還可能需要排查 Envoy 日志等，不過(guò)這不是這次關(guān)注的點(diǎn)，暫且先不展開介紹。

我猜你可能已經(jīng)想到我要表達(dá)什么，lstio 控制面的各個(gè)組件異常都可能會(huì)導(dǎo)致數(shù)據(jù)面在發(fā)起請(qǐng)求調(diào)用時(shí)出現(xiàn)問(wèn)題，而控制面組件越多，意味著在排查問(wèn)題的時(shí)候要檢查的故障點(diǎn)越多，當(dāng)然過(guò)多的組件設(shè)計(jì)導(dǎo)致部署難度會(huì)增加這點(diǎn)也是毋庸置疑。

說(shuō)得也許有點(diǎn)危言聳聽。不過(guò)，對(duì)于將要或者正在使用服務(wù)網(wǎng)格的用戶來(lái)說(shuō)，大可不必太擔(dān)心，這種由于服務(wù)網(wǎng)格本身異常導(dǎo)致數(shù)據(jù)面無(wú)法正常請(qǐng)求的情況一般只出現(xiàn)在服務(wù)網(wǎng)格的開發(fā)過(guò)程中，真正用于生產(chǎn)環(huán)境的肯定是經(jīng)過(guò)充分測(cè)試的服務(wù)網(wǎng)格組件，對(duì)于業(yè)務(wù)用戶而言可以當(dāng)成是一個(gè)穩(wěn)定的基礎(chǔ)組件來(lái)用。

現(xiàn)在，Service Mesh 的優(yōu)點(diǎn)已經(jīng)逐漸被大家認(rèn)可，比如開發(fā)運(yùn)維解耦、集中式管理、開發(fā)語(yǔ)言無(wú)關(guān)等等，但這里有一個(gè)問(wèn)題其實(shí)是被大家所忽視的，那就是 lstio 自身的控制面組件的運(yùn)維難題，分析下來(lái)可能有這么三個(gè)方面：

第一是管理職責(zé)劃分問(wèn)題

lstio 控制面組件拆分設(shè)計(jì)的初衷是為了功能職責(zé)分離，以便不同的運(yùn)維 / 開發(fā)人員可以單獨(dú)管理，但現(xiàn)狀是，大多數(shù)的 lstio 應(yīng)用場(chǎng)景里，運(yùn)維這件事往往是由一個(gè)人或者同一個(gè)團(tuán)隊(duì)來(lái)管理，這與當(dāng)初的設(shè)計(jì)初衷是背道相馳的，存在著過(guò)度設(shè)計(jì)的可能；

第二是導(dǎo)致的部署復(fù)雜

拆分后的不同組件，在整個(gè)可運(yùn)維性方面卻是線性增長(zhǎng)，比如剛才的排查問(wèn)題場(chǎng)景，每個(gè)組件都有獨(dú)立的部署文件，里面封裝著各自特有的啟動(dòng)參數(shù)，雖然這部分可以直接封裝成 K8s 的單一 yaml 文件，但是一旦出問(wèn)題需要排查原因或者是社區(qū)版本的 lstio 功能不滿足需要進(jìn)行二次開發(fā)時(shí)，這么多復(fù)雜的配置和參數(shù)你就必須得關(guān)心了。對(duì)于開發(fā)或者運(yùn)維來(lái)說(shuō)，這無(wú)疑帶來(lái)了巨大挑戰(zhàn)。

而且，lstio 在設(shè)計(jì)之初非常理想化的提出控制面的各個(gè)組件都可以獨(dú)立部署，在實(shí)際應(yīng)用場(chǎng)景里卻并非如此。

不管是出于簡(jiǎn)化運(yùn)維或是節(jié)省資源的目的想要精簡(jiǎn)部署的話，你可能不得不做出“一些艱難選擇”，任何一個(gè)組件的割舍都意味著你將失去很多核心能力……放棄 galley 意味著無(wú)法進(jìn)行 API 校驗(yàn)，隨意下發(fā)的錯(cuò)誤配置可能會(huì)導(dǎo)致 envoy 拒絕配置而使得相關(guān)的配置也同時(shí)失效；放棄 mixer 意味著你將無(wú)法完成類似于流控、權(quán)限檢查、監(jiān)控采集等；放棄 injector 意味你無(wú)法使用自動(dòng)注入功能……

第三是不必要的獨(dú)立伸縮性和安全性考慮

lstio 拆分設(shè)計(jì)之后，按預(yù)先設(shè)想各個(gè)組件都擁有獨(dú)立的伸縮能力，但值得思考的是，lstio 的各個(gè)拆分組件，真的需要各自不同的安全設(shè)計(jì)考慮以及獨(dú)立的伸縮能力設(shè)計(jì)嗎？

引用來(lái)自 Istiod 設(shè)計(jì)文檔里的一段話：“目前看來(lái)，對(duì)于多數(shù)組件來(lái)說(shuō)并非如此。而控制平面的成本由單一功能（xDS）決定。相對(duì)而言，其它所有組件的消耗微不足道，因此分離并無(wú)必要。”同樣，在關(guān)于分離的安全性設(shè)計(jì)方面，文檔是這么描述的:“在目前，Mutating Webhook、Envoy Bootstrap 以及 Pilot，這幾個(gè)組件的安全級(jí)別和 Citadel 是基本持平的，對(duì)他們的濫用所引發(fā)的損失幾乎是相同的。”

非常顯然，分離設(shè)計(jì)并不會(huì)在安全性和擴(kuò)展性方面帶來(lái)實(shí)質(zhì)性的提升，相反這種設(shè)計(jì)會(huì)給用戶帶來(lái)額外疑惑 ——“我究竟要給各個(gè)組件設(shè)置多少個(gè)副本或者資源才合理呢？“

看完上面的幾點(diǎn)分析，你可能已經(jīng)對(duì) lstio 控制面的拆分架構(gòu)設(shè)計(jì)有了新的看法，順應(yīng)了一句老話，“永遠(yuǎn)沒(méi)有完美的架構(gòu)，只有最合適的架構(gòu)”。這個(gè)看似如此優(yōu)雅的架構(gòu)設(shè)計(jì)，卻在用戶落地過(guò)程中，對(duì)運(yùn)維人員或者開發(fā)人員帶來(lái)了意料之外的困難……

其實(shí)我們可以跳出這個(gè)架構(gòu)設(shè)計(jì)來(lái)重新思考一個(gè)有趣的問(wèn)題：

服務(wù)網(wǎng)格本身的設(shè)計(jì)目標(biāo)就是號(hào)稱下一代微服務(wù)架構(gòu)，用于解決微服務(wù)之間的運(yùn)維管理問(wèn)題，而在服務(wù)網(wǎng)格的設(shè)計(jì)過(guò)程中，竟然又引入了一套新的微服務(wù)架構(gòu)？

這豈不是“用一套微服務(wù)架構(gòu)設(shè)計(jì)的系統(tǒng)來(lái)解決另一套微服務(wù)系統(tǒng)的服務(wù)治理問(wèn)題？”那誰(shuí)來(lái)負(fù)責(zé)解決 istio 系統(tǒng)本身的微服務(wù)架構(gòu)問(wèn)題呢？

微服務(wù)架構(gòu)帶來(lái)的運(yùn)維成本是不可避免的，所以，這里問(wèn)題的本質(zhì)是“一套系統(tǒng)的運(yùn)維職責(zé)由誰(shuí)來(lái)負(fù)責(zé)？” lstio 作為一個(gè)開源項(xiàng)目，運(yùn)維的職責(zé)無(wú)疑會(huì)落在各個(gè)想要使用網(wǎng)格的團(tuán)隊(duì)身上，對(duì)于非 istio 開發(fā)團(tuán)隊(duì)而言，這個(gè)使用門檻是比較高的，無(wú)疑存在著巨大的學(xué)習(xí)和使用成本，很多人因此望而卻步。

What — 什么是 Istiod ?
幸運(yùn)的是，lstio 社區(qū)“非常及時(shí)”地發(fā)現(xiàn)這個(gè)問(wèn)題，也許是因?yàn)?Github 社區(qū)里幾乎每天都有各種花樣、無(wú)窮無(wú)盡的部署相關(guān) issue，也許是他們?yōu)榱私鉀Q運(yùn)維部署難題在嘗試各種手段（比如 lstio operator、Istioctl 等工具在一定程度上是為解決部分運(yùn)維部署易用性問(wèn)題的）卻未取得突破性的改善后，終于有一天，有個(gè)勇敢的人站出來(lái)說(shuō)了句：“復(fù)雜性是萬(wàn)惡之源，停止焦慮，愛上單體” 吧！！！

這就是文章開頭的這句合體“宣言”，召喚出了 Istiod …

在這這份公開的設(shè)計(jì)文檔里，作者一開始便非常明確地提出 istiod 的設(shè)計(jì)目標(biāo)：

降低安裝復(fù)雜度。單一的二進(jìn)制文件在安裝部署時(shí)將會(huì)更加簡(jiǎn)單；
降低配置復(fù)雜度。之前的很大一部分配置文件是用于編排控制面組件，而單體化設(shè)計(jì)后這部分配置可以被移除，而且新版本的 Istiod 在配置上可能更精簡(jiǎn)，只需保留一個(gè) mesh.yaml 文件，并且能提供最佳實(shí)踐配置；
增加控制面可運(yùn)維性。通過(guò)單體設(shè)計(jì)后的控制面在類似于金絲雀發(fā)布的多控制面場(chǎng)景里顯得更加簡(jiǎn)單；不同的工作負(fù)載可以通過(guò) namespace 或者 pod 上的標(biāo)簽設(shè)置（也可以是組合匹配）來(lái)選擇對(duì)接不同的控制平面；
提高問(wèn)題診斷能力。單個(gè)控制面組件意味著出了問(wèn)題后無(wú)需在不同的組件間切換來(lái)切換去，排查各種問(wèn)題，顯然這有助于提升問(wèn)題排查效率；
提高效率和響應(yīng)速度。再也不用在各個(gè)組件間通過(guò)遠(yuǎn)程調(diào)用來(lái)傳遞數(shù)據(jù)，而且原本不同組件間需要共享的數(shù)據(jù)，現(xiàn)在也可以安全被共享，而且也會(huì)一定程度上加快控制面的啟動(dòng)速度；
消除不必要的耦合。通過(guò)把 Envoy 的啟動(dòng)配置生成移到控制面可以避免 pilot agent 的訪問(wèn)權(quán)限問(wèn)題。（這個(gè)設(shè)計(jì)目標(biāo)存在爭(zhēng)議，有人提出 Envoy 的啟動(dòng)配置跟 pilot 或者 galley 沒(méi)有直接關(guān)系應(yīng)該單獨(dú)出文檔介紹，也有人認(rèn)為作者的意圖是指說(shuō)將 injector 組件也合并入 Istiod 組件內(nèi)）。
6 個(gè)設(shè)計(jì)目標(biāo)，基本上都是在針對(duì) Istio 的運(yùn)維問(wèn)題，而且也不難發(fā)現(xiàn)，這種單體式的設(shè)計(jì)理念，的確能降低整體的運(yùn)維復(fù)雜度以及排查問(wèn)題的難度。

那么在一體化的設(shè)計(jì)后，Istiod 又應(yīng)該如何找準(zhǔn)自己的定位，明確自己的工作職責(zé)呢？當(dāng)然，Istio 的開發(fā)團(tuán)隊(duì)并不是說(shuō)完全推翻之前的設(shè)計(jì)，其實(shí)只是將原有的多進(jìn)程設(shè)計(jì)模式優(yōu)化成單進(jìn)程的形態(tài)，之前各個(gè)組件被設(shè)計(jì)成了 Istiod 的內(nèi)部子模塊而已，因此 Istiod 就需要承擔(dān)所有的職責(zé)：

監(jiān)聽配置，接手了原來(lái) galley 的工作，負(fù)責(zé)監(jiān)聽來(lái)自多種支持配置源的數(shù)據(jù)，比如 K8S api server，本地文件或者基于 MCP 協(xié)議的配置，包括原來(lái) galley 需要處理的 API 校驗(yàn)和配置的轉(zhuǎn)發(fā)也需要設(shè)計(jì)在內(nèi)；
監(jiān)聽 Endpoint，監(jiān)聽來(lái)自本地或者遠(yuǎn)程集群的 endpoint 信息，在將來(lái)還計(jì)劃允許 endpoint 復(fù)制在各個(gè)集群內(nèi)，包括非 K8s 的注冊(cè)中心例如 consul；
CA 根的生成，生成私鑰和證書，目前 Citadel 的職責(zé)之一；
控制面身份標(biāo)識(shí)，目前在內(nèi)部控制面之間是通過(guò) CA 根來(lái)生成一個(gè) SPIFFE ID 用于識(shí)別身份，也同時(shí)用于 injector 組件的證書生成，可以參考另外一篇 proposal（simplified control-plane identity proposal）
證書生成，主要是為各個(gè)控制面之間的通訊生成私鑰和證書來(lái)保證安全通訊；
自動(dòng)注入，在 K8S 里需要為 Mutating Admission Controller 提供接口支持，從而可以在 pod 創(chuàng)建階段修改資源文件來(lái)實(shí)現(xiàn) sidecar 的自動(dòng)注入；
CNI/CRI 注入，通過(guò) CNI/CRI 作為 hook 來(lái)實(shí)現(xiàn)自動(dòng)注入的另一種方式，目前還沒(méi)使用；
Envoy 啟動(dòng)配置生成，上文目標(biāo)中提到的，Envoy 的啟動(dòng)配置將由 istiod 來(lái)提供；
本地的 SDS Server，提供密鑰發(fā)現(xiàn)服務(wù)的本地服務(wù)端；
中央 SDS Server，同上，是一個(gè)中央化的密鑰發(fā)現(xiàn)服務(wù)端，一般用以對(duì)接第三方的密鑰系統(tǒng)；
xDS 服務(wù)提供，之前 pilot 的核心能力，為所有的 Envoy 提供 xDS 下發(fā)的服務(wù)端；

如果將改造前的 Istio 控制前按功能簡(jiǎn)化整理成表格就是：

而新版本后的組件則非常精簡(jiǎn)，對(duì)應(yīng)如下：

經(jīng)過(guò)對(duì)比，可以很直觀地看到，Istiod 是將原有的的其它組件統(tǒng)統(tǒng)塞入了 pilot，而架構(gòu)調(diào)整后的新 pilot，即 Istiod 肩負(fù)了相比 pilot 更多的職責(zé)，單個(gè)二進(jìn)制文件在部署方式上變得更加簡(jiǎn)單。

如果按照官方的部署一套 demo 的話，除了 ingress 和 egress 網(wǎng)關(guān)以及另外幾個(gè)監(jiān)控相關(guān)的組件，剩下的就只有一個(gè) istiod 組件。

通過(guò)這種多進(jìn)程到單進(jìn)程的架構(gòu)調(diào)整，Istio 的開發(fā)團(tuán)隊(duì)可以算是以最小的成本實(shí)現(xiàn)了整體運(yùn)維方面的巨大收益：

運(yùn)維配置變得更加簡(jiǎn)單，用戶只需要部署或升級(jí)一個(gè)單獨(dú)的服務(wù)組件；

更加容易排查錯(cuò)誤，因?yàn)椴恍枰贆M跨多個(gè)組件去排查各種錯(cuò)誤；

更加利于做灰度發(fā)布，因?yàn)槭菃我唤M件，可以非常靈活切換至不同的控制面；

避免了組件間的網(wǎng)絡(luò)開銷，因?yàn)榻M件內(nèi)部可直接共享緩存、配置等，也會(huì)降低資源開銷；

新的基于 Istiod 的架構(gòu)變成下圖：

相比之前的架構(gòu)圖，是不是感覺(jué)格外清爽，有種豁然開朗的感覺(jué)？
When — 什么時(shí)候發(fā)布 ?
介紹完了 Istiod 的誕生初衷和設(shè)計(jì)理念，作為服務(wù)網(wǎng)格的開發(fā)人員或者正在觀望的團(tuán)隊(duì)，想必都會(huì)對(duì)這個(gè) Istiod 的新特性滿懷期待，單體設(shè)計(jì)后的 Istio 管控平面簡(jiǎn)化部署流程，減少因?yàn)椴渴鸹蛘吲渲脝?wèn)題引發(fā)的不必要時(shí)間浪費(fèi)，的的確確是在“save your life”。

網(wǎng)易輕舟微服務(wù)團(tuán)隊(duì)一直在關(guān)注 Istio 社區(qū)的最新動(dòng)態(tài)，早在社區(qū)代碼倉(cāng)庫(kù)的 release 1.5 開發(fā)分支中就發(fā)現(xiàn)了 Istiod 的身影，而近日正式發(fā)布的 1.5 版本，眾望所歸的 Istiod 自然包含在內(nèi)，這意味著從這個(gè)版本開始，Istio 控制面部署形態(tài)將正式進(jìn)入一個(gè)全新的時(shí)代，堪稱是一次突破性的設(shè)計(jì)革新。

One More Thing，Istio 的官方博客在正式發(fā)布 1.5 的前幾天，發(fā)布了一篇博文 ——《Istio in 2020 - Following the Trade Winds》，介紹了 Istio 社區(qū) 2020 年的一些“風(fēng)向標(biāo)”，其中就有提到一些非常令人興奮的特性：

1.將會(huì)更整潔、更平滑、更快速

Istio 從誕生以來(lái)的第一天就提供了可擴(kuò)展性方面的能力，這里面 mixer 組件扮演了非常重要的角色，它允許用戶通過(guò)自定義適配器（adapter）的方式來(lái)開發(fā)擴(kuò)展；在之前版本里，mixer 一直是一個(gè)進(jìn)程外組件設(shè)計(jì)，新設(shè)計(jì)中針對(duì)一些常用場(chǎng)景比如鑒權(quán)，將會(huì)被 Istio 的認(rèn)證模塊取代，這樣子設(shè)計(jì)好處是允許用戶直接在 proxy 內(nèi)部進(jìn)行鑒權(quán)認(rèn)證，其它的比如通用的指標(biāo)監(jiān)控也同時(shí)被移入了 proxy 內(nèi)部。

這意味著之前一直遭人詬病的 Mixer 性能問(wèn)題將會(huì)有非常大的改善，根據(jù)官方的 benchmark，通過(guò)新的 telemetry 模型設(shè)計(jì)可以取得業(yè)界領(lǐng)先的性能數(shù)據(jù)，相比之前減少約 50% 的延遲以及不少 CPU 消耗；

2.全新的擴(kuò)展支持方式

這種全新的擴(kuò)展支持架構(gòu)相比之前提供了更好兼容性，也正是 Istio 社區(qū)的開發(fā)者主導(dǎo)開發(fā)了 Envoy 里的 WASM 特性支持，允許用戶以超過(guò) 20 種開發(fā)語(yǔ)言來(lái)實(shí)現(xiàn)各種擴(kuò)展插件。

令人感到興奮的是，這些插件是可以在 envoy 處理流量過(guò)程中被動(dòng)態(tài)的加載、重載的，這種動(dòng)態(tài)的靈活性自然不言而喻，istio 社區(qū)也在和 envoy 社區(qū)共建來(lái)發(fā)現(xiàn)、分發(fā)更多的擴(kuò)展，目的是為了讓這些插件更加容易被用戶安裝或是在容器環(huán)境里運(yùn)行；包括部分之前編寫 mixer adapter 的開發(fā)者也正在“搬運(yùn)”這些插件到 WASM 上，社區(qū)也在努力提供相關(guān)的文檔以幫助更多的開發(fā)者上手 WASM；

Istio 1.5 確實(shí)可以稱得上是一次突破性的版本發(fā)布，各種架構(gòu)上或者是設(shè)計(jì)上的優(yōu)化，都可以看的出來(lái)是在做減法，包括更精簡(jiǎn)的架構(gòu)，更簡(jiǎn)單的擴(kuò)展支持方式。

社區(qū)里提出的各種缺陷，都正在逐一被優(yōu)化，比如可運(yùn)維性、易用性、擴(kuò)展性等方面，還有一直被人詬病的性能，也正在通過(guò)架構(gòu)性的調(diào)整得以優(yōu)化和改良，甚至這篇文章里還提到，之前把一大批非容器用戶擋在門外的平臺(tái)限制問(wèn)題，在不久的將來(lái)也將成為一個(gè)歷史，按照博客介紹的，社區(qū)正在努力 “Making it easier to run Istio without needing Kubernetes”！

結(jié)語(yǔ)

盡管之前一直被人抱怨存在各種問(wèn)題，但 Istio 社區(qū)的開發(fā)腳步?jīng)]有停歇，我們看到了一次又一次的版本發(fā)布從未間斷，伴隨著各種大大小小的功能更新和優(yōu)化。就網(wǎng)易杭研而言，輕舟微服務(wù)將 Istio 引入生產(chǎn)環(huán)境也是極為審慎，事實(shí)上也曾遇到了運(yùn)維和開發(fā)的困惑，而 istiod 架構(gòu)設(shè)計(jì)的回歸讓我們徹底松了一口氣，擁抱 Istio 實(shí)現(xiàn)服務(wù)網(wǎng)格的思路更加堅(jiān)定。

就像當(dāng)年的 kubernates 也曾受過(guò)質(zhì)疑，現(xiàn)在卻沒(méi)人質(zhì)疑它在容器編排領(lǐng)域的地位，相信在不久的未來(lái)，Istio 這艘小船在微服務(wù)的海洋里將會(huì)行駛得更加敏捷、輕快、平穩(wěn)，而 Service Mesh，也終將不再是一個(gè)新鮮詞。

作者介紹

翁揚(yáng)慧，網(wǎng)易杭州研究院云計(jì)算技術(shù)部資深研發(fā)工程師，有多年微服務(wù)開發(fā)經(jīng)驗(yàn)，目前主要負(fù)責(zé)網(wǎng)易輕舟服務(wù)框架和服務(wù)網(wǎng)格的核心設(shè)計(jì)以及業(yè)務(wù)落地工作，熱愛編程，熱衷于開源社區(qū)的技術(shù)交流和分享。

總結(jié)

以上是生活随笔為你收集整理的Istio 架构的演进，为什么会有 istiod ?的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。