這個月的8號、9號，個人很榮幸參加了China.NET Conf 2019 , 中國.NET開發者峰會，同時分享了技術專題《.NET技術架構下的混沌工程實踐》，給廣大的.NET開發小夥伴介紹混沌工程和高可用性改造實踐。會後大傢伙聚餐的時候，陳計節老師建議大家將各自的議題分享到社區，分享給大家。因此，今天和大家分享我的技術專題《.NET技術架構下的混沌工程實踐》。
先放幾張大會照片：
整個專題主要分為四個部分：
- .NET分佈式、微服務架構下的高可用性挑戰
- 混沌工程簡介
- .NET混沌工程的實踐和成果分享
- 展望和規劃
一、.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
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※帶您來了解什麼是 USB CONNECTOR ?
※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象
※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!
※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化
※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益