我有：
的microService-A 微服务-B 微服务-C
Microservice-A调用Microservice-B和Microservice-C
当我部署Microservice-A时，我希望确保它所依赖的其他微服务自我上次发布以来没有改变。
有推荐的方法吗？
我在想：
这应该在我在部署程序开始之前中断当前正在运行的Microservice-A之前发生。
当然可以做测试，但在我看来这太迟了。我正在寻找一种在部署之前验证这一点的自动方法。
以前有人做过这样的事吗？可以使用什么工具？
答案 0 :(得分：0)
每个微服务都可以通过API或写入公共文件/共享数据库来提供版本号。然后，每个微服务将包含其依赖项的所有预期版本号，并在启动之前检查文件/数据库中的版本号是否匹配。
答案 1 :(得分：0)
理想的解决方案是永远不要将您部署到您不熟悉依赖项版本的环境中。这就是疯狂。
避免这种情况是一个治理问题，因此应该是任何面向服务的构建软件方法的核心。
例如，假设您正在开发服务的2.0版本A.在目标环境中，您拥有服务B版本1.0和服务C版本1.0。
因此，作为开发构建的一部分，在无压力发布路径上的第一步，您应该运行一组最近邻自动化测试，它基于B 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。通过如上所述的惯例，我们可以确定更改不会破坏我们，因为主要版本号未更改。
虽然设置和维护集中式发布管理协议可能很麻烦，但好处是您始终完全相信通过部署服务，任何事情都不会中断。更重要的是，这避免了任何复杂的（以及我的想法，人为的）运行时依赖性解析，例如你在原始问题中提出的建议。