微服务部署

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或通过写入公共文件/共享数据库来提供版本号。然后，每个微服务将包含所有预期的依赖关系的版本号，并检查在启动之前文件/数据库中的版本号是否匹配。