检测Azure实例的崩溃

Question

我想检测一下我的Azure角色的实例已经崩溃的事实。在我的情况下检测意味着我的角色的另一个实例被通知崩溃。请查看下面解释的我的想法或提出另一种解决方案。

我提出的想法充分利用了Azure队列中的项目处理时间有限这一事实。

1. 配置Azure队列。该角色的所有实例都会侦听此队列。
2. 配置角色实例以具有内部端点
3. 当实例A启动时，它会向队列发布消息。该消息包含实例A的ID，A的内部端点的IP，此消息应转发回A的标记。
4. 消息最有可能在另一个实例B上结束.B将通过内部端点将MessageId和PopReceipt转发给A.实例A使用此ctr http://msdn.microsoft.com/en-us/library/dn451949.aspx创建CloudQueueMessage的对象。
5. 实例A开始无限地更新收到的消息的可见性超时。从Azure Queue的角度来看，此消息将被处理很长时间。在第一次更新中，A删除了“forward-this-message”标记。
6. 如果实例A崩溃，则会停止延长处理时间。该消息很快就会自动显示给其他实例。
7. 实例C获取消息并了解崩溃A：消息包含实例A的ID而没有“forward-this-message”标记。
8. 如果实例A正常停止，则会将其队列消息标记为已处理。

Answer 1

这一切看起来都很复杂。

就个人而言，我会回过头来看看我需要知道实例何时崩溃的原始假设 - 并考虑我对该信息的处理方式。我倾向于乐观的解决方案（即，假设成功和处理失败）而不是悲观的解决方案（即假设失败，因此提供一些机制来确保成功）。后者的一个问题是，无论如何你将不得不处理未声明的实例崩溃 - 所以为什么不把它作为默认行为。这是在实例上调用操作 - 并处理发生的任何故障。

例如，如果我想在另一个实例上的内部端点上调用操作，我将对所有其他实例进行负载平衡，并在检测到失败的实例时，尝试对另一个实例执行操作。 Ryan Dunn现在是一个古老的post，其中包括对内部端点的负载平衡。

我的基本观点是，在将消息从一个实例传递到另一个实例的情况下，很难强大地执行此类型的编排。有太多可能的失败点。最好提出一个更直接解决潜在需求的解决方案。一个简单的解决方案几乎总是比更复杂的解决方案更好。