已過時的許多存儲庫的微服務

Question

在微服務架構中，保持許多開發人員環境跨多個源代碼存儲庫最新的最佳策略是什麼？

假設有10個團隊的10個開發人員在git中處理200個微服務。每個開發人員都需要定期從每個存儲庫中取出。這可以用腳本來完成，但有沒有更好的方法？我們是否這樣做是錯誤的，因爲它似乎是一個沉重的開銷。

Answer 1

我不會建議讓每個開發人員構建每個微服務。我會提出某種持續集成環境。一個集中式構建服務器連接到所有的git回購站。

每次更新回購時，構建服務器都應檢測更改，構建代碼，運行單元（或功能）測試，然後將服務推送到某種集成環境。然後，構建服務器也可以針對部署的服務運行一些集成測試。

大多數開發人員應該能夠在不需要訪問其他微服務的情況下進行所有開發和測試。如果開發人員構建服務X，該服務取決於Y & Z並且依賴於A & B，那麼開發人員大部分應該只有服務X.對於單元測試服務Y & Z應該被模擬/模擬。

所面臨的挑戰是要通過更改服務X.那種集成測試的往往是作爲服務X往往不知道細節的開發人員棘手可以防止顯影劑打破服務的一個& B（或甚至如何使用）上游服務（例如A & B）。

解決這個問題的方法我相信會定期進行集成測試，無論是由服務X構建還是定期運行。通過一個項目，這個複雜的強大而強大的單元測試理念和集成測試框架將變得至關重要。

Answer 2

這歸結爲你的服務位置/檢測技術是好的。所有服務需要知道的是在哪裏發送請求X以便從特定服務獲得響應Y.如果這是很好的實施。你可以非常好地讓每個開發人員運行他在本地直接工作的任何子集的服務，並讓其他服務在一個通用環境中運行（可以稱之爲遠程）

遠程將被配置爲運行您的所有服務平臺，並將有一些方法來獲取最新的代碼（基於節奏或基於定期）。可以將本地環境配置爲：本地運行的所有服務都將知道本地運行的其他服務，並知道如何在需要任何信息時訪問遠程服務。對於開發人員環境，添加約定，每個開發人員運行生產開發所需的最少數量的服務。這意味着如果您不是將代碼用作服務，請遠程運行它，以便您知道您正在運行最新的代碼並且不會過期。

這種方法夫婦陷阱的

1. ，你可以在本地運行服務A和具有服務B上遠程運行。你在本地測試一切，它似乎在工作，所以你決定推動。當你推動時，另一位開發人員也會將更改推送給B，而現在您的更改不再兼容。
2. 如果您在本地運行服務A和C並且遠程運行B，那麼將請求發送到服務B到遠程環境應該非常直接。但是，您應該小心，如果A呼叫B和B呼叫C，那麼對C的呼叫需要從遠程環境路由到您的本地C服務，而不是您的遠程C服務。
3. 測試 - 您可以通過兩個單獨的測試套件來解決許多與測試有關的複雜環境相關的問題。 1.單元測試 - 測試服務中的單個組件，並調用其他被嘲笑的服務。 2.環境集成測試 - 這些測試驗證不同服務之間的通信。 Suite 1將檢查您的服務的內部代碼，Suite 2將在您將更改推送到遠程後繼續運行，並將繼續確保服務間通信如預期。

希望幫助