Spring Cloud 應用在 Kubernetes 上的最佳實踐 — 高可用(混沌工程)

簡介: 從上篇開始,咱們進入到了高可用的章節,上篇提到的熔斷能力,是歷年保障大促當天晚上整個系統不被洪峯流量打垮的法寶,本篇介紹的措施與熔斷有不同的地方?html

前言

從上篇開始,咱們進入到了高可用的章節,上篇提到的熔斷能力,是歷年保障大促當天晚上整個系統不被洪峯流量打垮的法寶,本篇介紹的措施與熔斷有不同的地方,一個是線上洪峯來臨時的保護措施,他更多的是流量低峯或者在專門的演練環境中,針對可能碰見的各種故障,採起演練的手段,來窺探對業務的影響。他的主要目的是讓咱們本身更加了解本身業務系統的薄弱環節,以便來對症下藥加強系統的高可用能力。本文重點介紹爲何要作混沌工程以及如何使用 ChaosBlade 工具和 AHAS 平臺快速實施混沌工程。git

 

爲何須要混沌工程

任何一個系統都會有不曾可知的故障出現,拿現代工藝已經很好的磁盤來講,有統計數據的磁盤最低的年故障率均可達到 0.39% 。即使是這麼底層基礎設施,也會有這麼高的不肯定性。尤爲當下大部分的服務形態都是分佈式架構,在分佈式系統架構下,服務間的依賴日益複雜,更很難評估單個服務故障對整個系統的影響;而且請求鏈路長,監控告警的不完善致使發現問題、定位問題難度增大;同時業務和技術迭代快,如何持續保障系統的穩定性和高可用性受到很大的挑戰。github

 

雲原生系統挑戰更大

談到雲原生,能夠說雲原生是一個理念,主要包含的技術有云設施、容器、微服務、服務網格、Serverless等技術。雲設施指公有云、專有云和混合雲等,是雲原生系統的基礎設施,基礎實施的故障可能對整個上層業務系統形成很大影響,因此說雲設施的穩定性是很是重要的。
容器服務的挑戰能夠分兩大類,一類是面向 k8s 服務提供商,服務是否穩定,另外一類是面向用戶,配置的擴縮容規則是否有效,實現的 CRD 是否正確,容器編排是否合理等問題。
分佈式服務的挑戰主要是複雜性,單個服務的故障很難判斷對整個系統的影響;service mesh,sidecar 的服務路由、負載均衡等功能的有效性,還有 sidecar 容器自己的可用性。
一些新興的部署模式的挑戰 如 serverless,如今基本上都是函數加事件的形式,資源調度是否有效,並且 serverless 服務提供商屏蔽了一些中間件,你能掌控的是函數這些服務,那麼你能夠經過混沌工程去驗證你函數調用的一些配置,好比超時配置,還有相關的一些降級策略,這些是否合理。
以上技術都有相同的共性,好比彈性可擴展、鬆耦合、容錯性高、還有一些易於管理,便於觀察這些特性。因此說在雲原生時代,經過混沌工程能夠更有效的推動系統的「雲原生」化。



數據庫

 

每一個職位都須要懂混沌工程

混沌工程是一種思想,他讓系統中的每一個參與者都學會去考慮一件事情:若是所依賴的某服務中斷了服務該怎麼辦?對於如下四類人羣而言,意義尤顯突出:小程序

  • 對於架構師來講,能夠驗證系統架構的容錯能力,咱們須要面向失敗設計的系統,混沌工程的思想就是踐行這一原則的方式。
  • 對於開發和運維,能夠提升故障的應急效率,實現故障告警、定位、恢復的有效和高效性。
  • 對於測試來講,能夠彌補傳統測試方法留下的空白,以前的測試方法基本上是從用戶的角度去作,而混沌工程是從系統的角度進行測試,下降故障複發率。
  • 對於產品和設計,經過混沌事件查看產品的表現,提高客戶使用體驗。因此說混沌工程面向的不只僅是開發、測試,擁有最好的客戶體驗是每一個人的目標 因此實施混沌工程,能夠提前發現生產環境上的問題,而且能夠以戰養戰,提高故障應急效率和可使用體驗,逐漸建設高可用的韌性系統。


 

混沌工程實操

在一次完整的演練流程中,須要先作好計劃,對相關的演練計劃有一個行爲預期;演練相關計劃的同時,咱們推薦的最佳實踐是須要配合有業務的自動化測試,每演練一次須要全方位的跑完自動化測試用例,這樣才能全面的瞭解真正的業務產生時對業務形成的影響:
1.png
架構

在上面的圖中描述了一次完整的故障演練須要通過的步驟,其中的最重要的一步的實踐是如何「執行預製混沌實驗」?由於這一步須要一個專業的工具,在業內目前最流行的工具是 Netflix 的 Chaos Monkey 和阿里巴巴開源的 ChaosBlade ,咱們接下來主要是介紹如何使用 ChaosBlade 來完成一次演練。負載均衡

 

使用 ChaosBlade 去作

ChaosBlade 是阿里巴巴一款遵循混沌實驗模型的混沌實驗執行工具,具備場景豐富度高,簡單易用等特色,並且擴展場景也特別方便,開源不久就被加入到 CNCF Landspace 中,成爲主流的一款混沌工具。目前包含的場景有基礎資源、應用服務、容器服務、雲資源等。ChaosBlade 下載解壓即用,能夠經過執行 blade 命令來執行雲原生下微服務的演練場景,下面是模擬 Kubernetes 下微服務中數據庫調用延遲故障。
2.jpeg
less

使用 AHAS 故障演練平臺去作

AHAS 故障演練平臺是阿里雲對外部用戶開放的雲產品,使用方式可參考官方文檔。其底層的故障注入能力大部分來源於 ChaosBlade 實現,另外一部分使用自身小程序擴展實現。AHAS 相比於 ChaosBlade,除了簡單易用的白屏操做以外,還實現了上層的演練編排、權限控制、場景管理等,並且還針對微服務新增應用維度演練,簡化演練成本,優化演練體驗。運維

3.png

結尾

混沌工程是一種主動防護的穩定性手段,體現的是反脆弱的思想,實施混沌工程不能只是把故障製造出來,須要有明確的驅動目標。咱們要選擇合適的工具和平臺,控制演練風險,實現常態化演練。阿里巴巴內部從最先引入混沌工程解決微服務的依賴問題,到業務服務、雲服務穩態驗證,進一步升級到公共雲、專有云的業務連續性保障,以及在驗證雲原生系統的穩定性等方面積累了比較豐富的場景和實踐經驗;這一些經驗沉澱咱們都經過開源產品以及雲產品 AHAS 一一對外輸出。分佈式

 

 

原文連接 本文爲阿里雲原創內容,未經容許不得轉載。

相關文章
相關標籤/搜索