我们需要解决的问题是如何以原子方式部署它们：
让我们说：要求用户服务版本为2.0的最终服务。
如何在部署前端服务之前确保用户服务可用。
我们有复制的想法在整个基础架构中，部署所有内容，然后使其可用。但是在我看来，这很复杂。您如何制作这些备用实例，部署服务并进行切换？
我们为每个服务使用两个ALB和目标组（动态端口映射）。
#1 楼
这个问题可能表明对微服务的架构划分很差。来自什么是微服务？：这些服务围绕业务功能构建，并且
可以由全自动部署机械独立部署。
在这种情况下错过的关键点是它们可独立部署的方面。
这一点也可能只是被误解了：这不一定意味着每个微服务都应该能够独立执行其全部功能，而只是意味着它能够在其他一些微服务能够正常运行时保释。功能取决于不可用，可能会在微服务可用时跟踪“待办事项”以供以后执行。
从不同的角度看：处理外部服务依赖项的不可用性实际上应该是每种微服务功能的一部分-因此，即使不满足其运行时依赖关系，人们也可以认为微服务功能齐全：）
值得注意的是，我认为在以上注释中，我指的是微服务不可用性，无论其原因是什么，无论是部署依赖顺序还是其他原因（例如停机）。
还要考虑的另一件事是，在部署微服务和通过将流量切换到微服务之间来实现微妙的区别。交换流量通常比部署本身要快，因此可以通过首先部署所有微服务，然后对所有微服务执行流量切换，来提高整个系统级别的可用性。
#2 楼
我们遇到了类似的情况，其中我们的一个应用程序必须在第二个应用程序之前被构建，部署和运行。这是因为应用程序A具有一些功能，在通过应用程序B引用之前，应先执行这些功能。我们完成此操作的方法是将其构建到单个交付管道中。这样，所有依赖项都可以按需顺序或并行部署。为了以防万一，我们还按顺序提供了数据库脚本和回滚功能。
改写为您的情况，您可以在前端服务之前部署api。
希望这会有所帮助。
评论
我也这么想！非常感谢您的这些解释。
–凯马兹（Kaymaz）
18年7月23日在12:16