Microservices 微服务部署

我有：

微服务-A 微服务-B 微服务-C

Microservice-A调用Microservice-B和Microservice-C

当我部署Microservice-A时，我希望确保它所依赖的其他Microservice自上次发布以来没有发生变化

有推荐的方法吗

我在想：

• 当我部署Microservice-A时
• Microservice-A调用Microservice-B和Microservice-C
• 此调用将获取它所依赖的端点的端点规范，并验证自上次发布以来端点是否已更改（以破坏Microservice-a的方式）

这应该发生在我在部署过程开始之前中断当前运行的Microservice-A之前

当然可以做测试，但在我看来那太晚了。我正在寻找一种在部署前自动验证的方法

---

以前有人做过类似的事情吗？可以使用什么工具来实现这一点？

每个微服务都可以通过API或写入公共文件/共享数据库来提供版本号。然后，每个微服务将包含其依赖项的所有预期版本号，并在启动前检查文件/数据库中的版本号是否匹配。

每个微服务可以通过API或写入公共文件/共享数据库来提供版本号。然后，每个微服务将包含其依赖项的所有预期版本号，并在启动前检查文件/数据库中的版本号是否匹配。

理想的解决方案是永远不要将您部署到您还不知道依赖项版本的环境中。那样的话，疯狂就是谎言

避免这种情况是一个治理问题，因此应该是任何面向服务的软件构建方法的核心

例如，假设您正在开发服务A的2.0版。在您的目标环境中，您有服务B的1.0版和服务C的1.0版

因此，作为开发构建的一部分，实现无压力发布的第一步应该是运行一组最近邻自动化测试，这些测试根据服务合同（稍后将详细介绍）剔除B v1.0和C v1.0。这可以通过使用测试双重工具（例如）来实现

然后，正如您创建了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）。所有服务的合同都应基于提供完整服务描述的标准（例如），并且非常容易找到-使用a可以简化这一点

如前所述，应该始终能够知道依赖服务的新版本是否有可能破坏您的服务。一种策略是在版本控制约定上达成一致，在增加版本时赋予某种意义。例如，您可以使用major.minor.patch（例如v1.0.0），其中对主版本号的更改构成对服务合同的更改，因此有可能破坏服务合同。在我们前面的示例中，服务C从v1.0升级到v1.1。有了如上所述的约定，我们可以确保更改不会破坏我们，因为主要版本号没有改变

---

虽然设置和维护一个集中的发布管理协议可能会很麻烦，但好处是您始终有充分的信心，通过部署您的服务，不会有任何问题。更重要的是，这避免了任何复杂的（在我看来，是人为的）运行时依赖项解析，就像您在原始问题中提出的那样。

理想的解决方案是，永远不要将部署到您还不知道依赖项版本的环境中。那样的话，疯狂就是谎言

避免这种情况是一个治理问题，因此应该是任何面向服务的软件构建方法的核心

例如，假设您正在开发服务A的2.0版。在您的目标环境中，您有服务B的1.0版和服务C的1.0版

因此，作为开发构建的一部分，实现无压力发布的第一步应该是运行一组最近邻自动化测试，这些测试根据服务合同（稍后将详细介绍）剔除B v1.0和C v1.0。这可以通过使用测试双重工具（例如）来实现

然后，正如您创建了v2.0发行版分支一样，您了解到另一个团队即将发布服务C的v1.1。应该始终能够确定v1.0到v1.1是否构成服务C的v1.0合同的突破性更改（稍后将对此进行详细介绍）

如果v1.1是一个突破性的更改，那么没问题，您可以使用服务C合同的v1.1更新您的测试，并修复任何故障。然后您就可以创建一个新的v2.0.1补丁分支和版本了。如果出于任何原因你被迫被释放