如何搭建微服務架構的質量體系

本文主要談如何構建微服務的質量體系。在這以前，你們先簡單瞭解下幾個問題：

1.爲何用微服務

單體應用就是將應用程序的全部功能都打包成一個獨立的單元，最終以一個WAR包或JAR包存在，裏面包含DAO,Service、UI等全部的邏輯。不幸的是，這種簡單的單元有很大的侷限性。應用程序隨着業務需求的迭代，功能的追加擴展,最終成爲一個龐然大物。

複雜性高：業務規模和團隊規模發展的必定階段，模塊耦合嚴重，代碼難以理解，質量變差 交付效率低：構建和部署耗時長，難以定位問題，開發效率低，全量部署耗時長、影響範圍廣、風險大，發佈頻次低 伸縮性(scalable)差：單體只能按總體橫向擴展，沒法分模塊垂直擴展 可靠性差：一個bug有可能引發整個應用的崩潰 阻礙技術創新：受技術棧限制，團隊成員使用同一框架和語言

2.什麼是微服務

微服務架構:將單體應用拆分爲多個高內聚低耦合的小型服務，每一個小服務運行在獨立進程，由不一樣的團隊開發和維護，服務間採用輕量級通訊機制，獨立自動部署，能夠採用不一樣的語言及存儲。微服務的優勢：

易於開發與維護：微服務相對小，易於理解 獨立部署：一個微服務的修改不須要協調其它服務 伸縮性強：每一個服務均可按硬件資源的需求進行獨立擴容 與組織結構相匹配：微服務架構能夠更好將架構和組織相匹配，每一個團隊獨立負責某些服務，得到更高的生產力 技術異構性：使用最適合該服務的技術，下降嘗試新技術的成本 微服務的介紹有不少，能夠參考：zhuanlan.zhihu.com/p/...

3.微服務帶來的質量挑戰

系統依賴性增長：將單體應用轉成微服務，雖然增長了縮放能力和靈活性，可是引入了更多的依賴，使系統總體變的更復雜，使測試環境的搭建配置以及校驗指標更加難以掌控。 並行開發障礙：系統依賴性的增長還會給微服務的並行開發工做形成影響，須要等待其餘微服務測試環境部署完畢，才能實現集成、測試。微服務數量越多，須要考慮的對象就越是普遍 影響傳統測試方法：傳統測試方法每每經過UI測試進行驗證，而微服務的測試方案更加複雜。不只須要驗證各獨立微服務，還須要檢查總體業務的執行路徑

4.質量體系如何搭建

4.1下面是比較通用的微服務架構下質量保障體系圖 更多請參考：runtester.com/detail/blog…