Windows下做7层软负载的经验分享Windows下做7层软负载的经验分享(2)Windows下做7层软负载的经验分享(3)Windows下做7层软负载的经验分享(4)
本文将为大家介绍在windows下做7层软负载做了一些分析，对负载这块有兴趣的你，可以来看看哦。其实所谓四层就是基于IP+端口的负载均衡;七层就是基于URL等应用层信息的负载均衡;你对7层,有了浅显的印象吧,那大家有啥做7层软负载的经验可以讨论分享一下呢，当然最好是windows平台下的。性能分析
1、 对外网的连接管理和协议解析使用http.sys(HttpApi.dll,HttpListener)内置机制，http.sys在内核级别进行HTTP的连接管理和协议解析，性能应该可以保证。
2、 对内网RealServer的连接管理和拼包使用HttpWebRequest的内置机制，但有如下问题
a) 连接管理：默认Proxy向RealServer发送请求会新建立一个连接，收到应答后会拆除连接，也就是说Proxy和RealServer之间会建立大量连接，但是由于受端口(65535)限制，出站连接不可能太多。这个问题要想办法解决，可以尝试把RealServer启用KeepAlive解决。
b) 拼包：HttpListener收到包后，虽然自动已经解析成对象，但是还要把这些包重新拼成HttpWebRequest的格式发给 RealServer，这里面包括拷贝Uri,HttpHeader，Cookies,Body等，这些数据量挺大的，在内存中拷贝一遍肯定损耗性能。该问题应该无法规避。
3、如果是常规的web应用(资源访问类)，Request小，Response很大，RealServer返回Response时还要经过Proxy，还要进行内存拷贝，这个也非常影响性能。然后7层又做不到LVS的那种DirectRoute机制(需要修改网络包的mac地址)，实现IP隧道和TCP的状态迁移需要修改操作系统的TCP/IP协议栈。鉴于代价太大，该问题也无法规避。
4、 Http协议规定请求和应答必须成对出现，默认情况下一条连接上发送出去请求后要等到收到该请求对应的应答后才能发送下一个请求，虽然Http1.1有 pipeline功能，可以成批发送请求，不必先等待应答，但是也有诸多限制，比如规定了POST不应该使用pipeline，一条连接上第一次发送请求也不可以使用pipeline机制，还有每批请求的请求数也不好定夺，批量发送请求后，如果连接断开，会有多个请求失败，等等。HTTP协议不像SIP协议那样靠CallID和Cseq来匹配请求和应答，那样可以纯异步的收发请求和应答，所以在实现Http协议栈时要同步等待应答，然后该连接上才能发送下一批请求，这必然会影响性能。
5、 HttpListener的异步接收请求和发送应答是普通的APM模式(BeginXXX,EndXXX格式)，这种异步模式在频繁调用时会大量产生和销毁IAsyncRequest对象，从而增加了GC的压力，而且IAsyncRequest对象还没有提供自定义池化的接口。如果 HttpListener提供了新的基于事件的异步模式(XXXAsync(eventargs)模式，参考Socket.ReceiveAsync方法)会解决这个问题。
6、另外由于HttpLisenter是.net的包装类，在用户态执行，而HTTP.SYS是内核态运行，在接受请求，返回应答会进行两次用户态和内核态之间的切换，从而降低性能，如果能在内核态直接进行7层转发就好了，在linux下LVS(KTCPVS)可以做到内核态的基于内容的7层转发，在 windows下可能需要做TDI或者NDIS开发，查了些资料，太复杂了，所以也不考虑了先。
可靠性分析
为了容灾，提高可靠性，考虑如下方案
1. 7层软负载的前面要有4层负载设备，7层软负载多台，且共享哈希策略，4层设备按Session做随机负载，这样所有的7层软负载机器均可正确处理任何一个请求，且某台7层软负载宕机后，剩下的7层软负载可继续工作，由于4层负载有keepalive功能，可以检测出哪台7层软负载宕机了，并且不给其转发请求。
2. 7层软负载做双击热备，7层软负载直接接入外网，正常情况下由主服务器处理请求，如果主服务器宕机，备份服务器发现后，通过ARP欺骗获取主服务器原有 IP，以把请求吸引到备份服务器上处理(硬件如果支持可能可以考虑主备机共享一个MAC地址)，主备切换时可能会造成短时请求失败的现象。
综合考虑，第二个方案有些山寨和不保险，优先考虑第一个方案。
单元测试
场景设计：
比如一个获取用户头像的请求，用户的头像存放在多台DB里，并由多个web服务器(webserver1,webserver2)缓存头像并根据用户的HTTP请求返回给客户端用户头像，由于web服务器缓存了用户头像，是有状态服务，所以HTTP请求里要带userid参数，7层负载根据 userid做哈希后把请求路由给缓存该userid对应用户头像的web服务器。
请求格式:
GET /getportrait.aspx?userid={userid}
其中{userid}是Int32类型，路由算法是{userid} mod 2 = 0的话路由给webserver1 ，{userid} mod 2 = 1的话路由给webserver2
应答格式:
200 OK HTTP1.0
Content-Length:5
Content-Type:text/txt
{userportrait}
其中为了测试方便{userportrait}为文本格式，就是webserver本身的机器名字
测试用例：
请求GET /getportrait.aspx?userid=1111，预期返回应答webserver2
请求GET /getportrait.aspx?userid=2222，预期返回应答webserver1
具体测试userid可随机生成整数，并根据是否可被2整除对应答进行预期。
性能测试
测试准备：
两台物理机RealServer1和RealServer2,一台软负载机器SoftProxy，两台测试机TestClient1,TestClient2。
其中SoftProxy的配置：Xeno 3.0G(16核)，16G内存，windows2003 x64, 千M网卡(先不考虑双网卡均衡)。
RealServer配置：Xeno 1.86G(4核)，8G内存，windows 2003 x86
部署：
RealServer1和RealServer2部署具有返回用户头像的服务，SoftProxy部署7层软负载，TestClient1和TestClient2部署LoadRunner及测试脚本进行测试。
测试模型：
在线用户：300个虚拟用户，每个虚拟用户模拟1000客户端，共模拟300000在线用户,每个用户每5秒获取一次头像。
测试预期：
预期SoftProxy每秒处理6w的获取头像请求，并且CPU利用率在80%以下，内存利用率在5G以下。
其它问题
1、 客户端IP
a) 因为RealServer接收的是SoftProxy的请求，不能直接知道客户端IP，所以SoftProxy需要在转发包的时候加上一个http header以告诉客户端IP
2、 重定向，身份验证，临时应答,缓存等问题
a) httpRequest.ServicePoint.Expect100Continue = false;
b) httpRequest.ServicePoint.UseNagleAlgorithm = false;
c) httpRequest.AllowWriteStreamBuffering = false;
d) httpRequest.AllowAutoRedirect = false;
e) httpRequest.AuthenticationLevel = AuthenticationLevel.None;
f) httpRequest.AutomaticDecompression = DecompressionMethods.None;
g) HttpRequestCachePolicy noCachePolicy =
new HttpRequestCachePolicy(HttpRequestCacheLevel.NoCacheNoStore);
httpRequest.CachePolicy = noCachePolicy;
3、 Cookies咋办?
a) HttpWebRequest并不支持直接写cookie，只能创建cookie容器，等应答回来后才会有cookies，这个比较郁闷，暂时如下这样写，收到RealServer的应答后把应答里的Cookies复制给Listenresponse并返回给客户端
httpRequest.CookieContainer = new CookieContainer();
HttpWebResponse httpResponse = (HttpWebResponse)httpRequest.GetResponse();
listenresponse.Cookies = httpResponse.Cookies;
4、 超时值，不好定夺
a) httpRequest.Timeout = 20;
b) httpRequest.ReadWriteTimeout = 10;
对windows下做7层软负载做了一些分析，感觉最不靠谱的就是HttpWebRequest，这玩意实现太复杂，包装太深，而且也不是设计为发送大量出站HTTP连接用的，HttpListener应该还行，就是设计为做HTTP服务器用的，实在不行Proxy和RealServer之间用 Remoting传递HTTP信息，然后两边把Remoting再转换成HTTP信息。
