ASP.NET C# 分布式负载均衡的操作是什么？

假如想要进行负载平衡，实际上建议直接购买云服务或硬件设备，这样基本上不需要进行任何配置和学习就可以很容易地进行负载平衡。别跟风各种反代 nginx，说白了有钱人买设备比自己鼓吹靠谱多了，没钱买设备用云服务也很划算。

在进行负载均衡之前，最重要的一点是，您的网站应用是否已准备好进行负载均衡，比方说，您是否已进行 Sessionless，请求处理时间是否均匀(在某些情况下，几秒钟处理一个请求？是否在代码中存在依赖全局锁(static对象上的锁)。

如果以上几点没有做好，比如严重的Session依赖，几十秒的请求处理时间长，一秒几百的处理时间短，代码中各种静态非线程安全的共享资源。建议你先重构系统，再考虑负载均衡。

做负载均衡，一般来说，刚开始已经做了一些工作，最基本的就是去除Session依赖，避免全局锁。然后配置机器密钥。如果无法释放会话相关性，则使用状态服务器模式。当然，直接释放Session依赖更好。

然后就是考验。IIS的WebFarm可以使用多个进程来处理请求，但是因为是在一台机器上测试，所以很多情况无法测试(比如machineKey不一致导致的问题)。

现在真的是一个非常好的时机，因为云计算已经非常成熟，所以负载均衡测试可以直接扔到云上去测试。如果您购买作为按需实例，您可能会购买几个最便宜的虚拟机，然后使用云负载平衡测试。经过一周的测试，要花两三百块钱才能上。这个测试和实际情况几乎没有区别。如果将来部署在云上，根本没有区别。

经过云测试，基本确定系统能够在负载均衡环境下稳定运行。此时可以对一些高度怀疑可能出现问题的地方进行补充测试，比如回发到不同的服务器，登录和注销到不同的服务器等等。这时可以直接打开Fiddler override去掉DNS解析，手动指定服务器测试各种可能出错的场景。

这些都完成之后，就可以进行压力测试了，有些问题只有在压力下才会暴露出来。同时，我们可以测试当增加负载节点时，压力阈值是否可以线性增加。如果不是线性增长，说明网站架构有问题，不能很好的利用负载均衡。
完成所有这些之后，有必要在将负载平衡器部署到生产环境之前对其进行监控和测试。也就是说，确认负载均衡器可以自动发现节点故障，自动迁移节点。高级负载平衡器还可以根据节点负载情况动态分配请求，尽可能将同一客户端的请求分配给同一服务器。这些都是需要测试的，而不是发现各种设备都是在线服务器挂机后才配置的。

完成之后可以进行压力测试，一些问题在压力下暴露出来。另外，还可以测试增加负载节点时所能承受的压力阈值是否线性增长，如果不是，说明一个网站架构不能很好地利用负载均衡。

基本上就是这样。其实主要看网站是否做好负载均衡的准备。这一步最关键。如果网站什么都准备好了，负载均衡其实就是点几个按钮的事情。