美團點評：打造微服務自動化測試與持續集成工具鏈實踐

• 2019 年 12 月 11 日
• 筆記

來源：http://www.uml.org.cn

1 從Monolithic到Microservices

在2008年時，市場軟體形式大多為CS架構。當時存在的問題在於，開發耗時1-2年且內部的解耦度低；而優點在於對測試團隊十分友好。

後來軟體形式又經歷了從SOA分散式架構到現在的微服務架構。

對於微服務架構來說，它並非像開發者們想像中的井井有條。下圖是一個微服務架構化的典型示例，從綠色的線可以看出服務之間的關係錯綜複雜。

由於微服務架構把系統功能細分，團隊會在各個方面都碰到了挑戰。那麼微服務架構下工程品質面對的問題，該如何解決？接下來我們將會從四個方面講述。

2 問題的發現與解決

自動化測試

1.存在的問題

服務數量多，以HTTP和RPC介面為主：鏈路長依賴多。

服務交付周期變短：從以前的大模組開發，花費幾個月時間交付。到現在的一到兩周交付上線，但自動化測試開發速度跟不上交付的速度。

框架使用不規範，多種方式並存。

自動化測試程式碼的擴展性和可維護性不夠

2.解決方案

通過提供相應的自動化測試框架工具，可以實現標準化、規範化、快速交付測試程式碼。具體操作如下。

統一的框架archetype自動生成整個項目框架。

數據、配置、程式碼分離進行數據的驅動。

單介面+場景化，確保做到無參數傳遞。

把一些常用的Lib庫打包，在POM文件裡面引用。

HTTP和Thrift介面封裝，提高程式碼的復用率。

API-Lib

下圖是自動化測試框架圖示。

在數據校驗時，自動化設計框架會自頂層生成測試項目結構，測試環境動態配置。

在測試數據，會由數據驅動來完成，只需要維護裡面的數據即可，無需改變程式碼；

在Testcase層，引入了Json Schema、Json Path做數據校驗；

把HTPP和Thrift做了相應的封裝，方便調用；

最底層使用了Thrift，封裝相應的Lib庫。

自動化示例

如下圖，左邊是之前的Test程式碼，右邊是通過統一測試框架自動生成後的程式碼。

分為data和內部環境數據，子文件里是單介面和多場景，在內可以復用API介面。

如何做到無參數

對於程式碼而言，多一個參數含義，整體複雜度和冗餘度都會提升。

團隊從框架引用，生成框架，到case的編寫，生成Thrift寫法；在數據維護上自動生成數據格式。做到了測試框架+測試程式碼+測試數據，實現了自動化。

自動化之後可以做到相應的專項程式碼測試，大量的數據變化和驗證會在文件里直接做相應的要求。

開發聯調

1.存在的問題

多個服務同時開發， 聯調耗時日益增長：從內部看聯調的佔比大概在20%-50%之間。這種情況主要有兩方面。一是，聯調自測環境不穩定，服務多。另一方面是，多人開發，從一開始的簡單介面約定到中間PM需求改變，導致介面互相之間數據格式上有變化，雙方難做同步。

聯調測試環境不穩定：需要找合作方調試，浪費時間。

自測時需要部署和維護多個依賴方服務。

2.解決方案

開發未動，Mock先行，隨時聯調。

在開發開始時，多方定義好相應的介面，介面文件，數據格式和規則。通過Mock工具生成服務，發布到聯調測試環境中。

使用Moka工具自動生成Mock Server，指定相應的Thrift定義，根據相應規則，生成Mock Server，在內配置聯調服務，指向Mock Server，再配置相應的數據規則和匹配規則。

通過Moka能夠做到開發剛開始時就可以提供相應的聯調服務，流程基本如下。

一鍵生成獨立Mock優於平台的點在於，適用性好。也支援Thrift的註解方式使用和Mock數據管理。

測試環境

1.存在的問題

由於服務數量增多，鏈路變長，調用依賴增多，整個環境的搭建會十分吃力。

多人共用一套環境，互相影響，容易影響測試結果。

穩定性差。

2.解決方案

