測試微服務的4個最佳實踐

1.單元測試和微觀服務 - 類似於PB＆J
單元測試始終是QA策略的重要組成部分，但對於微服務則更是如此。微服務架構將單體應用程式分解為較小的相互依賴的服務。每個服務都執行一個功能，或者至少是目標 - 儘管最初將整體轉換為微服務時，在單個服務中包含多個功能是正常的。假設單個服務僅執行一個功能，單元測試完全適合此模型，因為它們需要測試程式碼片段的最基本功能。單元測試在應用程式的最小元件級別執行。
單元測試有助於將測試範圍僅限於一個功能區域。這樣，每個單元測試都有一個明確定義的單一目標。雖然在單塊中很難確定測試失敗的根本原因，但是在微服務上執行單元測試，識別失敗變得更加容易。
避免誤報有助於提高測試質量，這是透過將微服務與單元測試相結合來實現的。限制測試範圍也使測試執行得更快。憑藉焦點和速度的雙重優勢，單元測試對於微服務來說是不可或缺的。

2.測試服務之間的整合
比單元測試更高一級，我們進入整合測試，它仍然在微服務中佔有一席之地。整合測試用於檢查每個服務如何與其他服務以及外部元件一起使用。他們並不關心內部每項服務的行為，而是關注服務之間的通訊。它們還可用於測試資料庫等外部元件。
在單元測試有足夠的覆蓋率之後，應該進行整合測試。它們應該在引入新功能時執行，因為它們確保新功能與應用程式的其他部分相容。
服務到服務通訊的另一個重要方面是跟蹤。通常，任何請求都會觸及多個服務，然後再透過響應回送給使用者。在這種情況下，跨服務的請求的可觀察性和監控非常重要。跟蹤是實現這一目標的好方法。像Jaeger這樣的新開源工具有助於將單個請求分解為易於檢視的視覺效果，顯示其接觸的服務數量以及每項服務的持續時間。這對於解決延遲和識別瓶頸非常有用。

3.計劃失敗
部署後，確保應用程式的可靠性非常重要。微服務架構已經透過將服務彼此隔離來幫助解決這個問題，這樣即使一個服務發生故障，它也不會消除相鄰服務。更進一步，你可以透過練習混亂工程來建立彈性 - 這是Netflix在宣佈他們的混沌猴子工具時流行的一個概念。該工具會隨機殺死例項和服務，並迫使工程師做出響應並確保很少或沒有停機時間。失敗是不可避免的，混亂工程可以幫助您隨時為失敗做好準備。
但是，你不能馬上開始。你需要從小規模開始建立一個完整的混亂工程實踐。最初，您可能會手動使服務和例項失敗，然後逐漸以隨機，自動的方式引發故障。
要實現這一點，您可以使用像Chaos Monkey這樣的獨立工具。您還可以使用像Istio這樣的微服務網路工具。Istio可以自動路由流量，導致故障和延遲進入HTTP請求。Istio的HTTPFaultInjection功能使您可以有意延遲或中止請求。

4.作為GITOPS的一部分進行測試
雖然持續整合已經存在了一段時間，但今天，大部分創新都圍繞著持續部署 - 特別是GitOps（一種從GitHub儲存庫開始自動部署的方式）。GitOps介紹了DevOps一直以來的自動化和速度，但現在才在Jenkins X，Helm和Grafeas等雲原生工具的幫助下實現。

雖然GitOps在拉取請求之後自動執行每一步，但在測試時很容易妥協。但是，要使GitOps模型成功，需要進行測試自動化，以便在“合併”之前對每個部署進行測試和批准。如果沒有這個，就無法保持所部署內容的質量。Helm和Jenkins X等工具加速了軟體交付流程，但他們需要專注於測試自動化。
總之，微服務透過將整體分解為眾多微服務，為應用程式架構帶來了根本性的變化。這些服務需要進一步細分並透過單元測試進行測試。一旦進行了適當的單元測試，整合測試應檢查服務之間的通訊。部署後，混沌工程可以幫助構建更具彈性的應用程式。此外，測試自動化是實現成功GitOps的關鍵。