测试一年多，上线就崩溃！微服务到底应该怎么测试？
不久前，也就是11月16日，澳大利亞交易所（Australian Securities Exchange, ASX）上線了一個新的交易系統(tǒng)，但因為出現(xiàn)故障而被迫關(guān)閉。這是其 2016 年因硬件故障導致休市后最為嚴重的一次事故。
測試了一年多，結(jié)果上線當天就奔潰
11 月 16 日中午，ASX 發(fā)布聲明表示當天將休市，于次日正常時間重新開放。交易所給出的關(guān)閉的原因是“局限于單個交易指令中交易多種證券（組合交易）的軟件問題導致了市場數(shù)據(jù)不準確。”
ASX 此次升級的系統(tǒng)是由納斯達克開發(fā)的最新一代交易系統(tǒng)，目前在全球廣泛使用。為了保障上線后的安全運行，ASX、技術(shù)提供商納斯達克（ Nasdaq ）、客戶和第三方獨立專家已經(jīng)做了一年多的廣泛測試，包括四次彩排。
微服務該如何測試？
看完了熱鬧，也看看咱們自己的系統(tǒng)。隨著以 Spring Cloud、Dubbo 為代表的微服務架構(gòu)的流行，現(xiàn)在很多企業(yè)都采用了微服務架構(gòu)。隨著服務越來越多，這些服務該如何測試？如何防范上面說的系統(tǒng)風險呢？
我們來捋一捋線上系統(tǒng)的風險，然后針對對應的風險來做對應的測試計劃。以如下架構(gòu)為例：
一般來說，一個業(yè)務系統(tǒng)的風險來自兩處：
-
其一是變更帶來的風險，比如前面提到的新系統(tǒng)上線，或者我們給上圖中的購物車服務修一個 bug 等等。
-
其二是日常風險，比如底層的數(shù)據(jù)庫、主機、網(wǎng)絡等軟硬件問題。
如圖：
首先，對于變更帶來的風險，我們可以用如下的測試方式來驗證：
開發(fā)自測
開發(fā)完一個功能后，在提交測試前，開發(fā)人員需要盡力確保邏輯正確。比如 IDEA 或者 Postman 等工具都可以在本地測試 HTTP 接口，可以用來測試 Spring Cloud 服務:
對于 Dubbo 服務，由于是基于 tcp 協(xié)議的，開發(fā)就需要自己手寫一個簡單的 conumer 來驗證下服務的功能:
測試環(huán)境驗證服務
開發(fā)提交測試后，測試人員也需要對服務進行測試，確保該服務能正常工作。此時的測試，一般是在單獨的測試環(huán)境進行的。
對于 Spring Cloud 服務，測試人員可以在 Postman 等工具上，填寫目的 IP、url、參數(shù)來發(fā)起請求、驗證服務：
對于 Dubbo 服務來說，Dubbo Admin 也提供了服務測試功能，能夠在頁面上發(fā)起調(diào)用來驗證服務:
為了安全考慮，一般測試環(huán)境和公網(wǎng)、辦公網(wǎng)是隔離的，比如測試環(huán)境是阿里云上一個單獨的 VPC。在這種情況下，如果需要用 postman 或者 dubbo admin，就需要打通網(wǎng)絡，比如專線等等。
如果你的服務接入了阿里云的微服務引擎（Microservice Engine, 下文簡稱為 MSE），那么就可以直接在 MSE 控制臺上發(fā)起測試請求，而不用理會網(wǎng)絡、權(quán)限等問題。
在 MSE 控制臺上，點擊 微服務治理中心->微服務測試->服務測試 菜單，選擇服務、方法后，就可以可在服務測試頁面選擇調(diào)用的節(jié)點、填寫調(diào)用的參數(shù)：
可以看到，對于入?yún)⒅械膹碗s結(jié)構(gòu)，比如圖中的 ProductItem，MSE 的服務測試功能還會生成示例數(shù)據(jù)，不用測試人員自己去翻代碼看如何填寫入?yún)⒘恕?/p>
填寫完成后，就可以點擊執(zhí)行，來執(zhí)行測試：
MSE 的服務測試功能也支持 Spring Cloud 接口的測試：
整體回歸測試
在一個服務發(fā)布后，需要測試人員驗證下比較重要的產(chǎn)品流程。比如架構(gòu)圖中，從瀏覽商品到最后下單，中間調(diào)用了好幾個服務，測試人員需要整體來回歸一遍這個功能。
對于簡單的場景，在上線不頻繁的情況下，可以由測試人員手動完成整個流程，來看看整個業(yè)務流程是否正常。如果業(yè)務場景過于復雜，或者上線比較頻繁，那么就需要自動化測試了。一般來說，各個公司都會自建 CI 系統(tǒng)來完成這種集成測試。
以 Jenkins 為例，需要：
同樣，這兒也要處理不同環(huán)境中的網(wǎng)絡問題，尤其是生產(chǎn)環(huán)境中的回歸測試，更需要嚴格控制權(quán)限。
作為微服務整體的解決方案，MSE 也提供了自動化回歸能力，能夠一鍵完成回歸測試。首先，點擊 微服務治理中心->微服務測試->服務測試 菜單，新建一個自動化用例。每一步都可以調(diào)用一個 Spring Cloud 和 Dubbo 服務，可以添加斷言，來驗證測試是否通過：
點擊“立即執(zhí)行”后，就在執(zhí)行歷史頁面看到自動化回歸的結(jié)果：
服務巡檢
除了變更帶來的風險之外，我們還需要應對日常風險，比如數(shù)據(jù)庫、網(wǎng)絡等組件出問題的情況。為了應對這些風險，我們需要定時驗證下這個服務能不能正常工作。通常，很多公司會使用 CI 系統(tǒng)的定時執(zhí)行功能來構(gòu)建一個定時執(zhí)行的任務，如果任務執(zhí)行失敗，會自動觸發(fā)告警。
以 Jenkins 為例，除了要搭建 Jenkins、寫測試腳本以外，還需要將 Jenkins 的任務設置為定時觸發(fā)：
比如，我們需要檢查商品服務是不是正常，就可以寫一個 Jenkins 定時任務來調(diào)用商品服務，定時檢查商品服務是否正常。當然，如果你的服務接入了 MSE 的話，也可以使用 MSE 提供的服務巡檢功能來定時檢查服務，如果不能按照預期工作，那么就立刻發(fā)告警，通知告警的訂閱人。
點擊 微服務治理中心->微服務測試->服務巡檢 菜單，新建一個巡檢任務：
然后在列表點擊對應巡檢任務的開始按鈕，就能開始巡檢了:
如果巡檢出錯了的話，也會有對應的告警出來，以釘釘告警為例：
當然，這兒也支持設置郵件、短信告警。您可以根據(jù)服務重要程度來設置不同的告警接收方式。
服務壓測
系統(tǒng)的流量是在不斷變化的，為了應對可能出現(xiàn)的突發(fā)流量，我們需要及時評估系統(tǒng)壓力，決定是否擴容。另一方面，代碼也是不斷在修改的，所以也需要在每次上線前壓測下，看下代碼性能是不是有明顯惡化。在壓測方面，Apache JMeter 可以很好的測試 Spring Cloud 服務和 Dubbo 服務。
對于 Spring Cloud 服務，可以利用 JMeter 自帶的 HTTP 取樣器來壓測：
對于 Dubbo 服務的壓測，jmeter-plugins-for-apache-dubbo 新增了 Dubbo 取樣器，可以用來測試 Dubbo 服務。
只需要在 Dubbo 取樣器的配置頁面設置 registry、interface、method 等，就可以創(chuàng)建好壓測任務了。
創(chuàng)建好壓測任務后，通過 jemter 命令行即可執(zhí)行壓測任務，并得到壓測結(jié)果：
jmeter -n -t ./rest-order-thread-group.jmx -l ./result.txt -e -o ./webreport
最后，如果您的服務已經(jīng)接入了 MSE，那 MSE 也提供了開箱即用的壓測能力。
點擊 微服務治理中心->微服務測試->服務壓測 菜單，新建一個壓測場景，并配置好壓測參數(shù)：
您也可以在壓力配置選項卡上配置壓力模型等參數(shù)：
配置完成后，可以在對應壓測場景的詳情頁面開始壓測。也可以在壓測場景的詳情頁面查看結(jié)果，如果你需要更加詳細的結(jié)果，請點擊運行記錄的詳情按鈕。
總結(jié)
微服務的測試，不論是自己搭建測試系統(tǒng)、還是通過 MSE 來測試，都是為了應對變更帶來的風險和日常風險。只有了解風險，才能及時應對，保障服務高可用。
相比于自建測試系統(tǒng)，阿里云產(chǎn)品 MSE 提供了同樣的功能，不僅避免了用戶自己處理不同網(wǎng)絡互通的問題，而且提供了完善的權(quán)限管理功能，確保線上穩(wěn)定安全運行。除此之外，MSE 還提供了注冊配置中心托管、微服務治理等功能，歡迎體驗。
招賢納士
我們 Dubbo / Spring Cloud 商業(yè)化團隊正在招人，除了 EDAS，我們還有 ARMS (應用實時監(jiān)控服務)、MSE（微服務引擎）、ACM（應用配置管理）、SAE（Serverless 應用引擎）等獨立產(chǎn)品。我們在忙什么？用心打磨這些產(chǎn)品，就是我們的工作。團隊的目標是將阿里巴巴在服務治理上的最佳實踐通過產(chǎn)品化的形式輸出給阿里云上的企業(yè)客戶，幫助客戶實現(xiàn)業(yè)務永遠在線。
原文鏈接：https://developer.aliyun.com/article/781158?
版權(quán)聲明：本文內(nèi)容由阿里云實名注冊用戶自發(fā)貢獻，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔相應法律責任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務協(xié)議》和《阿里云開發(fā)者社區(qū)知識產(chǎn)權(quán)保護指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進行舉報，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。總結(jié)
以上是生活随笔為你收集整理的测试一年多，上线就崩溃！微服务到底应该怎么测试？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Dubbo 版 Swagger 来啦！
- 下一篇： 更便捷：阿里云DCDN离线日志转存全新升