Spring Cloud Contract 在永輝雲創的研發實踐

永輝雲創服務端研發團隊在日常研發工作中, 積累了很多經驗和實踐, 並形成了一套知識庫。作為一個積極向上，追求技術進步的團隊, 我們很樂於將我們的實踐經驗，分享給業內同事們，共同探討， 一起進步。

分散式研發模型演進

眾所周知, 分散式系統是由眾多微服務構成,並按照功能模塊劃分後, 由不同的開發小組進行維護. 研發模型如下圖所示: 開發人員完成某一個微服務的功能後, 發布測試環境交付測試團隊驗證. 這種工作模式的弊端是, Bug在測試環境才被暴露, 而不是在編碼階段就被發現.

為了解決上述的弊端, 研發團隊通常會引入了單元測試, 並使用EasyMock, Mokito等框架, 來幫助開發人員在開發階段暴露Bug. (對DB, Redis等依賴通常使用Docker來解決, 與主題無關, 這裡暫時不做過多介紹. 有興趣的可以自己研究)

在日常的研發工作中, 很多團隊或多或少遇到過這種情形: 微服務提供方修改了對外介面, 導致消費方無法正常請求, 造成生產事故. 管理上的人為避免, 難免導致各種疏漏, 為此我們找到了一種智能的解決方案---消費者驅動的契約測試.大意是這樣的: 服務提供方和消費方約定共同的契約, 雙方圍繞契約, 進行各自的單元測試工作.

Spring Cloud Contract概要

永輝雲創使用Spring Cloud作為微服務基礎框架, 藉助Spring Cloud Contract來幫助服務提供方和消費方來制定契約. 所謂契約, 就是雙方約定好的介面調用參數, 及對應的輸出. 整體概覽如下圖所示.

通過上圖, 相信大家對Spring Cloud Contract有了大體的了解, 下面我們用幾個關鍵詞來描述Spring Cloud Contract的特性.

用於UT

定義遠程服務數據

自動生成測試代碼

Spring Cloud Contract在永輝雲創的具體實施步驟如下圖所示, 通常, 服務提供方, 也是數據定義方. 在這裡, 我們使用的了數據定義方(所有服務契約在一個工程中定義), 服務提供方, 服務消費方三方模型.

Spring Cloud Contract實踐

以下內容，摘自我們推進Spring Cloud Contract落地之初，編寫的技術文檔。 希望給讀者帶來更加接地氣的參考, 部分內容進行了脫敏, 請讀者諒解.

數據定義方

對於請求返回數據, 所有提供方統一在spring-cloud-contract（內部項目名, 非spring cloud Contract）項目里定義, 方便大家看測試數據

原則上由服務開發定義者來提供這個groovy，但是如果時間急迫，依賴方直接編寫，並有服務開發者review後也可以提交~

題外話：有些工具, 例如wiremock可以幫助錄製並模擬http請求. 使用場景: 前端開發依賴於服務端提供的介面, 我們通常是等服務端開發完成後,部署到測試環境,供前端調用. 現在有了wiremock, 假設我們要開發v2版本的介面, 可以先錄製v1版本的請求, 然後修改膠片為v2版本http響應. 這樣就可以前端就可以在v2介面開發完成前, 愉快地進行mock請求, 減少前端對服務端介面進度的依賴.*

http://www.cnblogs.com/tanglang/p/4791198.html

http://wiremock.org/docs/running-standalone/

服務提供方

引入UT相關jar包

配置UT代碼生成器插件

配置UT基礎類

生成UT代碼時, 有需求是需要初始化資料庫, 配置內置的redis, mysql. 我們使用相關的開源框架, 搭建了自己的UT基礎類, 進行ut前的場景準備.

Test文件夾下的項目啟動類Bootstrap

需要注釋掉consul, feign, 保證ut對外部依賴的隔離.經過實踐, 發現測試時TestBootstrap不會覆蓋Bootstarp, 因此需要保持兩者名字一致, 即TestBootstrap要修改文件名為Bootstrap.class

test/resources/bootstrap.properties__增加配置(重要)__

服務消費方

配置和服務提供方一致, 需要調用提供方介面的測試類, 增加以下注釋,埠號不要寫錯了

THANK YOU

Powered by 永輝雲創技術

關注我們，共同進步

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！