這個月的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