ASP.NET中如何实现负载均衡

浏览数：17 / 时间：2015年06月09日

ASP.NET站点中做负载均衡：

　　基于HTTP协议我们可能发现我们要解决两点问题：

　　第一，做到负载均衡，我们需要一个负载均衡器。

　　可以通过DNS轮询来做，在DNS服务器上配置为每次对我们做负载均衡的同一主机名的DNS查询得到不同的IP地址。这样的好处是配置简单投入较小，缺点是浏览器访问各个服务器的机会是均等的，不能根据服务器的负载程度自动把请求路由到负载较小的服务器。

　　可以通过专用的负载均衡设备，通过监测后台数台服务器的负载情况，自动把HTTP请求转发到负载较轻的服务器。另外必须监测后台服务器的IIS负载情况，而不是整台服务器的CPU负载。同时可能需要在负载均衡器和后台服务应用之间建立心跳连接，以避免出现某台服务器IIS进程或者其中跑的应用已经down掉，负载均衡器反而监测到这台服务器的负载最小而把大量请求转发的这台服务器，达到相反的效果。

　　第二，Session状态的保持和迁移。

　　由于HTTP协议的无状态性，我们一般是在Session中保存客户端的一些状态数据，负载均衡之后，前后两次HTTP请求所到达的服务器可能不是同一台，这就造成可能出现这样的情况，前一此请求处理中设置的session在第二次请求中变得不可用了，造成应用程序出错。所以我们要把session跟随迁移。实现的方法就是session的统一存储和服务器间共享。

　　在ASP.NET中服务器保存session有五种方式，Off不说了，InProc是保存在服务器进程的内存中，显然不能满足要求。另外两种能够满足：

　　StateServer是把session保存在专门的状态服务器中。这样各台服务器都存取同一个StateServer，达到共享的目的。

　　SQLServer是把session保存在数据库中。同样能达到目的。

　　Custom自定制的存储方案，我们自己写当然能够实现。

　　比较一下，Custom这种自己实现比较麻烦一般不用，SQLServer可以利用数据库的cluster达到高性能和高可用性的目的，StateServer当然也可以通过手段达到高可用性，不过似乎不能实现集群所以性能也有所限制。

　　另外如果要做负载均衡在StateServer和SQLServer中配置session时，必须在web.config中重写machineKey节点：

　　<machineKey

　　validationKey="1234567890123456789012345678901234567890AAAAAAAAAA"

　　decryptionKey="123456789012345678901234567890123456789012345678"

　　validation="SHA1"

　　decryption="Auto"

　　否则各个应用服务器拿到的session还是不一样的。

　　可能Custom方式可以自己定义存取session方式忽略machineKey，这可能就不必要了，因为没有做过，不多说。

1：HTTP重定向

所谓HTTP重定向，就是通过修改HTTP响应头中的Location标识为新的URL，然后返回给客户端，让客户端重新根据这个Location标识的URL去做新的请求。

这是一种最简单、也是最轻量级的负载均衡实现方案，使用asp.net，我们可以这样来实现，比如在主站www.yourdomain.com中，我们在默认主页如下编码：

static string[] servers = 
        {
            "http://192.168.0.77/luminji2/aspx/test3.aspx",
            "http://192.168.0.77/luminji2/aspx/test4.aspx"
        };
protected void Page_Load(object sender, EventArgs e)
{
    Response.Redirect(servers[DateTime.Now.Millisecond % 2]);
}

在上面的代码中，Response.Redirect实际为http头返回状态码302，这是为了告诉浏览器，请到Location中去拿URL，并且去到这个新的URL去做请求。当然，我们也可以采用最原始的方法来代替Redirect方法：

  
    Response.Status = "302 Found";
Response.StatusCode = 302;
Response.AddHeader("Location", servers[DateTime.Now.Millisecond % 2]);

使用HttpWatch监视，我们对www.yourdomain.com请求，得到：

可以清晰的看到第一次请求返回的302，然后转发到新的地址，得到状态码200。

以上方法是在客户端的重定向，即浏览器请求了两次，一次是到主服务器，第二次是到Location中指定的服务器上去请求。

HTTP重定向的方式非常依赖于主站的处理能力，它的性能瓶颈也是来自于IIS对于接受请求->asp.net处理首页动态程序->返回带有特定头请求，是的，它不能突破自身的性能瓶颈，比如，在我的破测试机上，我得到的吞吐率为：

好在IIS自身已经支持重定向（查阅http://technet.microsoft.com/zh-cn/library/cc732969(WS.10).aspx），这更进一步省略了我们自己写代码实现重定向，省略运行ASP.NET代码带来的性能损耗。

2：varnish实现的反向代理负载均衡

另外一种思路是使用反向代理服务器的负载均衡功能，上篇当中介绍的varnish就支持这样的功能，查看配置文件：

  
    backend web1 {
     .host = "192.168.0.77";
     .port = "8081";     
}
backend web2 {
     .host = "192.168.0.77";
     .port = "8082";
}
director lb round-robin {
    {
        .backend = web1;
    }
    {
        .backend = web2;
    }
}
 sub vcl_recv {
     set req.backend = lb;
     return (pass);
 }