微服務部署

Question

我：

的microService-A 的microService-B 的microService-C

的microService-A調用的microService-B和微服務-C

當我部署的microService-A我想請確保自從我上次發佈它以來，它所依賴的其他微服務未發生變化。

有沒有推薦的方法來做到這一點？

我在想：

• 當我部署的microService-A
• 的microService-A將調用的microService-B和微服務-C
• 這個調用將獲取的端點終點標準它取決於並驗證自上次發佈以來端點是否發生了變化（以破壞Microservice-A的方式）。

這應該在部署過程開始之前中斷當前運行的Microservice-A之前發生。

當然可以做測試，但在我看來這太遲了。我正在尋找一種自動化的方式來在部署之前驗證這一點。

有沒有人做過這樣的事情？什麼工具可以用於這個？

Answer 1

理想的解決方案是永遠不會處於將您部署到您尚未知道依賴項版本的環境中的位置。這樣瘋狂的謊言。

避免這種情況是一種治理問題，因此應該成爲任何面向服務的構建軟件方法的核心。

例如，假設您正在開發服務的版本2.0。在目標環境中，您有服務B版本1.0和服務C版本1.0。

因此，作爲開發版本的一部分，無壓力發佈路徑的第一步應該是運行一組最近鄰居自動化測試，根據Bump v1.0和C v1.0服務合同（稍後更多）。這可以通過使用測試雙工具（如mountebank）來實現。

然後，就像您創建了v2.0發行版分支一樣，您將瞭解到另一個團隊即將發佈服務C的v1.1。應該始終可以確定v1.0到v1.1構成對服務C的v1.0合同的一次重大改變（稍後會有更多介紹）。

如果v1.1是一個突破性更改，沒問題，您可以使用服務C合同v1.1更新測試並修復任何故障。那麼你很有必要創建一個新的v2.0.1補丁分支併發布。如果因爲任何原因你被迫在服務C之前發佈，你仍然可以從v2.0分支發佈。

如果V1.1不是一個重大更改，沒問題，只要鬆開了你現有的分支。

有用於與由集中式發佈管理協議產生如上述的塔頂應對各種策略。

如前所述，應該測試您的服務時，可以使用所有相關的服務合同。 （注意：最接近的鄰居測試是從契約驅動的，而不是使用現有的代碼模型，例如在服務的單元測試中定義的DTO），這非常重要。所有服務合同，應在此基礎上提供了一個完整的服務描述，很容易找到一個標準（如swagger） - 使用service repository可以簡化這一點。

前面還有人說，它應該總是能夠知道的相關服務的新版本必須打破你的服務的潛力。一種策略是同意版本控制規範，在增加版本時賦予某種意義。例如，您可以使用major.minor.patch（例如v1.0.0），其中主要版本號的更改構成對服務合同的更改，因此可能會破壞事情。在我們之前的例子中，服務C從v1.0變爲v1.1。按照上述的慣例，我們可以肯定，這一改變不會打破我們，因爲主版本號沒有變化。

雖然它可以是繁瑣的設置和維護一個集中釋放的管理協議，好處是你總是有充分的信心，通過部署你的服務，什麼都不會破。更重要的是，這避免了在你的原始問題中提出任何複雜的（以及我的想法，人爲的）運行時依賴解決方案。

Answer 2

每個微服務都可以通過API或通過寫入公共文件/共享數據庫來提供版本號。然後，每個微服務將包含所有預期的依賴關係的版本號，並檢查在啓動之前文件/數據庫中的版本號是否匹配。