1. 程式人生 > >China .NET Conf 2019-.NET技術架構下的混沌工程實踐

China .NET Conf 2019-.NET技術架構下的混沌工程實踐

這個月的8號、9號,個人很榮幸參加了China.NET Conf 2019 , 中國.NET開發者峰會,同時分享了技術專題《.NET技術架構下的混沌工程實踐》,給廣大的.NET開發小夥伴介紹混沌工程和高可用性改造實踐。會後大傢伙聚餐的時候,陳計節老師建議大家將各自的議題分享到社群,分享給大家。因此,今天和大家分享我的技術專題《.NET技術架構下的混沌工程實踐》。

整個專題主要分為四個部分:

  1. .NET分散式、微服務架構下的高可用性挑戰
  2. 混沌工程簡介
  3. .NET混沌工程的實踐和成果分享
  4. 展望和規劃

一、.NET分散式、微服務架構下的高可用性挑戰

目前,我們特來電的技術架構是分散式、微服務化的,線上超過1000臺Server,高可用保障壓力很大:

  • 系統7*24小時執行,不允許宕機,一旦宕機出問題,直接影響全國人民出行;
  • 系統SLA要求99.95% ,全年可宕機時間只有4.38小時;
  • 服務呼叫鏈路越來越長,依賴越來越複雜,某個環節出問題,都有肯能導致服務雪崩、大規模宕機;
  • 線上遭遇:網路抖動、記憶體洩露、執行緒阻塞、CPU被打爆、 資料庫被打爆、中介軟體宕機等棘手問題;
  • 每天上百次釋出更新,系統高可用性保障壓力非常大;

一張全鏈路監控圖可以反映我們系統的複雜:

 

例如主機CPU被打爆的問題,線上經常會遇到:

經歷了線上各種高可用性問題後,我們做了很多反思和總結:

系統在實現了分散式、微服務化之後,我們到底有多少把握來保證系統的正常執行?  

如果出現問題,整個分散式系統會變得非常“混亂”,甚至會引發系統的大規模宕機。

因此,我們有必要在線上事故出現之前,提前識別出系統有哪些弱點和問題,統一管控系統的固有混沌。

這套管控系統固有混沌的方法和體系,就是我們今天要介紹的主角:混沌工程。

二、混沌工程簡介

1. 什麼是混沌工程?

通過受控的實驗,掌握系統執行行為的過程,稱為混沌工程。

    混沌工程的典型實踐:Chaos Monkey
     一隻搗亂的猴子,在你的系統裡面上蹦下竄,不停搗亂,直到搞掛你的系統。

    

2. 為什麼需要混沌工程?

   混沌工程可以提升整個系統的彈性。
   通過混沌實驗,可以發現系統脆弱的一面,主動發現這些問題,並解決這些問題。

3. 混沌工程怎麼做?

   混沌工程的一般實施步驟:

1 選擇系統正常執行狀態下的可度量指標,作為基準的“穩定狀態”
2 混沌實驗分為實驗組和對照組,都能保持系統的“穩定狀態”
3 對實驗組注入混沌事件,如服務不可用、中介軟體宕機等混沌事件
4 比較實驗組和對照組“穩定狀態”的差異

   如果混沌實驗前後系統的“穩定狀態”一致,則可以認為系統應對這種混沌事件是彈性的、高可用的。
   相反的,如果打破了系統的穩定狀態,我們就找到了一個系統弱點,然後儘可能地解決它,提升系統的高可用性。

4. 實施混沌工程的推薦原則

  • 明確系統穩定執行的狀態(指標)
  • 混沌事件必須是現實世界可能發生的(合理的)
  • 在生產環境進行混沌實驗 :生產環境可以真實地反映系統的穩定性
  • 持續整合:線上應用每天都在更新,通過持續整合的方式可以不斷髮現問題、解決問題。
  • 最小化影響範圍:線上進行混沌實驗,必須可控,必須確定混沌實驗的最小化影響範圍。

   這裡大家會問:在生產環境上搞混沌實驗,能行嗎?

5. 現實中的混沌工程

  生產環境必須以穩定為前提,因此推薦O2O模式的混沌實驗:即線下演練、線上驗證
  在系統未經過大規模高可用性改造之前,建議首先進行全面的線下演練:

   

   那麼, .NET技術架構下的混沌工程怎麼做?

