为啥我应该使用 LoadBalancerProbe 而不是订阅 RoleEnvironment.StatusCheck 事件？

Posted 2023-02-19

技术标签:

【中文标题】为啥我应该使用 LoadBalancerProbe 而不是订阅 RoleEnvironment.StatusCheck 事件？【英文标题】：Why should i use a LoadBalancerProbe instead of subscribing to the RoleEnvironment.StatusCheck Event?为什么我应该使用 LoadBalancerProbe 而不是订阅 RoleEnvironment.StatusCheck 事件？ 【发布时间】：2012-12-06 18:02:21 【问题描述】：

我正在摆弄 azure 提供的用于平衡多个 webrole 之间负载的选项。

我找到了三种可能的方法。

第一种方法是什么都不做，让默认（循环）实现来完成这项工作。

第二种可能性是在 ServiceDefinitionFile 中定义一个自定义 LoadBalancerProbe，我尝试过但没有开始工作：据我了解，每次对角色执行状态检查时都会调用自定义 aspx 页面。根据 http 响应代码，角色将其状态更改为忙。 - 但这永远不会发生。此外，我真的找不到任何定义自定义 LoadBalancingProbe 的示例。

因此我寻找了另一种方法来做到这一点。

现在我正在订阅 RoleEnvironment.StatusCheck 事件，它允许我实现一些逻辑并根据结果将角色状态设置为忙碌和可用。

我的问题： 1）假设自定义LoadBalancerProbe按照MSDN中的描述工作，订阅StatusCheckEvent和使用自定义探针有什么区别？

2) 为什么我的自定义负载均衡器探测不起作用？ - 我现在只是在使用 azure 模拟器进行测试，并且我很清楚流量仍然会路由到 webrole 实例，尽管它们在模拟器中设置为忙。但是我的自定义探针根本不会改变 webroleinstances 的状态。

这是非常基本的代码，据我所知，它应该将 webrole instance_n_0 的状态设置为忙。

public class LoadBalanceController : Controller


    public ActionResult Index()
    

        WebOperationContext woc = WebOperationContext.Current;
        if(RoleEnvironment.CurrentRoleInstance.Id.ToLower().Contains("_0"))
        
            woc.OutgoingResponse.StatusCode = System.Net.HttpStatusCode.ServiceUnavailable;
        else
        
            woc.OutgoingResponse.StatusCode = System.Net.HttpStatusCode.OK;

                   

        return View(); //not relevant

我还配置了我的 servicedefinitionfile 并设置了一个路由以在调用自定义探针中定义的 healthcheck.aspx 时重定向到此控制器/操作。

<LoadBalancerProbes>
    <LoadBalancerProbe name="WebRoleBalancerProbeHttp" protocol="http" path="healthcheck.aspx" intervalInSeconds="5" timeoutInSeconds="100"/>
</LoadBalancerProbes>
...
<InputEndpoint name="EndpointWeb" protocol="http" port="80" loadBalancerProbe="WebRoleBalancerProbeHttp"/>

路线：

    routes.MapRoute(
            name: "HealhCheck",
            url: "healthcheck.aspx",
            defaults: new  controller = "LoadBalance", action = "Index", id = UrlParameter.Optional 

        );

【问题讨论】：

【参考方案1】：

不确定为什么自定义探测不起作用，但区别在于：运行状况检查事件可让您宣布实例是否可用，但在调用频率方面您没有任何灵活性。此外，您不能启动侦听自定义端口（或端口类型）的单独服务。

您可以使用自定义探针获得更大的灵活性，因为您可以创建任何类型的端口侦听器来确定运行状况，甚至是单独的 exe。

对于虚拟机，这是运行状况探测的唯一方法，因为虚拟机不运行来宾代理，也不提供运行状况检查事件。

【讨论】：

【参考方案2】：

在您的服务定义文件中，您已将探测标记为托管在 http 端点（而不是 HTTPS）上。

您的网络应用程序也是这样吗？它是否在 HTTP 而不是 HTTPS 上公开该端点？如果是，那么还要检查是否有任何自动重定向到 HTTPS 发生。

我认为您已经正确设置了所有内容。 Here 是一个帖子，其中包含一些示例代码和另一个 question from SO，他们成功地设置了它（应该提供对 csdef 文件的一些见解）。

我同意 David Makogon 关于两者之间差异的观点。

【讨论】：