企業服務行業如何試水Istio|ServiceMeshMeetup分享實錄
崔秀龍,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 實踐探索
相關文章
- 企業服務行業如何試水 Istio | Service Mesh Meetup 分享實錄行業
- Office 365 企業應用以及服務概覽 分享記錄
- 如何管理企業通訊服務?
- 企業網站如何做滲透測試服務網站
- 【服裝行業】服裝企業如何挑選erp行業
- 服務型企業的資源管理:助服務行業突破瓶頸!行業
- SaaS服務平臺為中小企業實現企業管理
- 虹科分享 | 虹科Redis企業版資料庫如何支援實時金融服務?Redis資料庫
- 【分享】企業如何進行施行規劃?
- AI加持,華為雲視訊服務助力企業直播行業AI行業
- 雲端儲存服務企業就在企業雲盤
- nginx服務企業應用Nginx
- SOA企業服務平臺
- 什麼樣的CRM系統適合服務行業企業行業
- 服務型企業如何使用飛項實現專案化管理?
- 企業網站安全滲透測試服務範圍網站
- 【分享】軟體測試企業面試試卷面試
- 企業IT服務管理解決方案
- 企業服務匯流排ESB
- Istio技術與實踐6:Istio如何為服務提供安全防護能力
- 淺談IDC企業如何有效提高售後服務
- 機器人客服是如何改變企業服務的機器人
- IT服務管理方案——金融行業行業
- 家政服務行業新模式行業模式
- 企業級nginx服務優化(一)Nginx優化
- 企業計算中的面向服務
- 中國新經濟行業年度榜重磅揭曉,企企通榮膺「2023年中國企業服務年度企業」行業
- 高德獲北京軟體和資訊服務業綜合實力百強企業
- 一場為企業服務開發的效能測試報告測試報告
- 打造企業級開源資料庫 服務關基行業核心系統資料庫行業
- 生活服務類行業用什麼企業郵箱好?看四個方面行業
- 企業服務 | 美國SaaS行業十年千億美元發展之路回顧行業
- 企業安全實踐經驗分享
- ERP服務中小企業:企業搭臺 軟體唱戲 (轉)
- 蘋果企業開發者賬號—如何建立WatchKit 服務證書蘋果
- HPE和英偉達如何為企業AI提供一條龍服務?AI
- 如何進行企業BI分析,該如何選企業BI系統
- 企業服務匯流排ESB已死! 服務網格上位