微服務版本控制

Question

在基於微服務的體系結構中適應版本控制的最佳實踐是什麼？在運行時支持同一服務的多個版本部署以及消費者如何使用不同版本？ 1）如果我們使用基於路由版本的方法之一提到here 話，我想我們將有以下缺點

1. 內部服務不得不通過反向代理消費。
2. 消費者總是必須知道所需的版本。

向客戶公開版本信息是否是最佳做法？

在任何情況下，因爲我覺得，以下始終適用：

1. 重大版本變化，消費者必須改變。
2. 對於MINOR版本更改（向後兼容），只有需要添加功能的使用者需要更改。
3. 對於PATCH版本更改，它是可選的，可能無縫供任何消費者使用。

什麼樣的微服務版本策略可以幫助我們實現上述目標？

注 - 請隨時讓我知道這是否需要分成多個問題。

Answer 1

沒有最佳實踐。這將取決於如何在特定情況下使用版本控制。

Shawn Wildermuth在pluralsight video中討論了有關api版本控制的內容。不確定你的微服務實現細節，但如果你使用rest api，你可以嘗試實際有效負載的版本號

你也可以用Accept頭來做到這一點。接受允許您通過 註釋接受標頭的版本類型與您想要查看的API相對應。你也可以用內容類型來做到這一點。 供應商的應用程序/ vnd指定返回的 數據的版本，以便當應用程序發送它時，它知道它是什麼樣的有效載荷版本。這是 版本控制中的一項重要技術，因爲您必須對API，實際URI調用以及返回數據的形狀進行版本管理。

如果您發現一種適用於您的環境以及您的客戶和用戶的良好機制，請繼續使用。

Answer 2

什麼是對版本的微服務基礎的架構

一個startegy，我在我的微服務項目中使用是版本通過路由適應的最佳實踐。

我們使用JSON RPC 2。0，所以它與REST有點不同，但它可以應用。

我們只使用主要的版本控制，並嘗試同時使用舊版和新版，以便讓消費者更新時間。

事情要具有生產服務的超過兩個的版本

• 避免護理（真的很難管理，如果你有一些模型更新）。

• 找到告訴消費者使用的版本已過時的方法。

我知道有些微服務架構生活沒有版本控制，但它意味着你有消費者和生產者之間的強耦合，所以我可以不推薦這種方法。

要回答第二個問題

消費者如何能夠使用不同的版本？

這聽起來不可能，因爲消費者一次只能使用一個版本。

如果您想知道該版本可以在運行時使用它，您可以通過功能翻轉以及服務發現進行瀏覽。

如果路由x存在，您的消費者會定期詢問服務發現。如果爲true，則使用該功能，否則繼續使用當前版本。它可以工作，但管理起來有點棘手。

Answer 3

你可以混合不同stretagies

進行大的變動，你可以使用基於路由版本

對於其他可以使用適配器基於版本

的比賽