在近日舉行的QCon倫敦大會上，Rachel Reese聲稱，世界天生就是混亂的，我們應該有計劃并測試我們的系統，確保它能夠處理這種混亂。他描述了Jet這家于2015年7月成立的電子商務公司是如何使用微服務和混沌工程的。

Reese強調，測試微服務在環境中的交互極其重要，即使所有組件都經過了測試，但這并不意味著他們之間的交互是可靠的，也不意味著它們可以一起用于生產環境，所有這些都必須經過測試。她將Jet稱為一家“為正確的工作選擇正確的工具”的公司，對她而言，混沌測試就是其中一個正確的工具。

Reese將微服務定義為符合單一職責原則（SRP）的應用程序，但是在服務層，由于他們以函數的方式看待微服務，所以它有一個輸入，并產生一個輸出。她認為，使用微服務的好處包括簡化擴展性、獨立發布、均勻分布的復雜性。Jet在10到15個團隊中運行著大約400到1000個微服務，主要是用F#（一種函數優先的編程語言）編寫的。

Reese指出，混沌工程不是為了有趣而破壞代碼，相反，她將其定義為：

在分布式系統上做對照實驗，幫助建立對系統承受不可避免的故障的能力的信心。

參照混沌原則，Reese定義了混沌工程的四個步驟：

1. 定義“正常”（系統的正常狀態）；
2. 假定“正常”會在對照組和實驗組中持續；
3. 引入混沌：服務器崩潰、硬盤異常、網絡連接中斷等；
4. 查找對照組和實驗組行為上的差別。

更準確地講，這意味著：

• 建立假設，定義系統的正常行為和狀態，如吞吐量、延遲等；
• 真實世界的不同事件、流量峰值以及其他可以導致混沌的東西；
• 在生產環境中運行實驗，確保測試的真實性；
• 自動化實驗，讓其連續運行。

Reese發現，混沌工程有許多好處，包括：

• 白天測試導致系統中斷，就不用在凌晨3點修復問題；
• 工程師在設計過程中開始考慮故障；
• 防止系統后續出現中斷，讓系統更健康。

根據他們的經驗，Reese指出，他們尚還沒有在生產環境進行測試。作為一家初創企業，他們的主要目標是推出正確的東西。現在，他們白天所有時段都會進行隨機的QA測試。

其中一場對他們而言最“有趣的”的災難發生在數月之前，他們的手動測試人員發現，他們的搜索引擎宕掉了，導致了下游的一連串問題。這次故障的原因是混沌測試錯誤地重啟了搜索引擎。就靠這么一個故障，他們發現了五六個不同的問題。

Reese總結到：

如果可靠性很重要，那么你就應該為此開展測試。

Reese的講稿已經提供給QCon的參會者，稍后將提供給InfoQ的讀者。

查看英文原文：Chaos Testing of Microservices