混沌工程實踐指南——如何實施一次「完美」的冷啟動

打開今日頭條，查看更多圖片

中亭，阿里巴巴高可用架構團隊高級技術專家，多年穩定性產品研發、架構演進、常態&大促保障經驗，故障演練平台MonkeyKing創始人，雲產品AHAS技術負責人，混沌工程佈道師。

一、概述

在傳統的定義中，冷啟動是電腦（或系統）的一種啟動方式。就是切斷電腦的電源，重新啟動，一旦冷啟動，內存的東西全部丟失，重新檢測硬體，再依啟動操作系統。

在IT領域中，冷啟動覆蓋啟動服務的動作到有健康流量流入的全部過程，經歷的階段可能有代碼的初始化、數據載入、連接建立、錯誤恢復、系統自檢等等。根據業務特點、系統規模、組織結構、技術能力等因素的影響，實現方式和結果可能會有所不同（比如：有狀態設計、無狀態設計、局部熱載入等）。但是不管是什麼類型的產品或團隊、採用哪種技術棧，發布變更都是最高頻發生和最容易出問題的生產環節。

實現一個高容錯的啟動方案，應該是每一個IT團隊的基礎要求。本文將會結合一些典型的技術架構，圍繞一些通用的故障場景，給出一些設計和驗證方法。

二、一些常見故障

在軟體工程中,單體應用的標準定義是用戶界面和數據訪問代碼被組合到一個程序的單層軟體應用程序。通常情況下應用程序對應的代碼由多個模塊或項目所組成，項目會被打包成為一個大包（如WAR包）進行管理和發布。在業務發展的早期，此種架構可以復用較多的系統代碼，提高研發效率。不過也存在著一些明顯的隱患：

代碼包含的項目越多，WAR包越大，系統冷啟動的時間就越長。隨著業務的發展，系統的啟動時間就會失控。如果健康檢查的重試間隔、閾值沒有及時作出調整，就很可能出現誤判的情況，出現大面積啟動失敗情況。在不恰當的發布場景下，可能會帶來容量問題。

應用啟動獲取配置的方式包括：環境變數、進程參數、本地文件、資料庫、配置中心等。隨著配置數量的膨脹，載入經常出現的問題可能有配置超時、配置亂序、配置過大、配置不完整的問題。其中配置超時和過大可能會導致系統物理啟動失敗或負載飆高。配置亂序或不完整，可能會帶來系統非預期的初始化，產生邏輯問題。

當遠程配置異常時，大部分系統設計都會走入容錯邏輯，如：載入本地容災數據確保應用啟動，或重試獲取遠程數據直至啟動成功或失敗。兩種方式都是較常用的策略，正常狀態下都可以正常工作。不過介於兩種方案之間仍存在一些灰色地帶。思考一下，當遠程數據訪問出現連接中斷、返回非預期的狀態碼（比如：500、404）或無法解析的報文時，系統是否會走入本地容災路徑？是否會因為判斷本地數據過期並重新載入數據，導致永遠無法正常啟動？

單體應用的設計理念中，應用程序負責不僅是對一個特定的任務,還要覆蓋每一步需要完成特定功能。因此系統啟動設計的時候，經常性會把一些沒有正確處理的任務進行載入和處理。如果載入和處理過程被打斷，且載入和處理過程不具備冪等性，那麼一個直接結果是很多異常任務永遠不會被處理。

2014年，Martin Fowler與James Lewis共同提出了微服務的概念，定義了微服務是由以單一應用程序構成的小服務，自己擁有自己的行程與輕量化處理，服務依業務功能設計，以全自動的方式部署，與其他服務使用HTTP API通訊。同時服務會使用最小的規模的集中管理 (例如Docker) 能力，服務可以用不同的編程語言與資料庫等元件實作。微服務賦予了研發團隊協同開發能力，改變了複雜軟體系統的交互方式。單體應用可能出現的故障，微服務都會遇到。同時因為分散式調用的引入，還會帶來一些新的問題。下面整理了一些常見故障的背景和規避原則：

隨著服務拆分，應用啟動依賴的外部服務也會增多，從系統設計的角度，要儘可能的減小因為某個依賴的服務異常而導致系統無法啟動的情況。比較理想的情況應該是應用可以正常啟動，但是提供的服務能力是有部分缺失的（即：啟動弱依賴、運行態強依賴）。啟動強依賴的另外一個痛點是新建完整站點時，會出現循環依賴或必須按照特定順序建站的問題。

應用程序不可避免會依賴其他三方服務的Client，Client中可能會引入諸如緩存前置、業務容錯的邏輯。此時需要關注超時閾值、錯誤重試、同步處理等邏輯，多數冷啟動故障都是因為這些點沒有處理好。還要重點確保引入的代碼塊中不存在諸如"System.exit(status)"這樣的代碼。不然大面積觸發此種異常時，重啟已經無法恢復系統的正常運行。

先完成服務自檢，再註冊服務

當冷啟動過程中，如果服務還沒有完全初始化成功，就有請求進來了，這時候的處理結果就是失敗。

針對服務上線問題，服務框架的一個做法是在ProvierBean在初始化階段都不註冊到註冊中心，等Spring容器把所有的Bean初始化成功後，再統一註冊服務。

