從2005年Peter Rodgers博士提出微web服務，到2014年ThoughtWorks首席科學家Martin Fowler與James Lewis共同提出微服務概念至今已多年，這期間也是互聯網及互聯網+發展的高速期，消費市場變化莫測，消費者也變得越來越挑剔，很多公司和產品由于無法跟上市場的快速變化而紛紛倒下。越來越多的互聯網巨頭甚至傳統行業都開始對自己的遺留系統進行微服務改造，通過把系統拆分為更加靈活、有業務邊界上下文、松散耦合、可獨立部署的服務來應對快速變化的消費市場。

---

微服務架構面臨的挑戰

通常情況下，對于復雜業務或遺留系統，我們可以通過領域驅動設計(DDD:Domain-Driven Design)有效的解決限界上下文劃分、服務邊界定義以及組織結構調整等問題。除了這些，我們的開發團隊還面臨著其他的挑戰：復雜的分布式系統、數據一致性、容錯設計、限流設計、艙壁設計等問題。那么如此復雜的系統如何來保證系統“質量”呢？

長久以來，“測試金字塔”都是敏捷開發團隊保證項目交付質量的守則，而“測試金字塔”也確實從不同的維度涵蓋了方法調用、業務邏輯、用戶行為等方面。為了確保在進行復雜的調用和被調用時，服務之間能有一定程度上的一致性和快速反饋，我們會第一時間想到“契約測試”，“測試金字塔”也演化成了另一個樣子。

下圖，我們聚焦于微服務架構的業務服務層，在API測試之外在基礎服務的調用方和提供方之間增加了契約測試：

在微服務和前后端分離日趨流行的今天，契約測試的確可以在系統頻繁演進、重構的情況下保證服務間調用的可用性，而在“聚合服務層”通過API測試，可以暴露服務的組合過程中的問題。“盡早測試”可以讓團隊在初期發現更多的問題，降低后期修復成本，同時讓服務與服務之間具有“感知力”，任何與契約不符的業務變更都能被測試所感知。但是，既然契約測試是保證服務調用方和提供方的一致性，更直接說，是另一種對API的驗證，那么契約測試只能覆蓋到業務邏輯維度，如果想更好開發或改造微服務系統，就需要相對深入的了解微服務有哪些特性：

我們可以看到，這個簡單的圖中提到了一些微服務的特性(基于Spring Boot)：客戶端負載均衡、微服務容錯保護、API服務網關、分布式鏈路跟蹤等，我們不對這些進行解釋，但毫無疑問，契約測試無法覆蓋和測試到這些特性，同時也無法模擬例如網絡延遲、CPU滿載、請求異常、依賴故障、硬件故障等場景。對于一個不具備容錯能力的脆弱系統，即使我們可以對服務解耦、獨立部署，可對于用戶來說，體驗到的可能是一次又一次的“災難”。我們在質量活動中，總會聽到這樣的聲音：“不要動這個功能，會弄壞其他功能”、“客戶根本不會這么操作“、”這個缺陷沒有意義，你這樣會把系統弄掛”。我們總是擔心系統某些脆弱的環節掛掉，擔心某次操作讓整個系統宕機。遺憾的是，墨菲定律告訴我們，“如果事情有變壞的可能，不管這種可能性有多小，它總會發生。”

之前一個發生在身邊的項目經歷大概是這樣的：一個團隊提供基礎服務，并承諾服務的功能、性能、彈性都沒有問題。在集成聯調時，由于對認證服務的調用超過負荷，對整個服務系統造成阻塞，導致雪崩效應，幾乎所有客戶端應用大面積癱瘓；另一個案例，由于沒有對一個內容服務進行熔斷保護，導致整個網站首頁無法加載。而發生在世界各地的IT災難也不少，某航空公司，由于調度和跟蹤系統出現問題，導致去年6月份七天內將近3000個航班取消，損失3500萬美金；“信息災難總是普遍而沒有偏見地發生在各個領域和任何時候”。

既然我們沒有辦法避免災難的發生，最好的辦法就是“探索系統故障邊界，驗證系統災難恢復能力”。以往的“機房”時代的一些故障演練一般通過斷網、斷電模擬單點故障，來測試系統的恢復能力，而新型的分布式服務時代消除了單點故障，但也引入了更多復雜的問題，我們需要可靠性更強、容錯性和擴容性更高的系統。一種解決方案就是，我們需要一種有策略的、有方法的實踐方案對系統進行一定程度的“隨機破壞”，通過讓系統”感染“，來提升系統的”免疫力“。Netflix開發出Chaos Monkey來對系統進行隨機試驗來了解系統是否具有高可用性和容錯性，而由此便誕生出”混沌工程“。

---

什么是混沌工程？混沌工程原則是什么？

混沌工程是一種可試驗的、基于系統的方法來處理大規模分布式系統中的混亂問題。通過不斷試驗，了解系統的實際能承受的韌性邊界并建立信心，通過不同的試驗方法和目的，觀察分布式系統的行為和反應。一句話——以試驗的方法盡早揭露系統弱點。

混沌工程類似于“故障演練”，不局限于測試，而更像是工程實踐。為什么這么說，通常的測試用例會有“期望結果”和“實際結果”，通過將兩個結果比較，或者對用戶行為的預期，來判斷測試通過或失敗。而混沌試驗類似于”探索性測試“，試驗本身沒有明確是輸入和預期結果，通過對系統和服務的干預，來觀察系統的”反應“。我們將混沌工程原則融入在試驗過程中：在生產環境小規模模擬系統故障并定期自動化執行試驗，通過試驗結果與正常結果進行比對，觀察系統”邊界“。