三、.NET混沌工程的實踐和成果分享

  我們線上系統主要用到了以下.NET技術棧和開源技術:

  • ASP.NET MVC
  • 基於ASP.NET Core的Web執行框架-WRF
  • 基於ASP.NET Web API的分散式服務閘道器-SG
  • 基於.NET RPC通訊技術的分散式微服務平臺-HSF
  • 基於RabbitMQ和Kafka的訊息應用中心-MAC
  • iBatis.NET & Entity Framework
  • RabbitMQ & RabbitMQ Client for .NET
  • Kafka & Confluent.Kafka
  • Redis
  • Nginx

    在上述.NET 技術架構下,我們梳理了大量的混沌工程事件:

    

    

    

     通過大量的混沌實驗,我們逐步建立了提升系統高可用性的方法論和體系:

     

     .NET技術架構下的高可用性改進-依賴治理、容錯降級     

      業務場景:
      隨著業務複雜度的上升,服務呼叫鏈路越來越長,鏈路上存在大量不可控的因素:      

    • 網路抖動,導致服務異常
    • Redis、MQ、DB等中介軟體不可用,導致服務超時、異常
    • 依賴的服務不可用,直接影響服務呼叫方  

          

     如何應對:識別強弱依賴,對弱依賴進行降級,對強依賴有限降級     

    • “使用者有感知” 是強依賴
    • “使用者無感知” 是弱依賴
    • 故障發生時,核心業務有損失的是強依賴,無損失的是弱依賴

           

      .NET技術架構下的高可用性改進-解耦/隔離       

      業務場景:
      核心業務的呼叫鏈路很長,整個鏈路上包含主流程和輔流程
      輔流程的重要性低,不能因為輔流程的不可用,影響了主流程。

      

       如何應對:

       

       .NET技術架構下的高可用性改進-超時治理        

       業務場景:
       對於服務超時,長時間等待會影響使用者體驗,併發大時還可能造成執行緒池被打爆。
       同時可能產生服務級聯反應,導致大範圍服務雪崩。

              

        應對方案:
        超時時間設定:服務剛上線時,可以根據壓測情況預估一個值;
        服務上線後再根據實際監控進行修改,比如設定99%的請求響應時間為超時時間。
        超時後的處理策略:
        如果不是核心服務,可直接超時返回失敗。
        如果是核心服務,可以設定相應的重試次數.         

        示例:
        配置服務超時時間
        設定Http請求超時時間
        設定資料庫連線超時、SQL執行超時
        程式碼控制超時時間(例如:Polly的Timeout策略)

      .NET技術架構下的高可用性改進-重試補償         

        業務場景:
        實際線上應用中,假如遇到網路抖動、釋出重啟、資料庫阻塞超時等情況,都有可能引起服務呼叫失敗。         

        應對方案:
        通過失敗重試、異常後的補償,儘可能地保證業務可用。
        重試情況下:業務要保證冪等性、保證最終一致性。        

        示例:
        服務失敗重試策略
        訊息傳送、消費失敗重試、補償
        程式碼層面失敗重試補償(例如:Polly的Retry策略)

      高可用改進還有很多技巧,這裡不一一詳細給大家贅述了。

      通過對系統進行全面的高可用性改進,提升了我們對線上系統的信心!

四、 展望和規劃

    2019年,我們啟動了混沌工程實踐,逐步建立了混沌工程的自有方法論和體系,通過近一年的混沌工程實踐,混沌工程文化逐漸被開發團隊所認可。目前,混沌工程已經逐步過渡到線上生產環境進行(這來自於足夠的信心和把握)。但這只是一個起步,未來:

  • 正式的混沌工程團隊:通過多團隊配合、保障資源的持續投入
  • 覆蓋所有的關鍵核心應用:讓混沌工程深入到每個產品
  • 堅持O2O混沌工程實踐:線下演練、線上驗證,更可控
  • 混沌事件注入工具:ChaosBlade for .NET,工具讓混沌工程更高效
  • 持續的混沌實驗:持續進行、持續改進

    目標:通過混沌工程揭示問題、解決問題、形成閉環,不斷提升系統高可用性。

以上是本次China.NET Conf 2019的技術專題,分享給大家。

 

 

周國慶

2019/11/15

 

&n