解決的問題主要集中在，資源的申請，申請後的環境隔離與數據隔離，測試環境的維護，恢複測試環境等。

環境搭建可以從三個方面考慮，環境隔離、按需創建、描述依賴。

美團團隊選擇了通過HULK+泳道提供環境隔離，Cargo按需創建測試環境。骨幹+泳道複製全新的環境，隨後打通發布系統和程式碼倉庫，發布大的測試環境，做穩定性與可控性的監控和三個9穩定性測試環境。

環境監控：

原則：泳道可以調骨幹，骨幹不可調泳道。

環境建好後，要保證隨時可以使用。在穩定性監控下，只要提供服務，列表就可以進行監控，定時部署最新的分值程式碼。

整個環境都處於監控之中，每半個小時發送一次環境整體概況。如果某個服務穩定性降低，團隊會直接@負責人查看原因。

持續集成

1.存在的問題

一次提測服務增多，提測了多個倉庫，使得CI Job經歷了爆炸性增長。

提測品質無法得到保證，測試不過關；缺乏前置測試，無效溝通太多。

2.解決方案

微服務環境中兩個關鍵點：Merge到主分支前，提測前自動檢測。

關鍵節點1：

程式碼提交和Merge到主分支，拉分支會自動創建CI Job，Push程式碼觸發掃描，PR Merge到主分支觸發掃描，PR更新觸發再次掃描，通過允許Merge到主分支。

這樣可以做到不把問題帶到線上分支，並且前置的方式約束RD在上線前就解決問題。

關鍵節點2：

提測前還要再次自動檢測。當需求提測的時候，根據提供的發布資訊自動創建對應的Pipeline，點擊提測之後會自動出發Pipeline的執行，自動部署，並做冒煙測試。Pipeline會明確的顯示冒煙測試結果是什麼，問題在哪裡。

大大減少了無效的溝通。

工具鏈流程：

通過後台的CI服務，工具鏈從RD拉分支開始，拉分支會創建一個Pipeline Job，做Push程式碼的時候同時做Sonar掃描，由大象通知結果。

在工具鏈上共提供四個服務：

單測覆蓋率CI服務。在Pom無侵入修改引入Jar包；一鍵接入單測覆蓋率服務。

靜態程式碼掃描CI服務，Sonar伺服器進行線上監測。

自動部署，做冒煙測試。

記憶體掃描分析CI服務。Valgrind提供了Pipeline插件 開發，通過修改了插件，可以解決了許多相關的問題。在Pipeline上使用，可以一步分析，自動推送。

美團點評：打造微服務自動化測試與持續集成工具鏈實踐

3 經驗總結與反思

啟示

理解用戶需求的完整場景：源頭，原因和原理。

堅持工具設計的主線和願景，短期服從長期。

只有在用戶需要時才出現。

從工具和服務做起，不要一開始就做平台。

跨團隊合作，互補長短。

總結

我們在自動化測試方面，開發了規範化、標準化的LIPS自動化測試框架；開發聯調方面，開發了Moka；Cargo來創建測試環境，做三個9的穩定性和可用性服務的測試環境；在持續集成方面，使用Pipeline，提供相應的CI服務且不做任何配置；PUSH程式碼會自動獲取相應的資訊，幫助大家做持續集成。

Q&A

Q：手工測試和自動化測試佔比是怎麼樣的？

A：目前來講，在工具應用之前，手工測試佔比非常高，應該在60%以上，自動化測試應用的很不好，主要原因是整個標準化程度不夠，維護起來很麻煩。根本的原因在於沒有一個很好的框架工具支援它。

Q：Sonar掃描歷史債怎麼處理呢？

A：Sonar掃描每個團隊都積累了很多關於怎樣解決這個問題的經驗。我們的解決方法一方面是依靠團隊技術leader，有團隊的支援，另外做好前置掃描，禁止有問題的程式碼上線。只有解決問題才可以上線。

歡迎參加眾測：

https://wap.ztestin.com/site/register?usercode=FAAAQwMQGAAXAwQBA3QhExcDHAQDPjVaABMIQg%3D%3D