这不是我遇到的实际问题，但是我想知道人们为了解决一个非常普遍的情况而采取的不同方法是什么。
您有一个或多个微服务，每个微服务都具有客户端用来消耗资源的模式和接口。
我们在另一个仓库中有一个网站，该网站正在使用其中一种微服务（例如REST API）的数据。
类似
微服务（API）：我更改了接口，这意味着JSON响应是不同的。 前端：我在前端进行更改以适应微服务的响应。
如果我们在部署前端之前部署微服务，则您将制止前端站点。
因此，您需要确保某些人已经部署了新版本，然后部署了微服务。
这是手动方法，但是人们正在以自动化的方式进行跟踪，例如在没有部署正确版本的前端的情况下无法进行部署。
答案 0 :(得分：0)
我认为，如果您在DevOps env中使用docker，则可以将docker-compose与depends_on属性depends_on startup-order一起使用，或者应创建脚本bash（例如）来检查在继续之前已部署并包含在管道中的前端的正确版本
答案 1 :(得分：0)
最安全的方法之一是尝试通过在服务级别上使用版本控制来始终向后兼容，这意味着当您需要引入向后不兼容的更改时，具有相同服务的不同版本。 假设您有一个微服务，可在像这样的其余端点中提供产品
/ api / v1 /产品
当您进行向后不兼容的更改时，应通过保持现有版本仍然可用来引入新版本
/ api / v1 / products
/ api / v2 /产品
您应该为第一个服务端点设置一个日落，并与客户进行交流。在您的情况下，这是前端部分，但在其他情况下，可能还有很多其他客户端（不同的前端服务，不同的后端服务等）
这种方法的缺点是您可能需要支持同一服务的多个版本，这可能很棘手，但这是不可避免的。在许多情况下，与客户的交流也很棘手。
另一方面，它为您提供了微服务隔离和自由的真正力量。