如果要做负载均衡,其实建议直接购买云服务或者硬件设备,这样基本上不需要什么配置和学习就可以轻松的搭建负载均衡。不要跟风各种反代nginx,说白了有钱的话买个设备比自己鼓捣靠谱多了,没钱买设备用云服务也是很划算的。
做负载均衡之前最重要的是你的网站应用是否针对负载均衡做好了准备,譬如说是不是已经做了Sessionless,请求处理时间是不是均匀(会不会有几秒钟处理一个请求的情况?)。代码里面是否有依赖全局锁(对static对象的锁)
如果对于上面的几点还没有做好,例如严重的Session依赖、请求处理时间长则几十秒,短则一秒钟处理上百个,代码里面各种静态的非线程安全的共享资源。建议你们先对系统进行重构,然后再考虑负载均衡这回事儿。
要做负载均衡,一般来说一开始就已经做了一些工作,解除Session依赖和避免全局锁是最基本的。然后就是配置
machineKey,如果无法解除Session依赖,改用StateServer模式,当然最好还是直接解除Session依赖。
然后就是测试了,IIS的WebFarm可以使用多个进程来处理请求,但是因为是在一台机器上测试,很多情况是无法测试到的(例如machineKey不一致导致的问题)。
现在真是一个非常好的时代,因为云计算已经非常成熟,所以负载均衡的测试可以直接丢到云上去测试。如果以按需实例来购买的话,大概购买几台最便宜的虚拟机,再使用云负载均衡测试,测试一周时间算下也就两三百块钱到顶了,这种测试和实际情况几乎没有任何区别,如果你以后是部署在云上的话,那更是根本不存在区别了。
经过云测试后,基本确定系统在负载均衡环境可以稳定运行,这时候可以针对一些高度怀疑可能出问题的地方进行补充测试,例如PostBack到不同的服务器,登录和注销在不同的服务器等。此时可以直接开Fiddler override掉DNS的解析,手动指定服务器对各种可能出问题的场景进行测试。
这些都完成后可以进行压力测试,有些问题在压力的情况下才会暴露。同时可以测试一下增加负载节点时所能承受的压力阈值是否线性增长,如果不是线性增长,说明网站架构有问题不能很好地利用负载均衡。
最后这些都完成后,需要部署到生产环境之前,还需要进行负载均衡器的监测测试。也就是确认负载均衡器能自动发现节点故障,自动迁移节点。高级一点的负载均衡器还能根据节点负载情况动态分配请求,以及尽可能的对于同一客户端的请求分配到同一服务器。这些都需要进行测试,而不是到了线上服务器挂了才发现各种没有配置。
做完这些,就可以开始部署了。这个时候你就需要考虑以后升级更新的问题,一旦网站进行负载均衡,升级更新就不能用原来的经验。一般来说可以这样做:
在更新网站时,先将一台网站服务器从负载均衡节点中移除,对其进行更新,测试完毕后,再将一半的网站服务器从负载均衡节点中移除,将这些服务器全部更新到最新版本。对安装到最新版本的网站群进行压力和负载均衡测试,测试通过后,将负载均衡器整体切换到更新了的网站群。最后将剩下的网站服务器全部更新,再纳入到负载均衡节点中。
基本上就这些了,其实主要还是看网站是否对负载均衡做好了准备,这个步骤是最为关键的,若网站做好了一切准备,那负载均衡其实就是点几个按钮的事情。