跨微服务依赖版本控制

Question

跨微服务依赖版本控制

3

架构概述 考虑以下简化的微服务架构：

服务A - 门户
服务B - API

服务A依赖于服务B。

问题陈述 如果我想在服务A中构建一个新的向后兼容的功能，需要对服务B进行更改，那么根据语义化版本控制的定义，我必须为两个服务创建一个新的次要版本。然而，服务A需要部署服务B的新次要版本。如何有效地管理这种依赖关系？我需要创建一个新的主要版本来表示已更改的依赖关系吗？我想避免在服务B还没有部署之前就部署服务A...

基本上；如何为组件本身的非破坏性更改（即较小的更改）进行版本控制，但如果版本不匹配，则会破坏整个应用程序？

- Pieter van der Heijden

2

既然这是一个非破坏性的更改，那么你可以通过确保在将期望在B中使用的新端点/特性的更改发送到Service A之前，先将更改部署到Service B来手动处理解决方案。但是，听起来你正在寻找一种像软件包管理器一样自动解决这些依赖关系的方法 - 是这样吗？ - David T.

@DavidT. 没错，我们有几个生产环境，每个环境都有自己独立的流水线。因此，在将服务A发布到所有环境之前，无法手动部署服务B。这更接近于helm图表而不是软件包管理器。 - Pieter van der Heijden

1

这正是我所想的。过去一年里，我一直在开发一个部署工具，专门解决这个问题（微服务的部署时依赖解析），并且即将在本周发布。该平台将根据服务清单为每个部署作业提供所需的相关服务的配置和连接。这个服务清单看起来很像其他任何软件包管理器的清单。如果你有兴趣试用，我可以在接下来的几天内回复你并提供链接。 - David T.

@DavidT。是的，请告诉我更多，我非常感兴趣！ - Pieter van der Heijden

抱歉耽搁了！我们本周刚发布了beta版，我很想让您试用一下，看看它是否符合您的需求：Architect.io。 - David T.

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Imran Arshad · Accepted Answer

您不需要打破现有的API合同。我们称您现有的API（B服务）为myapi/v1/products。您不会在现有的API或此端点中做任何更改。您将创建新版本，称之为myapi/v2/products，并部署它。您可以自由选择在哪里以及如何托管该端点。该端点拥有您想要的所有最新更改。您的门户尚未受到影响。

现在，您将部署门户，并将使用myapi/v1/来实现向后兼容的功能，使用myapi/v2/来实现新功能，这样您就可以管理API版本控制而不会破坏功能。

希望这能帮到您！