Azure 服务计划和非生产槽

Question

我正在寻找有关微服务架构中的 azure 服务计划的最佳实践。我们有一系列微服务，每个微服务在容量、资源、开发人员和整体架构方面都完全独立。不用说，如果一个服务遇到问题，如果不与有问题的服务交互，其他服务不应该受到影响。这些服务托管在 Azure 中

我的问题是关于服务计划以及这些应该如何与开发/登台环境相关联。到目前为止，我们将为我们的微服务创建一个服务计划，称为 PersonService。因此，我们将创建 PersonService 服务计划，然后默认插槽将是生产 (person-service)，然后我们将有另一个暂存插槽 (person-service-staging) 来满足暂存/测试需求。所有这些都将在同一个服务计划下提供。

今天我想到了一个可怕的想法，如果开发人员在暂存中部署了一些可怕的错误，耗尽了所有 CPU 和/或内存，那么生产槽将缺乏这些资源，并且基本上暂存环境会影响响应时间生产。

我认为会是这样吗？你们建议如何设置它以避免这个问题？谢谢

Answer 1

是的，你是对的，如果 person-service-staging 开始消耗大量底层服务器的资源，它将影响 person-service。

避免它在很大程度上取决于您当前的设置以及您的优先事项。添加开发/测试/登台服务计划是迄今为止最简单的方法。这使您的生产服务计划仅适用于生产就绪代码。使用部署槽只是为了方便在版本之间切换（如果您意识到生产中的某些内容已损坏，则可以快速回滚）

对此的替代方案是制定一个服务计划，该计划专门用于部署您作为测试管道的一部分进行部署。 Azure 建立服务计划的速度意味着您可以即时创建和销毁它们。这使您能够对登台服务器进行性能测试，当它运行在与您的生产代码相同的计划上时。

云计算的主要优势之一是能够创建一次性服务器。即使在 CI 场景中，也需要经过深思熟虑才能摆脱“那是我们的登台服务器”的旧理念——除非你每 30 分钟部署一次代码！ - 扔一些新服务器进行测试可能会更干净。即使您没有自动化测试管道，也只需将几个 Azure 自动化脚本连接到网页上的一个按钮（尽管令人惊讶的是这两个脚本的速度有多快！变成更优雅的东西/复杂）