自动Azure VIP交换

Question

我有一个ASP.NET MVC 4应用程序作为Azure Web角色托管。我想做一些看起来应该是非常标准的事情：我想创建一个函数，我可以调用这个函数，当VIP交换操作完成时，它启动一个VIP交换，并引发事件（或调用回调）。

只是为了添加一些情境：我的网站实现了一个工作流程，需要大约一个小时（或更少）才能完成。如果我想发布一个新版本的网站代码，那么它很方便（也就是说，更少的“后向兼容性”代码来编写），首先让所有当前用户完成工作流程，以便新代码不需要处理由以前版本的代码创建的数据。因此，我的网站中的管理功能首先会向数据库中添加一个值，以禁用新的工作流程;它会等到所有当前的工作流程完成;然后它会调用“VIP交换”例程;最后，当VIP Swap程序发出完成信号时，它将戳数据库值以重新启用新的工作流程。

我找到了如何以编程方式启动VIP掉这里的微软文档： http://msdn.microsoft.com/en-us/library/ee460814.aspx

该过程涉及张贴到一个神奇的URL，并包括一些头在POST，然后定期执行得到一个神奇的URL并检查响应代码。

我越想到这件事，似乎就越不重要。除了配置后台计时器和完成通知的基本复杂性之外，我不知道在IIS环境中可能会遇到什么样的复杂性（如果有的话）。我甚至可以在后台线程上执行HTTP操作吗？对于这个问题，我是否会遇到复杂情况，只是试图使用.NET中的任意六种不同的“在背景中执行操作”机制？

任何帮助或指导将不胜感激。特别是，如果有人可以指示我准备好执行此功能，我会欣​​喜若狂！

Answer 1

我不认为你会找到一个简单的解决方案，因为布料控制器设置为做一些非常花哨的事情，没有你的参与。运行在云计算环境中，一个实例可以从你的下方拉出，长达一小时的工作流程（从OnStopping事件最多5分钟被称为清理），您需要做其他工作无论如何要确保你的所有任务都完成了。

简单的问题是“如果工作流仍在运行时发生实例故障，你会怎么做？”你重新启动它们还是丢失了？如果他们迷路了，那么你也不在乎，所以杀死升级工作流程同样不重要。如果重新启动，然后他们使用相同的机制来决定一个节点是否是因被关闭，并相应地分发作业。这种模式与Hadoop JobTracker非常类似。不要只在任何ol实例上运行工作流程。将它们提交给（作业跟踪器）服务，以决定要做什么。然后，（作业跟踪器）服务可以使用服务管理API来扩展尽可能多的实例，并根据需要运行所需的版本，在适当的节点上运行工作流，并在不再需要或过时时关闭它们。

不幸的是，这可能不是你正在寻找简单的解决方案，但一些在你的架构需要改变，而不是试图迫使PaaS的，以适应与你目前的做法。分解工作负载，创建松散耦合的服务，设计失败以及其他一些云/分布式计算实践需要考虑。有一个原因可以说Hadoop的构建方式就是这样 - 它能够在一堆不太可靠的商品硬件上完成工作。