2021年 Istio 大型“入坑”指南

【百度雲原生導讀】2021年伊始，如果你打算在生產環境中落地 Service Mesh，那麼 Istio 必定在你的考慮範圍之內。作為目前最流行的 Service Mesh 技術之一，Istio 擁有活躍的社群和眾多的落地案例。但如果你想在生產環境大規模落地 Isito，這看似壯觀美好的冰山下，卻是暗流湧動，潛藏著無數兇險。

本文是筆者深度參與百度百億量級流量生產環境研發和落地 Istio 兩年來的經驗總結和一些思考，旨在讓正在考慮在自己生產環境引入 Isito 的讀者能有所參考和啟發，做好更充足的儲備，更輕鬆的“入坑” Istio。

01

使用 Istio 無法做到完全對應用透明

服務通訊和治理相關的功能遷移到 Sidecar 程式中之後, 應用中的 SDK 通常需要作出一些對應的改變。

SDK 需要關閉一些功能，例如重試。一個典型的場景是，SDK 重試 m 次，Sidecar 重試 n 次，這會導致 m * n 的重試風暴，從而引發風險。

此外，諸如 trace header 的透傳，也需要 SDK 進行升級改造。如果你的 SDK 中還有其它特殊邏輯和功能，這些可能都需要小心處理才能和 Isito Sidecar 完美配合。

02

Istio 對非 K8S 環境的支援有限

在業務遷移至 Istio 的同時，可能並沒有同步遷移至 K8S，而是仍然執行在原有 PaaS 系統之上。

這會帶來一系列挑戰：

原有 PaaS 可能沒有容器網路，Istio 的服務發現和流量劫持都可能要根據舊有基礎設施進行適配才能正常工作

如果舊有的 PaaS 單個例項不能很好的管理多個容器（類比 K8S 的 Pod 和 Container 概念），大量 Istio Sidecar 的部署和運維將是一個很大的挑戰

缺少 K8S webhook 機制，Sidecar 的注入也可能變得不那麼透明，而需要耦合在業務的部署邏輯中

03

只有 HTTP 協議是一等公民

Istio 原生對 HTTP 協議提供了完善的全功能支援，但在真實的業務場景中，私有化協議卻非常普遍，而 Istio 卻並未提供原生支援。

這導致使用私有協議的一些服務可能只能被迫使用 TCP 協議來進行基本的請求路由，這會導致很多功能的缺失，這其中包括 Istio 非常強大的基於內容的訊息路由，如基於 header、 path 等進行權重路由。

04

擴充套件 Istio 的成本並不低

雖然 Istio 的總體架構是基於高度可擴充套件而設計，但由於整個 Istio 系統較為複雜，所以如果你實際對 Istio 進行過擴充套件，就會發現成本並不低。

以擴充套件 Istio 支援某一種私有協議為例，首先你需要在 Istio 的 api 程式碼庫中進行協議擴充套件，其次你需要修改 Istio 程式碼庫來實現新的協議處理和下發，接著你還需要修改 xds 程式碼庫的協議，最後你還要在 Envoy 中實現相應的 Filter 來完成協議的解析和路由等功能。

在這個過程中，你還可能面臨上述數個複雜程式碼庫的編譯等工程挑戰（如果你的研發環境不能很好的使用 Docker 或者無法訪問部分國外網路的情況下）。

即使做完了所有的這些工作，也可能面臨這些工作無法合併回社群的情況，社群對私有協議的擴充套件支援度不高，這會導致你的程式碼和社群割裂，為後續的升級更新帶來隱患。

05

Istio 在叢集規模較大時的效能問題

Istio 預設的工作模式下，每個 Sidecar 都會收到全叢集所有服務的資訊。如果你部署過 Istio 官方的 Bookinfo 示例應用，並使用 Envoy 的 config dump 介面進行觀察，你會發現，僅僅幾個服務，Envoy 所收到的配置資訊就有將近 20w 行。

可以想象，在稍大一些的叢集規模，Envoy 的記憶體開銷、Istio 的 CPU 開銷、XDS 的下發時效性等問題，一定會變得尤為突出。

Istio 這麼做一是考慮這樣可以開箱即用，使用者不用進行過多的配置，另外在一些場景，可能也無法梳理出準確的服務之間的呼叫關係，因此直接給每個 Sidecar 下發了全量的服務配置，即使這個 Sidecar 只會訪問其中很小一部分服務。

