我正在寻找微服务架构中蔚蓝服务计划的最佳实践。我们有一系列微服务，每个微服务在容量，资源，开发人员和整体架构方面完全独立。不言而喻，如果一个服务遇到问题，如果不与有问题的服务交互，则不应该影响其他服务。这些服务托管在Azure
中我的问题是关于服务计划以及这些应该如何与开发/暂存环境相关。到目前为止，我们将为我们的微服务创建一个服务计划，称之为PersonService。因此，我们将创建PersonService服务计划，然后默认的插槽将是生产（人员服务），然后我们将有另一个临时插槽（person-service-staging）来满足暂存/测试需求。所有这些都将在同一服务计划下提供。
今天有一个可怕的想法，如果一个开发人员在升级中部署一些可怕的错误会占用所有的CPU和/或内存，那么生产槽就会从这些资源中匮乏，而且基本上，暂存环境会影响响应时间生产。
我是否认为情况会这样？你们如何建议设置它以避免这个问题？感谢
答案 0 :(得分：1)
是的，你是对的，如果人员服务阶段开始消耗大部分底层服务器的资源，它将影响人员服务。
避免它取决于您当前的设置以及您的优先级。添加dev / test / staging服务计划是迄今为止最简单的方法。这使您的生产服务计划仅用于生产就绪代码。使用部署插槽只需简单地在版本之间切换（如果您意识到生产中的某些内容被破坏，则快速回滚）
另一种方法是制定一个服务计划，专门用于作为测试管道的一部分进行部署的暂存。 Azure可以提供服务计划的速度意味着您可以动态创建和销毁它们。这使您能够在与生产代码相同的计划上运行时，对登台服务器进行性能测试。
云计算的一个主要好处是能够装箱一次性服务器。它需要经过深思熟虑的思考，即使在CI场景中，也要摆脱“那是我们的登台服务器”的旧哲学 - 除非你每30分钟部署一次代码！ - 抛出一些新服务器进行测试可能会更加清晰。即使您没有自动化测试管道，也只需要将几个Azure自动化脚本连接到网页上的按钮（尽管令人惊讶的是，这些脚本会多快地增加到更优雅的/复杂的）