企業服務行業如何試水Istio|ServiceMeshMeetup分享實錄

s潘潘發表於2019-01-11

崔秀龍,HPE 軟體分析師,Kubernetes 權威指南作者之一,Kubernetes、Istio 專案成員。
本文根據崔秀龍在 2019 廣州 Service Mesh Meetup#5 分享整理,完整的分享 PPT 獲取方式見文章底部。
本文內容收錄在崔秀龍的新書:《深入淺出 Istio – Service Mesh 快速入門與實踐》的第十章,該書將於近期由博文視點出版發行,敬請關注。

1.jpg

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,首先應該確定,該技術的採用,是否能夠在可控的風險和投入下,得到有效的產出。

  1. 微服務模式的推進,必須要有相應的管理能力,Service Mesh 目前看來,是一個確定有效的方案,如果不是 Istio,也會有其它替代產品出現。
  2. 目前看來,Istio 是 Service Mesh 的標誌性產品,有一定可能性成為事實標準。
  3. 提供了眾多開箱即用的豐富特性,能夠迅速進入 Service mesh。
  4. 最後是無侵入的優勢:如果試用失敗,可以退回,控制損失範圍。

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 或者其它的新技術的試用決策都是可以進行嘗試的,甚至也是有可能因此獲利的。
2.jpg

PPT 下載和視訊地址
點選頁面回顧按鈕,回顧當天所有講師分享:
https://tech.antfin.com/activities/72

延伸閱讀


相關文章