簡介： 隻有了解風險，才能及時應對，保障服務高可用。
不久前，也就是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 還提供了注冊配置中心托管、微服務治理等功能，歡迎體驗。