我正在寻找微服务架构中蔚蓝服务计划的最佳实践.我们有一系列微服务,每个微服务在容量,资源,开发人员和整体架构方面完全独立.不言而喻,如果一个服务遇到问题,如果不与有问题的服务交互,则不应该影响其他服务.这些服务托管在Azure中

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

今天我想到了一个可怕的想法,如果一个开发人员在升级中部署一些可怕的错误会占用所有的CPU和/或内存,那么生产槽就会从这些资源中匮乏,而且基本上,暂存环境会影响生产的响应时间.

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

最佳答案 是的,你是对的,如果人员服务阶段开始消耗大部分底层服务器的资源,它将影响人员服务.

避免它取决于您当前的设置以及您的优先级.添加dev / test / staging服务计划是迄今为止最简单的方法.这使您的生产服务计划仅用于生产就绪代码.使用部署插槽,只需在版本之间轻松切换(如果您意识到生产中的某些内容被破坏,则快速回滚)

替代方案是提供一个服务计划,该计划专门用于作为测试管道的一部分进行部署的暂存. Azure可以提供服务计划的速度意味着您可以动态创建和销毁它们.这使您能够在与生产代码相同的计划上运行时,对登台服务器进行性能测试.

云计算的一个主要好处是能够装箱一次性服务器.它需要经过深思熟虑的思考,即使在CI场景中,也要摆脱“那是我们的登台服务器”的旧哲学 – 除非你每30分钟部署一次代码！ – 抛出一些新服务器进行测试可能会更加清晰.即使您没有自动化测试管道,也只需要将几个Azure自动化脚本连接到网页上的按钮(尽管令人惊讶的是,这些脚本会多快地增加到更优雅的/复杂)