1楼（站大爷用户）

分布式均衡一般是利用服务器 不是利用你的开发语言去实现

2楼（匿名用户）

这个培训课中有详细讲解 http://www.jinhusns.com/Products/Curriculum/?type=f

3楼（未知网友）

写写我的经验吧，楼上@lvony 和@陈计节 已经描述得挺全了，两位大大好像都说错了一点，单机多进程是Web Garden ，多机才是Web Farm～
我认为分布式最为要命的地方也是在于一些全局数据的使用，甚至在必要的时候是需要在某些点使用集中式的方式。例如大家都提到了Session，通过自定义Session是不难做到Session的集中管理的，而Session容器的选择实际也提供了分布式的选项。 在我的应用场景中最难处理的实际上是Cache同步的问题，Cache分布于多机，而且Cache大量参与了查询，如何尽量保证Cache的一致性困扰了我不少时间，目前是通过引入消息中间件以解决这一问题。 目前我们这方面依托于Redis提供Session服务和消息中间件服务，目前看来完全能满足需求。
而我更同意@仁殿宇 的说法，分布式Web与语言无关，与设计思路有关，这也是所有分布式应用设计所强调的一点：如果你要分布式，请从一开始就注意使用分布式的思想去解决问题。

4楼（未知网友）

负载均衡一般是从网络层面实现的，与开发语言和运行平台没有关系。
windows自身也有，开源的软件很多，商业的硬件也有

5楼（未知网友）

曾在去年为一个客户做过基于 nginx 的负载均衡，后来再加上一些新的实践，总结了一下，愿意分享。
实际上，我目前接触的项目，也并不算大，并没有针对超大型项目（如事务和逻辑密集型、大量并发的应用）做过相关实践，如果有人在相关领域有更好的方案，欢迎探讨。

分布式的程序与单个实例运行是有很大区别的，所以在分布式之前，请确保你的应用在开发阶段最好有相关的准备。一个完全针对单服务器环境开发的应用，要想在分布式均衡系统中完美运行，要做的工作之多会让运维人员抓狂。
IIS 提供了 Web Farm 部署的能力，即针对在同一台服务器上的特定 Web 站点，为其应用程序池配备多个进程。这种方式可以一定程序上模拟应用在分布式环境下的运行情况，比如 Session、Cache 的共享和身份鉴权等。但由于分布式负载均衡通常使用反向代理来完成入口服务器与多个分布式运算服务器之间的传输，因此在分布式负载均衡环境中，运行在不同服务器（或相同服务器上的不同 IIS 站点实例）可能在 Request URL 运算、文件存储、相对路径映射等这些方面与单实例运行时存在差异。

因此，在准备阶段请先确定你已经解决了上述这些问题，在这里我就不展开了，毕竟针对不同的应用会有不同的具体工作。而后，接下来的工作就显得很从容了。
分布式负载均衡的一般思路是整个系统仅有一个统一入口，再由这个统一入口 E 按配置的均衡规则将请求「反向」代理到多个运算服务器 S，最后再将由 S 运算得到的结果输出到客户端。
在每个 S 上，使用单实例时一样的配置：每一个 S 就是一个在普通部署方式下的正常服务器：因此要将它们的数据库连接串、Session 提供程序、Cache 提供程序、Form 鉴权所需的必要的 machineKey 等相关资源配备到统一位置或作统一处理，以保证所有 S 工作状态的一致性（即当用户的请求到达任何 S 时，其会话状态、缓存状态等都一致）。
在 E 的反向代理软件上，将所有 S 按策略配置完善（包括服务器位置、端口与权值；代理 IP和原始 host 头等）。出于安全考虑，可以将所有 S 的访问限制为仅 E 能访问，而 E 则应该配置为能够公开访问，最后将域名解析到 E 上。
注意，所有后续请求将先到达 E 上，然后再由 E 按照配置的策略分配给具体的某一个 S。因此，如果应用中有上传文件、自定义 MIME 类型、错误页等可能与 IIS 默认限制/功能相关的特性，注意 E 与 S 在这些配置上的一致性。

此外，关于 E 上要使用的反向代理软件，可以使用大家广为熟悉的 nginx，也可以使用微软与 IIS 集成的 Application Request Routing 组件（ARR）。

6楼（未知网友）

怎么会混进nginx这样奇怪的东西。。。

c# http://asp.net玩这个当然要用原生高大上的windows server nlb （network load balancing）了，具体怎么配置去翻technet吧

7楼（未知网友）

如果要做负载均衡，其实建议直接购买云服务或者硬件设备，这样基本上不需要什么配置和学习就可以轻松的搭建负载均衡。不要跟风各种反代nginx，说白了有钱的话买个设备比自己鼓捣靠谱多了，没钱买设备用云服务也是很划算的。

做负载均衡之前最重要的是你的网站应用是否针对负载均衡做好了准备，譬如说是不是已经做了Sessionless，请求处理时间是不是均匀（会不会有几秒钟处理一个请求的情况？）。代码里面是否有依赖全局锁（对static对象的锁）

如果对于上面的几点还没有做好，例如严重的Session依赖、请求处理时间长则几十秒，短则一秒钟处理上百个，代码里面各种静态的非线程安全的共享资源。建议你们先对系统进行重构，然后再考虑负载均衡这回事儿。


要做负载均衡，一般来说一开始就已经做了一些工作，解除Session依赖和避免全局锁是最基本的。然后就是配置machineKey，如果无法解除Session依赖，改用StateServer模式，当然最好还是直接解除Session依赖。

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


现在真是一个非常好的时代，因为云计算已经非常成熟，所以负载均衡的测试可以直接丢到云上去测试。如果以按需实例来购买的话，大概购买几台最便宜的虚拟机，再使用云负载均衡测试，测试一周时间算下也就两三百块钱到顶了，这种测试和实际情况几乎没有任何区别，如果你以后是部署在云上的话，那更是根本不存在区别了。

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

这些都完成后可以进行压力测试，有些问题在压力的情况下才会暴露。同时可以测试一下增加负载节点时所能承受的压力阈值是否线性增长，如果不是线性增长，说明网站架构有问题不能很好地利用负载均衡。

最后这些都完成后，需要部署到生产环境之前，还需要进行负载均衡器的监测测试。也就是确认负载均衡器能自动发现节点故障，自动迁移节点。高级一点的负载均衡器还能根据节点负载情况动态分配请求，以及尽可能的对于同一客户端的请求分配到同一服务器。这些都需要进行测试，而不是到了线上服务器挂了才发现各种没有配置。

做完这些，就可以开始部署了。这个时候你就需要考虑以后升级更新的问题，一旦网站进行负载均衡，升级更新就不能用原来的经验。一般来说可以这样做：

在更新网站时，先将一台网站服务器从负载均衡节点中移除，对其进行更新，测试完毕后，再将一半的网站服务器从负载均衡节点中移除，将这些服务器全部更新到最新版本。对安装到最新版本的网站群进行压力和负载均衡测试，测试通过后，将负载均衡器整体切换到更新了的网站群。最后将剩下的网站服务器全部更新，再纳入到负载均衡节点中。



基本上就这些了，其实主要还是看网站是否对负载均衡做好了准备，这个步骤是最为关键的，若网站做好了一切准备，那负载均衡其实就是点几个按钮的事情。