延伸一下，如果應用還有很系統性或業務性的操作，比如：載入數據、預熱緩存、開關初始等。建議提供一個冪等調用的HTTP介面，可以被啟動腳本調用做檢查，判斷是否繼續後續Web伺服器的啟動。

當重啟一個服務的時候，需要經過關閉服務和啟動服務兩個階段。啟動服務階段如上一個章節所述。關閉服務階段會導致上游系統調用產生大量失敗，並帶來一些業務波動。一種失敗原因是請求還在服務端處理沒有寫回給客戶端，另一種是上遊客戶仍在請求開始重啟的服務端。

服務框架對於優雅下線的做法是通過JDK的ShutdownHook來實現的，會經歷從註冊中心註銷服務、禁止接受新請求、停止創建外部調用等階段。通過延遲一定時間和上遊客戶重試的方式減小業務的影響。

每一個大型分散式微服務系統都應該有一個配置中心，配置內容可能覆蓋了業務開源和容災規則，其重要性無需多言。即便如此，微服務應用的視角中，對於配置中心必須是弱依賴、可緩存、可容災的。當系統的部署環境和節點規模變大之後，在一些極端場景很容易出現配置不一致的問題（比如：新老版本、局部容災等），進而引發嚴重的業務或可用性問題。因此於配置不一致的監控和覆蓋就顯得尤為重要。可以通過巡檢系統或日誌監控的方式去校驗每一次變更的動作，提高配置不一致發現的時效。

百分百完美的方案是不存在的，因為不同的架構和階段採用的方案都是有取捨的。不過做到相對"完美"還是十分有可能的。可以結合混沌工程[1]的思想，通過模擬一些失控的情況來驗證當下實施方案是否與預期一致，提前發現可能存在的風險。

應用高可用服務（AHAS）是一款能夠幫你快速提升高可用能力的SaaS化雲服務，提供提供架構感知、故障演練和限流降級的三大能力。目前公測期間，戳一下免費開通[2]。下面圍繞"杜絕啟動強依賴"這條設計規則，通過一個實際的例子來介紹如何通過應用高可用服務（AHAS）來輔助實施一次"完美"的冷啟動。

開通AHAS的服務並安裝AHAS探針（整個按照過程無侵入、白屏化操作），架構感知模塊能夠自動感知您的系統架構，以可視化的方式直觀呈現應用對基礎架構的依賴關係，以及組件間的依賴關係。

完成AHAS的安裝後，實施一次正常的發布行為，系統的依賴、網路調用就會按照時間的維度完整的錄製下來。如下圖：

點擊發布的服務節點（本例中是visits這個服務），可以看到詳細的調用關係。其中與discovery-service（註冊中心）這個服務有依賴關係，並且通信的埠是8761。

從"杜絕啟動強依賴"這條原則出發，當discovery-service出現異常時，應用是要具備弱依賴啟動能力的。因此我們模擬一個調用discovery-service超時的情況。我們配置的方案是visits主機範圍，所有遠程訪問8761埠的請求都延時5000ms。（一些通用的服務都有自己的固定埠，可以通過模擬指定埠的網路延遲來模擬服務或網路故障，一些常見TCP服務埠列表可以參考：List of Well-Known TCP Port Numbers）[3]

在故障模擬命令下達之後，就需要業務觀察系統的表現是否符合預期。觀察的點可以包括：系統監控、業務監控、是否觸發報警等，可以通過雲監控、業務實時監控服務 ARMS等雲服務配合觀察。

五、小結

混沌工程是在分散式系統上進行實驗的學科, 混沌工程實踐的其核心思想是通過實驗和探索，來逐步增強對系統的信心。AHAS本身也提供了豐富的故障能力。

如果你對提升穩定性有一定訴求，可以結合文章中介紹設計理念來做一些試驗。免費試用

1. 百度百科：冷啟動 [4]

2. AWS Lambda [5]

3. https://medium.com/@nathan.malishev/lambda-cold-starts-language-comparison-?-a4f4b5f16a62

4. 圖片引用：Monolithic Application Architecture [6]

5. 圖片引用：Microservice Architecture [7]

6. 維基百科：微服務 [8]

7. Dubbo延遲發布 [9]

8. HSF優雅上線(內部) [10]

9. Dubbo優雅下線 [11]

文中鏈接：

[1] https://zhuanlan.zhihu.com/p/52505917

[2] https://common-buy.aliyun.com/?source_type=zhihucoldstart&spm=5176.cnahas.0.0.41734bb7qvKk6B&commodityCode=ahas_001#/open

[3] https://www.webopedia.com/quick_ref/portnumbers.asp

[6] http://link.zhihu.com/?target=https%3A//www.thesunflowerlab.com/blog/choose-microservices-monolithic-application-architecture/monolithic-application-architecture-min/

本文轉自知乎專欄應用高可用。

參考閱讀：

技術原創及架構實踐文章，歡迎通過公眾號菜單「聯繫我們」進行投稿。轉載請註明來自高可用架構「ArchNotes」微信公眾號及包含以下二維碼。

高可用架構

改變互聯網的構建方式

長按二維碼 關注「高可用架構」公眾號

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！