不久前，也就是11月16日，澳大利亞交易所（Australian Securities Exchange, ASX）上線了一個新的交易系統，但因為出現故障而被迫關閉。這是其 2016 年因硬件故障導致休市後最為嚴重的一次事故。
測試了一年多，結果上線當天就奔潰
11 月 16 日中午，ASX 發佈聲明表示當天將休市，於次日正常時間重新開放。交易所給出的關閉的原因是“侷限於單個交易指令中交易多種證券（組合交易）的軟件問題導致了市場數據不準確。”
ASX 此次升級的系統是由納斯達克開發的最新一代交易系統，目前在全球廣泛使用。為了保障上線後的安全運行，ASX、技術提供商納斯達克（ Nasdaq ）、客戶和第三方獨立專家已經做了一年多的廣泛測試，包括四次彩排。
微服務該如何測試？
看完了熱鬧，也看看咱們自己的系統。隨著以 Spring Cloud、Dubbo 為代表的微服務架構的流行，現在很多企業都採用了微服務架構。隨著服務越來越多，這些服務該如何測試？如何防範上面說的系統風險呢？
我們來捋一捋線上系統的風險，然後針對對應的風險來做對應的測試計劃。以如下架構為例：
一般來說，一個業務系統的風險來自兩處：
-
其一是變更帶來的風險，比如前面提到的新系統上線，或者我們給上圖中的購物車服務修一個 bug 等等。
-
其二是日常風險，比如底層的數據庫、主機、網絡等軟硬件問題。
如圖：
首先，對於變更帶來的風險，我們可以用如下的測試方式來驗證：
開發自測
開發完一個功能後，在提交測試前，開發人員需要盡力確保邏輯正確。比如 IDEA 或者 Postman 等工具都可以在本地測試 HTTP 接口，可以用來測試 Spring Cloud 服務:
對於 Dubbo 服務，由於是基於 tcp 協議的，開發就需要自己手寫一個簡單的 conumer 來驗證下服務的功能:
測試環境驗證服務
開發提交測試後，測試人員也需要對服務進行測試，確保該服務能正常工作。此時的測試，一般是在單獨的測試環境進行的。
對於 Spring Cloud 服務，測試人員可以在 Postman 等工具上，填寫目的 IP、url、參數來發起請求、驗證服務：
對於 Dubbo 服務來說，Dubbo Admin 也提供了服務測試功能，能夠在頁面上發起調用來驗證服務:
為了安全考慮，一般測試環境和公網、辦公網是隔離的，比如測試環境是阿里雲上一個單獨的 VPC。在這種情況下，如果需要用 postman 或者 dubbo admin，就需要打通網絡，比如專線等等。
如果你的服務接入了阿里雲的微服務引擎（Microservice Engine, 下文簡稱為 MSE），那麼就可以直接在 MSE 控制檯上發起測試請求，而不用理會網絡、權限等問題。
在 MSE 控制檯上，點擊 微服務治理中心->微服務測試->服務測試 菜單，選擇服務、方法後，就可以可在服務測試頁面選擇調用的節點、填寫調用的參數：
可以看到，對於入參中的複雜結構，比如圖中的 ProductItem，MSE 的服務測試功能還會生成示例數據，不用測試人員自己去翻代碼看如何填寫入參了。
填寫完成後，就可以點擊執行，來執行測試：
MSE 的服務測試功能也支持 Spring Cloud 接口的測試：
整體迴歸測試
在一個服務發佈後，需要測試人員驗證下比較重要的產品流程。比如架構圖中，從瀏覽商品到最後下單，中間調用了好幾個服務，測試人員需要整體來回歸一遍這個功能。
對於簡單的場景，在上線不頻繁的情況下，可以由測試人員手動完成整個流程，來看看整個業務流程是否正常。如果業務場景過於複雜，或者上線比較頻繁，那麼就需要自動化測試了。一般來說，各個公司都會自建 CI 系統來完成這種集成測試。
以 Jenkins 為例，需要：
- 搭建 Jenkins，配置好網絡等環境
- 創建測試腳本倉庫，並添加測試腳本
- 在 Jenkins 中配置 pipeline
- 執行並查看結果
同樣，這兒也要處理不同環境中的網絡問題，尤其是生產環境中的迴歸測試，更需要嚴格控制權限。
作為微服務整體的解決方案，MSE 也提供了自動化迴歸能力，能夠一鍵完成迴歸測試。首先，點擊 微服務治理中心->微服務測試->服務測試 菜單，新建一個自動化用例。每一步都可以調用一個 Spring Cloud 和 Dubbo 服務，可以添加斷言，來驗證測試是否通過：
點擊“立即執行”後，就在執行歷史頁面看到自動化迴歸的結果：
服務巡檢
除了變更帶來的風險之外，我們還需要應對日常風險，比如數據庫、網絡等組件出問題的情況。為了應對這些風險，我們需要定時驗證下這個服務能不能正常工作。通常，很多公司會使用 CI 系統的定時執行功能來構建一個定時執行的任務，如果任務執行失敗，會自動觸發告警。
以 Jenkins 為例，除了要搭建 Jenkins、寫測試腳本以外，還需要將 Jenkins 的任務設置為定時觸發：
比如，我們需要檢查商品服務是不是正常，就可以寫一個 Jenkins 定時任務來調用商品服務，定時檢查商品服務是否正常。當然，如果你的服務接入了 MSE 的話，也可以使用 MSE 提供的服務巡檢功能來定時檢查服務，如果不能按照預期工作，那麼就立刻發告警，通知告警的訂閱人。
點擊 微服務治理中心->微服務測試->服務巡檢 菜單，新建一個巡檢任務：
然後在列表點擊對應巡檢任務的開始按鈕，就能開始巡檢了:
如果巡檢出錯了的話，也會有對應的告警出來，以釘釘告警為例：
當然，這兒也支持設置郵件、短信告警。您可以根據服務重要程度來設置不同的告警接收方式。
服務壓測
系統的流量是在不斷變化的，為了應對可能出現的突發流量，我們需要及時評估系統壓力，決定是否擴容。另一方面，代碼也是不斷在修改的，所以也需要在每次上線前壓測下，看下代碼性能是不是有明顯惡化。在壓測方面，Apache JMeter 可以很好的測試 Spring Cloud 服務和 Dubbo 服務。
對於 Spring Cloud 服務，可以利用 JMeter 自帶的 HTTP 取樣器來壓測：
對於 Dubbo 服務的壓測，jmeter-plugins-for-apache-dubbo 新增了 Dubbo 取樣器，可以用來測試 Dubbo 服務。
只需要在 Dubbo 取樣器的配置頁面設置 registry、interface、method 等，就可以創建好壓測任務了。
創建好壓測任務後，通過 jemter 命令行即可執行壓測任務，並得到壓測結果：
jmeter -n -t ./rest-order-thread-group.jmx -l ./result.txt -e -o ./webreport
最後，如果您的服務已經接入了 MSE，那 MSE 也提供了開箱即用的壓測能力。
點擊 微服務治理中心->微服務測試->服務壓測 菜單，新建一個壓測場景，並配置好壓測參數：
您也可以在壓力配置選項卡上配置壓力模型等參數：
配置完成後，可以在對應壓測場景的詳情頁面開始壓測。也可以在壓測場景的詳情頁面查看結果，如果你需要更加詳細的結果，請點擊運行記錄的詳情按鈕。
總結
微服務的測試，不論是自己搭建測試系統、還是通過 MSE 來測試，都是為了應對變更帶來的風險和日常風險。只有瞭解風險，才能及時應對，保障服務高可用。
相比於自建測試系統，阿里雲產品 MSE 提供了同樣的功能，不僅避免了用戶自己處理不同網絡互通的問題，而且提供了完善的權限管理功能，確保線上穩定安全運行。除此之外，MSE 還提供了註冊配置中心託管、微服務治理等功能，歡迎體驗。
招賢納士
我們 Dubbo / Spring Cloud 商業化團隊正在招人，除了 EDAS，我們還有 ARMS (應用實時監控服務)、MSE（微服務引擎）、ACM（應用配置管理）、SAE（Serverless 應用引擎）等獨立產品。我們在忙什麼？用心打磨這些產品，就是我們的工作。團隊的目標是將阿里巴巴在服務治理上的最佳實踐通過產品化的形式輸出給阿里雲上的企業客戶，幫助客戶實現業務永遠在線。
投遞簡歷：點擊投遞
