0

我想检测我的 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 队列的角度来看，此消息将被处理很长时间。在第一次更新中，A 删除了“转发此消息”标记。
  6. 如果实例 A 崩溃，它将停止延长处理时间。该消息将很快对其他实例自动可见。
  7. 实例 C 获取消息并了解崩溃的 A：消息包含实例 A 的 ID，并且没有“转发此消息”标记。
  8. 如果实例 A 正常停止，它会将其队列消息标记为已处理。
4

1 回答 1

0

这一切似乎都非常令人费解。

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

例如，如果我想在另一个实例的内部端点上调用操作，我将对所有其他实例进行负载平衡，并在检测到失败的实例时尝试在另一个实例上执行该操作。Ryan Dunn 有一篇关于内部端点负载平衡等内容的古老帖子。

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

于 2013-10-22T19:39:19.957 回答