当涉及到微服务架构中的 azure 服务计划时，我正在寻找最佳实践。我们有一系列微服务，每个微服务在容量、资源、开发人员和整体架构方面都完全独立。不用说，如果一个服务遇到问题，如果不与有问题的服务交互，其他服务不应该受到影响。这些服务托管在 Azure 中
我的问题是关于服务计划以及这些应该如何与开发/登台环境相关联。到目前为止，我们将为我们的微服务创建一个服务计划，称为 PersonService。因此，我们将创建 PersonService 服务计划，然后默认插槽将是生产 (person-service)，然后我们将有另一个暂存插槽 (person-service-staging) 来满足暂存/测试需求。所有这些都将在相同的服务计划下提供。
今天我想到了一个可怕的想法，如果开发人员在 staging 中部署了一些可怕的 bug，它会耗尽所有的 CPU 和/或 mem，那么生产槽就会因这些资源而饿死，而且从本质上讲，staging 环境会影响生产的响应时间。
我认为情况会是这样吗？你们建议如何设置它以避免这个问题？谢谢
是的，你是对的，如果 person-service-staging 开始消耗大量底层服务器的资源，它将影响 person-service。
避免它在很大程度上取决于您当前的设置以及您的优先事项。添加开发/测试/登台服务计划是迄今为止最简单的方法。这使您的生产服务计划仅适用于生产就绪代码。有了部署槽，就可以轻松地在版本之间切换（如果您意识到生产中的某些东西被破坏了，可以快速回滚）
对此的替代方法是制定一个服务计划，该计划专门用于您部署为测试管道的一部分的分段。Azure 建立服务计划的速度意味着您可以即时创建和销毁它们。这为您提供了能够针对您的登台服务器进行性能测试的好处，当它在与您的生产代码相同的计划上运行时。
云计算的主要好处之一是能够创建一次性服务器。即使在 CI 场景中，也需要经过深思熟虑才能摆脱“那是我们的登台服务器”的旧理念——除非你每 30 分钟部署一次代码！- 扔一些新服务器进行测试可能会更干净。即使您没有自动化测试管道，也只需将几个 Azure 自动化脚本连接到网页上的一个按钮（尽管令人惊讶的是这两个脚本的速度有多快！变成更优雅的东西/复杂）