暂存插槽和VIP交换 [英] Staging slot and vip-swap

问题描述

从经典的Cloud Service模型开始，到现在已经使用了5年，我们已经非常熟悉暂存插槽和vip交换功能的概念.是的，这种升级模型有很多缺点，但也有很多好处.

Coming from the classic Cloud Service model, after having used it to 5 years now, we are very used to the concept of a staging slot and the vip-swap capability. Yes this upgrade model has many warts but also many benefits.

很显然，SF没有公开此模型.所以我想知道这是否不是Cloud Services中流行的模型，还是6年后真的没有意义吗?

Clearly the SF doesn't expose this model. So I wonder was it just not a popular model in Cloud Services, or does it just really not make sense 6 years later?

这是范式变更之一，我只需要重新考虑我们的部署方式，并逐步采用新规定的模型(滚动升级)?还是有已知的技术来设置诸如带SF的暂存槽之类的东西?

Is this one of those paradigm changes where I just have to re-think how we deploy, and forge ahead with the newly prescribed model (rolling upgrades)? Or are there known techniques to setting up something like staging slots with SF?

正在寻求建议...

推荐答案

VIP交换对于有状态计算没有意义，而且Service Fabric在很大程度上是有状态计算平台(即使您仅使用无状态服务，系统本身也会提供服务)是有状态的).如果您的服务中有数据，则要保持数据并保持一致，就必须进行滚动升级.

VIP swaps don't make sense for stateful compute, and Service Fabric is largely a stateful compute platform (even if you only use stateless services, the system services themselves are stateful). If your services have your data in them, you have to do a rolling upgrade if you want to keep your data and keep it consistent.

是的，这是一种范式变化，但它是一个很好的变化.它鼓励持续交付和频繁升级，因为升级直接集成到平台中，并且不会花费您任何额外的费用.您无需为登台的VM付费，这对于大型部署而言可能会非常昂贵，甚至可能会阻止持续交付.

So yeah, it's a paradigm change, but a good one. It encourages continuous delivery and frequent upgrades because upgrades are integrated right into the platform and don't cost you anything extra. You don't need to pay for staging VMs, which can get expensive for large deployments, and that might even discourage continuous delivery.

现在，您可以执行类似于无状态服务的分段部署的操作.在Service Fabric中，您的部署"是应用程序，而不是VM.因此，您可以将新应用程序版本的实例与先前应用程序版本的实例并排创建，并按需要路由您的流量，无论是逐步将用户转移到新版本的实例，还是只需切换一下并一次将所有流量发送到新版本.当然，这对于有状态服务不起作用，因为您的所有数据仍在先前版本的应用程序实例中.

Now, you can do something similar to a staging deployment for stateless services. In Service Fabric, your "deployments" are applications, not VMs. So you can create an instance of a new application version side-by-side with an instance of the previous application version and route your traffic however you want, whether that's gradually move users to the instance of the new version, or just flip a switch and send all your traffic to the new version all at once. This of course doesn't work for stateful services, because all of your data is still in the previous version application instance.

这篇关于暂存插槽和VIP交换的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！