【百度雲原生導讀】2021年伊始，若是你打算在生產環境中落地 Service Mesh，那麼 Istio 一定在你的考慮範圍以內。做爲目前最流行的 Service Mesh 技術之一，Istio 擁有活躍的社區和衆多的落地案例。但若是你想在生產環境大規模落地 Isito，這看似壯觀美好的冰山下，倒是暗流涌動，潛藏着無數兇險。html
本文是筆者深度參與百度百億量級流量生產環境研發和落地 Istio 兩年來的經驗總結和一些思考，旨在讓正在考慮在本身生產環境引入 Isito 的讀者能有所參考和啓發，作好更充足的儲備，更輕鬆的「入坑」 Istio。web
一、使用 Istio 沒法作到徹底對應用透明
服務通訊和治理相關的功能遷移到 Sidecar 進程中以後, 應用中的 SDK 一般須要做出一些對應的改變。api
SDK 須要關閉一些功能，例如重試。一個典型的場景是，SDK 重試 m 次，Sidecar 重試 n 次，這會致使 m * n 的重試風暴，從而引起風險。性能優化
此外，諸如 trace header 的透傳，也須要 SDK 進行升級改造。若是你的 SDK 中還有其它特殊邏輯和功能，這些可能都須要當心處理才能和 Isito Sidecar 完美配合。服務器
二、Istio 對非 K8S 環境的支持有限
在業務遷移至 Istio 的同時，可能並無同步遷移至 K8S，而是仍然運行在原有 PaaS 系統之上。微信
這會帶來一系列挑戰：網絡
-
原有 PaaS 可能沒有容器網絡，Istio 的服務發現和流量劫持均可能要根據舊有基礎設施進行適配才能正常工做架構
-
若是舊有的 PaaS 單個實例不能很好的管理多個容器（類比 K8S 的 Pod 和 Container 概念），大量 Istio Sidecar 的部署和運維將是一個很大的挑戰運維
-
缺乏 K8S webhook 機制，Sidecar 的注入也可能變得不那麼透明，而須要耦合在業務的部署邏輯中分佈式
三、只有 HTTP 協議是一等公民
Istio 原生對 HTTP 協議提供了完善的全功能支持，但在真實的業務場景中，私有化協議卻很是廣泛，而 Istio 卻並未提供原生支持。
這致使使用私有協議的一些服務可能只能被迫使用 TCP 協議來進行基本的請求路由，這會致使不少功能的缺失，這其中包括 Istio 很是強大的基於內容的消息路由，如基於 header、 path 等進行權重路由。
四、擴展 Istio 的成本並不低
雖然 Istio 的整體架構是基於高度可擴展而設計，但因爲整個 Istio 系統較爲複雜，因此若是你實際對 Istio 進行過擴展，就會發現成本並不低。
以擴展 Istio 支持某一種私有協議爲例，首先你須要在 Istio 的 api 代碼庫中進行協議擴展，其次你須要修改 Istio 代碼庫來實現新的協議處理和下發，接着你還須要修改 xds 代碼庫的協議，最後你還要在 Envoy 中實現相應的 Filter 來完成協議的解析和路由等功能。
在這個過程當中，你還可能面臨上述數個複雜代碼庫的編譯等工程挑戰（若是你的研發環境不能很好的使用 Docker 或者沒法訪問部分國外網絡的狀況下）。
即便作完了全部的這些工做，也可能面臨這些工做沒法合併回社區的狀況，社區對私有協議的擴展支持度不高，這會致使你的代碼和社區割裂，爲後續的升級更新帶來隱患。
五、Istio 在集羣規模較大時的性能問題
Istio 默認的工做模式下，每一個 Sidecar 都會收到全集羣全部服務的信息。若是你部署過 Istio 官方的 Bookinfo 示例應用，並使用 Envoy 的 config dump 接口進行觀察，你會發現，僅僅幾個服務，Envoy 所收到的配置信息就有將近 20w 行。
能夠想象，在稍大一些的集羣規模，Envoy 的內存開銷、Istio 的 CPU 開銷、XDS 的下發時效性等問題，必定會變得尤其突出。
Istio 這麼作一是考慮這樣能夠開箱即用，用戶不用進行過多的配置，另外在一些場景，可能也沒法梳理出準確的服務之間的調用關係，所以直接給每一個 Sidecar 下發了全量的服務配置，即便這個 Sidecar 只會訪問其中很小一部分服務。
固然這個問題也有解法，若是你的生產環境中，能梳理出這些調用關係，你能夠經過 Sidecar CRD 來顯示定義服務調用關係，使 Envoy 只獲得他須要的服務信息，從而大幅下降 Envoy 的資源開銷。
六、XDS 分發沒有分級發佈機制
當你對一個服務的策略配置進行變動的時候，XDS 不具有分級發佈的能力，全部訪問這個服務的 Envoy 都會當即收到變動後的最新配置。這在一些對變動敏感的嚴苛生產環境，多是有很高風險甚至不被容許的。
若是你的生產環境嚴格要求任何變動都必須有分級發佈流程，那你可能須要考慮本身實現一套這樣的機制。
七、Istio 組件故障時是否有退路？
以 Istio 爲表明的 Sidecar 架構的特殊性在於，Sidecar 直接承接了業務流量，而不像一些其餘的基礎設施那樣，只是整個系統的旁路組件（好比 K8S）。
所以在 Isito 落地初期，你必須考慮，若是 Sidecar 進程掛掉，服務怎麼辦？是否有退路？是否能 fallback 到直連模式？
在 Istio 落地過程當中，是否能無損 fallback，一般決定了核心業務可否接入 Service Mesh。
八、Istio 技術架構的成熟度尚未達到預期
雖然 Istio 1.0 版本已經發布好久了，可是若是你關注社區每一個版本的迭代，就會發現，Istio 目前架構依然處於不太穩定的狀態，尤爲是 1.5 版本先後的幾個大版本，前後經歷了去除 Mixer 組件、合併爲單體架構、僅支持高版本 K8S 等等重大變更，這對於已經在生產環境中使用了 Istio 的用戶很是不友好，由於升級會面臨各類不兼容性問題。
好在社區也已經意識到這一問題，2021 年社區也成立了專門的小組，重點改善 Istio 的兼容性和用戶體驗。
九、Istio 缺少成熟的產品生態
Istio 做爲一套技術方案，卻並非一套產品方案。
若是你在生產環境中使用，你可能還須要解決可視化界面、權限和帳號系統對接、結合公司已有技術組件和產品生態等問題，僅僅經過命令行來使用，可能並不能知足你的組織對權限、審計、易用性的要求。
而 Isito 自帶的 Kiali 功能還十分簡陋，遠遠沒有達到能在生產環境使用的程度，所以你可能須要研發基於 Isito 的上層產品。
十、Istio 目前解決的問題域還頗有限
Istio 目前主要解決的是分佈式系統之間服務調用的問題，但還有一些分佈式系統的複雜語義和功能並未歸入到 Istio 的 Sidecar 運行時之中，好比消息發佈和訂閱、狀態管理、資源綁定等等。
雲原生應用將會朝着多 Sidecar 運行時或將更多分佈式能力歸入單 Sidecar 運行時的方向繼續發展，以使服務自己變得更爲輕量，讓應用和基礎架構完全解耦。
若是你的生產環境中，業務系統對接了很是多和複雜的分佈式繫系統中間件，Istio 目前可能並不能徹底解決你的應用的雲原生化訴求。
寫在最後
看到這裏，你是否感到有些沮喪，而對 Istio 失去信心？
上面列舉的這些問題，實際上並不影響 Istio 依然是目前最爲流行和成功的 Service Mesh 技術選型之一。Istio 頻繁的變更，必定程度上也說明它擁有一個活躍的社區，咱們應當對一個新的事物抱以信心，Istio 的社區也在不斷聽取來自終端用戶的聲音，朝着更合理的方向演進。
同時，若是你的生產環境中的服務規模並非很大，服務已經託管於 K8S 之上，也只使用那些 Istio 原生提供的能力，那麼 Istio 依然是一個值得嘗試的開箱即用方案。
但若是你的生產環境比較複雜，技術債務較重，專有功能和策略需求較多，亦或者服務規模龐大，那麼在開始使用 Istio 以前，你須要仔細權衡上述這些要素，以評估在你的系統之中引入 Istio 可能帶來的複雜度和潛在成本。
百度雲原生團隊在2021年將持續爲你們帶來 Service Mesh 系列文章，內容涵蓋 Istio 入門體驗、Istio 和 Envoy 源碼深度解析、服務網格大規模落地經驗、服務網格性能優化等，敬請持續關注。
關於百度智能云云原平生臺
百度智能云云原平生臺，爲客戶建設容器化和無服務器化的基礎設施，提供企業級的微服務治理能力，同時集成源自百度自身多年實踐的 DevOps 工具鏈。可以保障開發者享受到高效、靈活、彈性的開發與運維體驗，助力企業更高效率低風險地構建雲原生應用，普遍應用於金融、互聯網、製造等各行各業的雲原生轉型階段。
其中天合 Stack 是私有化雲原生技術中臺，包含基於 Kubernetes 的容器雲平臺、基於 Istio 和 SpringCloud 架構的微服務平臺和自研函數計算服務三部分，每部分都可獨立提供服務。
點擊https://cloud.baidu.com/product/cnap.html，查看百度雲原平生臺詳情。
相關閱讀：
重磅！雲原生計算交流羣成立
掃碼添加小助手便可申請加入，必定要備註：名字-公司/學校-地區，根據格式備註，才能經過且邀請進羣。。
瞭解更多微服務、雲原生技術的相關信息，請關注咱們的微信公衆號【雲原生計算】！