通過“測試金字塔”和混沌試驗，從業務邏輯和系統高可用性兩個維度對微服務系統進行觀察和測試，兩種方案結合形成了一種更全面的實踐，我稱之為“服務級質量內建實踐”（BQIS——Build Qualify in Services）。不論企業是在微服務改造期還是中臺戰略部署期，混沌實踐能夠有效避免生產環境災難，提升系統的容錯率和可用性。

---

如何引入混沌工程？

在眾多服務化改造案例中，Netflix無疑是最成功的公司之一，該公司的很多試驗工具也都集成在Spring Cloud中，成為微服務框架的標準。而Chaos Monkey就是Netflix進行混沌試驗一個重要工具。作為國內的電商巨頭，服務化和中臺戰略的先行者阿里，近期也開源了他們自己的混沌試驗注入工具ChaosBlade。

“混沌工程”的引入受限于組織文化的接受程度，任何一種工程實踐和方法論的落地都無法一蹴而就。但是我們依然可以通過裁剪，在組織的安全范圍內進行逐步嘗試。不管是在線上環境還是測試環境，我們都需要先搞清楚，目前的混沌工具都為我們提供了哪些方法。

Spring Cloud是時下最流行的分布式微服務架構下的一站式解決方案之一，它方便快速的將Spring Boot的微服務有效的管理起來，并提供了包括負載均衡、全鏈路監控、服務網關以及眾多基于Netflix的開源工具。除此之外，鑒于Netflix在服務化演進中的成功案例，我們來了解下Netflix開源的混沌工程試驗框架Chaos Monkey究竟是什么？

在Spring Boot工程中，對需要進行試驗的服務application.yml文件的Chaos Monkey進行配置：

從配置文件中我們可以很容易看到，Chaos Monkey的三種襲擊方式——延時、異常和進程終止，同時我們也可以設置一個數值范圍，在對服務進行延時攻擊時生成隨機延時。默認攻擊方式為延時攻擊，當同時開啟異常攻擊時，進程攻擊則不會發生。Level：N表示第N個請求將被攻擊，N=1時，表示每個請求都會被攻擊，當同時開啟異常攻擊時，與N值無關，表示每個請求都將被攻擊。

ChaosBlade提供的攻擊也很豐富，使用方式對開發人員來說更友好：

通過命令行對CPU、硬盤、網絡進行試驗，也可以對相應的服務進行類似的例如延時攻擊試驗：

利用性能測試工具例如Jmeter或Gatling，對于API進行測試，例如POST /product?des=phone，通過性能測試報告對比API性能指標以及Hystrix監控分析相關服務“反應”，同時也可以通過Grafana和CloudWatch監控各個系統參數來和“穩定基線數據”進行比較和觀察。

---

混沌試驗示例

試驗一：

1.確定目標和范圍，觀察CPU利用率基線：（CPU平均利用率低于20%）

觀察API延時基線：（可以看到API-1和API-2平均延時低于300ms，API-3在300ms-700ms之間）

2.設計實驗數據和方案，我們對幾個實例進行CPU滿載攻擊:

觀察CPU利用率：

觀察API延時：(API請求延時變化明顯，API-3延時更加嚴重)

試驗二：測試服務熔斷機制

示例項目架構：Eureka服務發現注冊，一個PROVIDER-SERVICE且有兩個實例，一個CONSUMER-SERVICE，也可以通過zipkin之類的分布式跟蹤系統也可以看到服務調用關系。

1.對PROVIDER-SERVICE的實例2進行延時攻擊：

2.查看PROVIDER-SERVICE instance 2的延時是否生效。通過postman測試，可以看到API響應為30s：

3.客戶端請求相同的API：

觀察結果：負載均衡生效，請求成功，熔斷器關閉

4.殺掉instance 1之后請求相同API：

觀察結果：請求超時，熔斷器關閉

5.連續且請求相同API：

觀察結果：部分請求被立刻拒絕，加速服務失敗的判定，熔斷器開啟

6.殺掉instance 2請求API:

觀察結果：fallback機制生效，返回相應邏輯。

這些只是混沌工程的簡單使用方法，在實際項目中需要根據項目架構、業務復雜度、調用場景等設計試驗細節。

---

總結

從業務的橫切面到對微服務系統的縱切面觀察，“契約測試”固然重要，但并不能代表微服務質量保證的全部。“蠻力”可以從某種意義上解決很多問題，但并不能催化出更高階解決方案。同樣，也只有了解到微服務的實現方式和原理才能夠更好的理解系統并實施更有效的質量解決方案。

Netflix對混沌工程的成熟度從“復雜度”和“接受度”兩個方面給出了定義，可以看到，混沌工程或試驗不單單是方法論的引入，更是實踐上的滲透。用“Immersion”解釋更加確切，與敏捷實踐類似，這樣的“服務級質量內建試驗”對團隊來說開始無疑是一種挑戰，但隨著越來越多的問題更快、更早的可視化給團隊，使組織和客戶對我們構建和改造中的系統越來越有信心。通過小規模實踐到大規模改造，混沌工程不是為了測試，更不是為了引入工具， 混沌工程會像一種文化，將擴散于范圍更廣的團隊和組織。

總結

以上是生活随笔為你收集整理的一文理解微服务架构下的系统可用性如何保证？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。