崔秀龍，HPE 軟體分析師，Kubernetes 權威指南作者之一，Kubernetes、Istio 項目成員。
本文根據崔秀龍在 2019 廣州 Service Mesh Meetup#5 分享整理，完整的分享 PPT 擷取方式見文章底部。
本文内容收錄在崔秀龍的新書：《深入淺出 Istio - Service Mesh 快速入門與實踐》的第十章，該書将于近期由博文視點出版發行，敬請關注。
Service Mesh 概念在 Linkerd 落地之後，讓一直漂浮在空中的微服務治理方案有了一個明确的落地點，給微服務架構的具體實作指出了一個清晰的方向，圍繞這一概念逐漸開始形成新的技術生态，在業界造成不少震動。這種震動對于企業 IT 轉型工作帶來的影響，甚至比容器化的影響更加深遠。對于承擔企業 IT 轉型工作的企業服務行業來說，也自然首當其沖感覺到新概念帶來的壓力。
企業服務行業和網際網路行業相比，業務形态、技術積累和人員結構等方面都大相徑庭，舉幾個常見的差異：
- 開發、運維、基礎設施所屬
- 人員結構、水準和年齡
- 資源使用率差别
- 架構和平台一緻性
- 負載能力
- ...
目前進行 Service Mesh 布道的主力還是網際網路行業的旗手們，一味追求跟進網際網路同行們的進度和做法，頗有邯鄲學步的風險。
本文中将會針對目前 Service Mesh 方面的一些普遍問題和關注熱點發表一些個人意見。并嘗試提供一種 Istio 的試用思路，給乙方同行們提供參考。
Istio 的功能
無需贅述，多數使用者都很清楚，Istio 使用和應用共享網絡棧的方式，利用 Iptables 劫持應用的網絡流量，進而在不修改業務源碼的情況下，完成一系列的功能：
- 監控服務品質
- 控制服務間的通路路由
- 應對服務故障
- 在服務間通信之間進行加密
- 通路控制和頻率限制
分布式跟蹤和業務緊密相關，無法做到無侵入。
這其中最大的優勢就是無侵入，這意味着給試用流程留下了全身而退的機會，如果沒有復原的能力，上述種種能力都是空中樓閣。
Istio 的問題
- API 穩定性可能是最嚴重的一個問題。目前最成熟的功能組别應該是流量控制，其版本号也僅是 v1alpha3，一般來說，alpha 階段的産品，代表着不提供向後相容的承諾，流量控制 API 在從 v1alpha2 更新為 v1alpha3 的過程中，API 幾乎全部改寫，使得很多早期使用者的精力投入付諸東流。核心功能尚且如此，遑論相對比較邊緣的 Mixer、Citadel 以及 Galley 元件的相關内容。
- 釋出節奏和釋出品質的問題也相當嚴重。Istio并不算長的曆史中，出現了多次版本撤回、大版本嚴重延期、釋出品質低下無法使用以及 Bug 反複等狀況，這無疑會讓每次更新嘗試都充滿了不确定性，會很大的影響生産過程的連續性。
- Mixer 是一個問題焦點，其資料模型較為複雜，并且集中了所有應用的流量于一點，雖然其中加入了各種緩存等技術來降低延遲，但是其獨特地位決定了 Mixer 始終處于一個高風險的位置。同時其 API 結構稍顯混亂，重構風險較大。
- Pilot的性能方面也經常為人诟病，雖然經過幾次更新，但是即使是 1.0 之後，還是出現了兩次 Pilot 在叢集中服務/Pod 過多的情況下會超量消耗資源的問題。
- 安全、實體機和虛拟機的支援以及網格邊緣通信這三組功能，目前使用者較少，品質尚不明确。
- 最後就是 Istio 的 Sidecar 注入模式，這種模式一定會增加服務間調用的網絡延遲，在目前階段這是一個痼疾，Sidecar 的固定延遲和 Mixer 的不确定行為相結合，有可能會産生嚴重後果。
這裡提出的隻是被反複提及，或者經常出現在 Issue 清單中的問題，由釋出問題來看，面臨的風險可能遠不止這些。
Istio 試用工作的理由和規劃
試用 Istio，首先應該确定，該技術的采用，是否能夠在可控的風險和投入下，得到有效的産出。
- 微服務模式的推進，必須要有相應的管理能力，Service Mesh 目前看來，是一個确定有效的方案，如果不是 Istio，也會有其它替代産品出現。
- 目前看來，Istio 是 Service Mesh 的标志性産品，有一定可能性成為事實标準。
- 提供了衆多開箱即用的豐富特性，能夠迅速進入 Service mesh。
- 最後是無侵入的優勢：如果試用失敗，可以退回，控制損失範圍。
Istio 的多數功能，在無需對程式進行修改（分布式跟蹤除外）的情況下，能對應用提供如此之多的功能支援，無疑是非常有吸引力的。Istio 的功能集，完全可以說是服務網格技術的典範。一旦确認現有環境有可能支援 Istio 的運作，并且在合理的投入下能夠獲得有效益的産出，那麼這個試用就是有價值的。
結合 Istio 的現狀，以及多數企業的運作狀态，個人淺見，Istio 的應用在現階段隻能小範圍試探性地進行，在進行過程中要嚴格定義試用範圍，嚴控各個流程。 按照個人經驗，筆者将試用過程分為如下 4 個階段。
- 範圍定義：選擇進入試用的服務，确定受影響的範圍，并根據 Istio 項目現 狀決定預備使用的 Istio 相關功能。圍繞這些需要，制定試用需求。
- 方案部署：根據範圍定義的決策，制定和執行相關的部署工作。其中包含 Istio 自身的部署和業務服務、後備服務的部署工作。
- 測試驗證：根據既有業務目标對部署結果進行測試。
- 切換演練：防禦措施，用于在業務失敗時切回到原有的穩定環境。
Istio 的試用步驟
确定功能範圍
在 Istio 中包含了非常多的功能點，從原則上來說，各種功能都是有其實際作用的。然而，Istio 作為一個新産品，本身也有很多不足，我們在 10.1 節中也提到了這些不足。
Istio 提供的衆多功能對每個公司或者項目，都會有不同價值。我們在采用一個新系統時，首先要考慮的就是成本效益問題，這裡的“價”代表着 Istio 帶來的風險、對業務應用的影響，還包括可能出現的服務停機等問題。
可以根據成本效益，做出一個優先級别清單。在制定了優先級清單之後，就可以根據這一清單，結合項目的實際需求，按照效果明顯、功能穩定、部署成本低、少改造或者不改造的标準來進行選擇，最終确定待測試的功能點。
在標明功能點之後，應該遵循目前已有的 Istio 文檔，對各個功能點進行單項測試和驗證，以確定其有效性。并通過官方 GitHub 的 Issue 清單及讨論組内容，了解現有功能是否存在待解決的問題，以及相關的注意事項等。
選擇試用業務
在試用功能點确定之後，就要選擇用于試用的業務應用了。Istio 作為一個相對底層的系統，其部署和調試過程必然會對業務産生一定的影響，在運作階段又有 Sidecar 和各個元件造成的損耗，如下所述：
- 所有網格之間的通信都要經過 Sidecar 的中轉，會造成大約 10 毫秒的延遲。
- Pilot 對叢集規模敏感，叢集中的服務數量、Pod 數量都可能對 Pilot 造成較大影響，也會影響到 Istio 各種規則向 Pod 的傳輸過程。
- 所有流量都會經由 Mixer 處理，也有造成瓶頸的可能。
- 安全功能設定不當同樣會造成服務中斷。
如上所述還隻是個概要，對業務來說，對這些風險都是必須正視并做好預案的。 為了避免引起過大損失，建議将如下标準作為選擇試用服務的依據：
- 能夠容忍一定的中斷時間。
- 對延遲不敏感。
- 調用深度較淺。
- 能夠友善地復原和切換。
- 具備成熟完善的功能、性能和疲勞測試方案。
定義試用目标
按照現有業務的實際需要，對試用服務進行功能分析。和傳統的需求功能分析類似，要在該過程中明确一些具體的需求内容。
- 環境需求：申請符合 Istio 運作以及業務要求的叢集以及資源。
- 功能性需求：在 Istio 的功能中選擇需要 Istio 為試用服務提供支撐的功能，應形成功能測試案例。
- 服務品質需求：根據現有業務的運作狀況，對服務品質提出具體要求，例如并發數量、響應時間、成功率等，應形成性能測試案例。
- 故障處理需求：對于試點應用發生故障時，如何在網格和非網格版本的試用 服務之間進行切換以降低故障影響，應形成故障預案。
Istio 部署
首先是基本環境的準備，按照前面提到的環境需求，複查叢集環境。 如果是内網部署，應該部署内網可達的私有鏡像庫，推送全部所需的鏡像，并利用 Helm 變量設定合理的鏡像位址。 接下來根據試用需求，利用 Helm 對 Istio 部署進行調整，這方面的調整主要分為兩類——資源配置設定和功能裁剪。
- 資源配置設定方面，在官方提供了資源配置設定建議可以參考，利用 Helm value 進行設定即可。
- 功能裁剪，同樣需要對 Helm value 進行設定，關閉不需要的功能。
後備業務部署
在進行試用應用的注入之前，首先應該部署一組備份服務，這組服務需要和整體服務網格進行隔離。這一組備份服務應處于待機模式，以備網格版本的應用在出 現故障時，進行整體切換。基于這一點考慮，負載均衡等前端控制設施也應齊備。
試用業務部署
接下來要把試用服務部署到網格之中，同其他 Kubernetes 一樣，網格應用的部署也是從 YAML 代碼開始的。原有應用的部署代碼需要根據 Istio 标準進行複核，檢查其中的端口命名、标簽設定。
除了待注入的應用清單檔案，還應該為每個部署單元都提供預設的 VirtualService 和 DestinationRule，建立基本的路由關系，提供一個路由基準，友善在路由調整過程中進行對比。
然後根據在前面制定的具體網格需求清單，逐個編寫所需的路由、規則等方面的配置内容。 在這些都完成之後，就可以按照順序逐個送出部署了。
監控告警部署
在試用服務部署之後，就有更多的項目可以監測了，這裡建議将其自帶的 Prometheus 進行變更，連接配接到能夠有效發出告警的 Alert manager 元件上，并根據試用業務的服務品質、Istio 元件進行告警設定。
驗證測試
根據功能需求對試用服務進行功能測試，在測試通過之後進行性能和疲勞測試，觀察各方面的性能名額是否符合，如果性能出現下滑，則可以嘗試擴容，提高資源配置設定率。
關鍵元件的性能下降有可能是 Istio 自身的問題，應檢查社群 Issue 或提出新的 Issue。
此處是一個關鍵步驟，如果測試方案不符合實際情況或者預期目标無法達到， 則強烈建議放棄試用。
切換演練
在功能和性能測試全部通過之後，就應該進行試用服務和後備服務之間的雙向切換的演練，在雙方切換之後都應該重複進行驗證過程，防止故障反複。 切換演練是試點應用的最後一道保險，在網格嚴重故障之後能否迅速恢複業務，全靠這一步的支援，是以同樣需要認真對待。
結論
雖然很多企業服務團隊的研發能力不高，無法像一些高水準技術團隊一樣，對開源軟體進行因地制宜的适應性修改。然而需要了解的重要一點是，不少軟體項目其實并非為世界級的流量而生的，網際網路 Say No 的時候，其它場景中未必無法接受。通過細緻的調查研究，詳盡的方案設計，謹慎的執行和驗證之後，Service Mesh 或者其它的新技術的試用決策都是可以進行嘗試的，甚至也是有可能是以獲利的。
PPT 下載下傳和視訊位址
點選頁面回顧按鈕，回顧當天所有講師分享：
https://tech.antfin.com/activities/72延伸閱讀