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

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

整個專題主要分爲四個部分：

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

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

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

• 系統7*24小時運行，不容許宕機，一旦宕機出問題，直接影響全國人民出行；
• 系統SLA要求99.95% ，整年可宕機時間只有4.38小時；
• 服務調用鏈路愈來愈長，依賴愈來愈複雜，某個環節出問題，都有肯能致使服務雪崩、大規模宕機；
• 線上遭遇：網絡抖動、內存泄露、線程阻塞、CPU被打爆、 數據庫被打爆、中間件宕機等棘手問題；
• 天天上百次發佈更新，系統高可用性保障壓力很是大；

一張全鏈路監控圖能夠反映咱們系統的複雜：

 

例如主機CPU被打爆的問題，線上常常會遇到：

經歷了線上各類高可用性問題後，咱們作了不少反思和總結：

系統在實現了分佈式、微服務化以後，咱們到底有多少把握來保證系統的正常運行？  

若是出現問題，整個分佈式系統會變得很是「混亂」，甚至會引起系統的大規模宕機。

所以，咱們有必要在線上事故出現以前，提早識別出系統有哪些弱點和問題，統一管控系統的固有混沌。

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

2、混沌工程簡介

1. 什麼是混沌工程？

經過受控的實驗，掌握系統運行行爲的過程，稱爲混沌工程。

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

2. 爲何須要混沌工程？

混沌工程能夠提高整個系統的彈性。
經過混沌實驗，能夠發現系統脆弱的一面，主動發現這些問題，並解決這些問題。

3. 混沌工程怎麼作？

混沌工程的通常實施步驟：

1 選擇系統正常運行狀態下的可度量指標，做爲基準的「穩定狀態」 2 混沌實驗分爲實驗組和對照組，都能保持系統的「穩定狀態」 3 對實驗組注入混沌事件，如服務不可用、中間件宕機等混沌事件 4 比較實驗組和對照組「穩定狀態」的差別

若是混沌實驗先後系統的「穩定狀態」一致，則能夠認爲系統應對這種混沌事件是彈性的、高可用的。
相反的，若是打破了系統的穩定狀態，咱們就找到了一個系統弱點，而後儘量地解決它，提高系統的高可用性。

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

• 明確系統穩定運行的狀態（指標）
• 混沌事件必須是現實世界可能發生的（合理的）
• 在生產環境進行混沌實驗 ：生產環境能夠真實地反映系統的穩定性
• 持續集成：線上應用天天都在更新，經過持續集成的方式能夠不斷髮現問題、解決問題。
• 最小化影響範圍：線上進行混沌實驗，必須可控，必須肯定混沌實驗的最小化影響範圍。

   這裏你們會問：在生產環境上搞混沌實驗，能行嗎？

5. 現實中的混沌工程

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

   

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

3、.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策略）

      高可用改進還有不少技巧，這裏不一一詳細給你們贅述了。

      經過對全面的高可用性改進，提高了咱們對線上系統的信心！

4、 展望和規劃

    2019年，咱們啓動了混沌工程實踐，逐步創建了混沌工程的自有方法論和體系，經過近一年的混沌工程實踐，混沌工程文化逐漸被開發團隊所承認。目前，混沌工程已經逐步過渡到線上生產環境進行（這來自於足夠的信心和把握）。但這只是一個起步，將來：

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

    目標：經過混沌工程揭示問題、解決問題、造成閉環，不斷提高系統高可用性。

以上是本次China.NET Conf 2019的技術專題，分享給你們。

 

 

周國慶

2019/11/15