當然這個問題也有解法，如果你的生產環境中，能梳理出這些呼叫關係，你可以透過 Sidecar CRD 來顯示定義服務呼叫關係，使 Envoy 只得到他需要的服務資訊，從而大幅降低 Envoy 的資源開銷。

06

XDS 分發沒有分級釋出機制

當你對一個服務的策略配置進行變更的時候，XDS 不具備分級釋出的能力，所有訪問這個服務的 Envoy 都會立即收到變更後的最新配置。這在一些對變更敏感的嚴苛生產環境，可能是有很高風險甚至不被允許的。

如果你的生產環境嚴格要求任何變更都必須有分級釋出流程，那你可能需要考慮自己實現一套這樣的機制。

07

Istio 元件故障時是否有退路？

以 Istio 為代表的 Sidecar 架構的特殊性在於，Sidecar 直接承接了業務流量，而不像一些其他的基礎設施那樣，只是整個系統的旁路元件（比如 K8S）。

因此在 Isito 落地初期，你必須考慮，如果 Sidecar 程式掛掉，服務怎麼辦？是否有退路？是否能 fallback 到直連模式？

在 Istio 落地過程中，是否能無損 fallback，通常決定了核心業務能否接入 Service Mesh。

08

Istio 技術架構的成熟度還沒有達到預期

雖然 Istio 1.0 版本已經發布很久了，但是如果你關注社群每個版本的迭代，就會發現，Istio 目前架構依然處於不太穩定的狀態，尤其是 1.5 版本前後的幾個大版本，先後經歷了去除 Mixer 元件、合併為單體架構、僅支援高版本 K8S 等等重大變動，這對於已經在生產環境中使用了 Istio 的使用者非常不友好，因為升級會面臨各種不相容性問題。

好在社群也已經意識到這一問題，2021 年社群也成立了專門的小組，重點改善 Istio 的相容性和使用者體驗。

09

Istio 缺乏成熟的產品生態

Istio 作為一套技術方案，卻並不是一套產品方案。

如果你在生產環境中使用，你可能還需要解決視覺化介面、許可權和賬號系統對接、結合公司已有技術元件和產品生態等問題，僅僅透過命令列來使用，可能並不能滿足你的組織對許可權、審計、易用性的要求。

而 Isito 自帶的 Kiali 功能還十分簡陋，遠遠沒有達到能在生產環境使用的程度，因此你可能需要研發基於 Isito 的上層產品。

10

Istio 目前解決的問題域還很有限

Istio 目前主要解決的是分散式系統之間服務呼叫的問題，但還有一些分散式系統的複雜語義和功能並未納入到 Istio 的 Sidecar 執行時之中，比如訊息釋出和訂閱、狀態管理、資源繫結等等。

雲原生應用將會朝著多 Sidecar 執行時或將更多分散式能力納入單 Sidecar 執行時的方向繼續發展，以使服務本身變得更為輕量，讓應用和基礎架構徹底解耦。

如果你的生產環境中，業務系統對接了非常多和複雜的分散式繫系統中介軟體，Istio 目前可能並不能完全解決你的應用的雲原生化訴求。

寫在最後

看到這裡，你是否感到有些沮喪，而對 Istio 失去信心？

上面列舉的這些問題，實際上並不影響 Istio 依然是目前最為流行和成功的 Service Mesh 技術選型之一。Istio 頻繁的變動，一定程度上也說明它擁有一個活躍的社群，我們應當對一個新的事物抱以信心，Istio 的社群也在不斷聽取來自終端使用者的聲音，朝著更合理的方向演進。

同時，如果你的生產環境中的服務規模並不是很大，服務已經託管於 K8S 之上，也只使用那些 Istio 原生提供的能力，那麼 Istio 依然是一個值得嘗試的開箱即用方案。

但如果你的生產環境比較複雜，技術債務較重，專有功能和策略需求較多，亦或者服務規模龐大，那麼在開始使用 Istio 之前，你需要仔細權衡上述這些要素，以評估在你的系統之中引入 Istio 可能帶來的複雜度和潛在成本。

2021年 Istio 大型“入坑”指南

寫在最後

相關文章