Deployment 跨微服务的部署同步

假设有两个环境：staging和prod。 还有两种微服务：A和B。 微服务已经部署到两个环境和每个运行服务版本1。因此，我们：

舞台：A1、B1 产品编号：A1、B1 现在，一个开发团队通过MessageBroker在microservice A中实现了同步API或异步API的新特性，并将A2部署到暂存中。然后，另一个团队在B中实现了新特性，该特性利用A2中的新特性，并将其部署到过渡B2。现在我们有：

分期：A2、B2 产品编号：A1、B1 新特性由客户机在临时环境中进行测试，并批准部署到生产环境中。问题是如何确定哪些服务应该首先部署到生产环境中。显然，B2不能首先部署，因为它依赖于A2。是否有任何工具/策略来跟踪它

我可以想象的是，所有服务都会跟踪它们所依赖的其他服务的哪个版本，并且在部署期间，会根据目标环境中运行的内容检查这些版本，如果缺少某些内容，则会拒绝部署

这就提出了一个问题——微服务部署应该是并行的还是一次一个微服务

另外，如果在将A2和B2部署到prod之前，将有A3发布到staging，并且依赖于B2，该怎么办？现在，我们应该按如下方式安排生产部署：

A2=>B2=>A3

---

这些都是我想到的现实世界的例子，但也许在微服务体系结构中，遵循一些规则可以避免这种情况？

在集成点中进行版本控制是一种选择

例如，如果microservice-A通过REST调用从microservice-B获取信息，例如，当microservice-B希望更改REST调用合同中的集成更改时，microservice-B可以添加具有新版本映射的新端点，如/getInformationFromMeV2，而无需删除旧端点。通过这种方式，当您部署microservice-B时，microservice-A仍可以使用旧端点一段时间。在部署microservice-A之后，您可以在下一次部署中从microservice-B中删除旧端点

注意：当然，如果microservice-A想要使用microservice-B中新开发的端点，则必须在microservice-A之前部署microservice-B

对于异步通信，您仍然可以应用此方法。如果您使用基于代理的通信（如使用Kafka），假设您想首先部署microservice-A：

如果microservice-A是消费者，则会创建新主题，microservice-A也会订阅新主题，并为microservice-A部署新版本。在部署microservice-B之前，microservice-A会同时使用来自新主题和旧主题的消息，在部署microservice-B后，所有消息都将发送到旧主题，旧主题将被删除

如果microservice-A再次成为生产者，则会创建新主题，并且在部署microservice-A后，会向新主题发送新消息。当Microservice-B也被部署时，它开始从新主题的开头读取消息，旧主题被删除

通过这种方法，您可以独立部署微服务，这对于微服务体系结构来说非常方便