崔秀龍，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
延伸閱讀
- 螞蟻金服 Service Mesh 漸進式遷移方案|Service Mesh Meetup 實錄
- 螞蟻金服Service Mesh新型網路代理的思考與實踐 | GIAC 分享實錄
- 螞蟻金服 Service Mesh 實踐探索