【51CTO.com快譯】采用微服務所帶來的諸多優(yōu)勢往往會在質量層面引發(fā)一系列挑戰(zhàn)。微服務近來已經成為優(yōu)步、Netflix、Spotify以及Amazon等眾多重量級廠商的優(yōu)先選擇。毫無疑問，這套架構方案在軟件開發(fā)生命周期內具備著巨大吸引力，但其帶來的諸多優(yōu)勢亦往往會在質量層面引發(fā)一系列挑戰(zhàn)。

[[177940]]

1.系統(tǒng)依賴性增加

根據定義，由整體式應用或服務過渡至微服務架構時會引入更多邏輯隔離組件。盡管這種拆分方式增加了縮放能力與靈活性水平，但亦引入更多依賴關系，使得系統(tǒng)整體更為復雜。具體來講，這意味著完整測試環(huán)境的配置與檢測指標更加難以衡量。

例如，假定我們設置的測試環(huán)境將原有應用程序拆分為10項Web服務。為了便于討論，我們假設每項Web服務各自擁有10項操作，且每項操作具備自己的一項獨立微服務（10乘以10）。原本的測試環(huán)境只需要訪問初始的10項Web服務，但如今新的測試環(huán)境則需要在全部測試場景中訪問100項經過妥善配置的微服務。

2.并行開發(fā)障礙

系統(tǒng)依賴性的增加還會給微服務的并行開發(fā)工作造成影響。系統(tǒng)依賴性擴展會產生兩種瓶頸類型：團隊需要等待其它團隊以完整相關微服務的并行開發(fā)，以及/或者團隊需要等待測試環(huán)境得到妥善配置（即包含全部相關微服務的正確版本）方可實現聚合、配置與設定。微服務數量越多，需要考慮的對象就越是廣泛，這意味著以并行方式開發(fā)及發(fā)布新功能就變得愈發(fā)困難。

3.影響傳統(tǒng)測試方法

傳統(tǒng)測試方法往往需要配合要求或者用戶背景，并通過UI測試進行驗證。而在微服務方面，我們則需要對測試策略進行整體變更，這意味著原有測試方法將不再適用。盡管通過UI實現的測試仍可在軟件開發(fā)生命周期末期順利起效，但微服務在消息層需要的方案無疑更加復雜。

另外，驗證各獨立微服務還只是***步。我們還需要通過現具分布式特性的微服務架構檢查全部關鍵性事務的執(zhí)行路徑。由于微服務的目標之一在于實現快速變更，因此我們必須意識到：

• 與服務自身相關的素材會發(fā)生變化。
• 這種變化會影響到其它服務的依賴性。
• 這種變化會影響到關鍵性端到端事務。
• 這種變化會影響到最終用戶體驗。
• 需要在測試數據中引入更多新要求。
• 需要應對更多非功能性要求，例如性能、可訪問性、可靠性以及彈性等等。

4.更多潛在故障點

微服務遷移的另一大負面影響在于引發(fā)大量獨立故障點。回到之前提到的簡單舉例，單一Web服務的失敗將影響全部10項操作。但在遷移后，拆分帶來的10項微服務各自都會在發(fā)生故障時影響其它9項服務。盡管微服務能夠利用隔離機制限定各獨立故障點的影響范圍，但開發(fā)測試人員必須意識到眾多活動組件所帶來的高度復雜性。

為了了解微服務變革給業(yè)務帶來的影響，開發(fā)測試團隊必須馬上對測試依賴性進行廣泛而嚴格的監(jiān)控。另外，開發(fā)測試團隊還需要能夠深入訪問采用這類高度模塊化、分布式體系架構的測試環(huán)境。

原文標題：4 Quality Challenges Caused by Microservices   原文作者：Cynthia Dunlop

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】