最近.NET的世界开始闹腾了，微软官方终于加入到了对.NET跨平台的支持，并且在不久的将来，我们在VS里面写的代码可能就可以通过Mono直接在Linux和Mac上运行。那么大家（开发者和企业）为什么那么的迫切的希望.NET跨平台呢？第一个理由是便宜，淘宝号称4万多台服务器全部运行在Linux，Linux平台下还有免费的MySql,这些都是免费的，这些省下来直接就是利润呀，做企业的成本可以降低又没有任何损失，何乐而不为呢？第二个理由是在Linux系统下还有很多非常优秀的构架（当然同样也是免费的），分布式缓存Memcached, 大数据处理构架Hadoop等等，这些都为一些大型的分布式系统提供了很好的支撑，当然还有诸如Liniux系统本身的一些安全和网络方面的优势，等等。 所以也难怪大佬们都纷纷不约而同的没有选择.NET。
但是如果.NET也支持跨平台之后，那这样的格局可能就要发生变化了。上面所有的优势依然可以保留，并且加上它语法的优越性，以及快速的开发效率等，还是会为其争得一席之地的。
但是，是不是Windows平台下就不能实现这些大型的分布式系统呢？我相信这个问题已经被广泛讨论过，但是至少我没有看到比较清晰的，完整的案例。带着这些问题，我决定升级我的机器，自己从头到尾在windows平台下搭建一个高可扩展性的分布式网站出来。我经验尚浅，很多的东西还处于摸索阶段，所以如果有错误，还请大师多多指点。
负载均衡可以帮我们解决两个方面的问题，第一个即提高可用性。这里面的可用性主要是从WEB服务器，的角度来讲的，如果说我们只有一台Web服务器，而它遇到了某种未知的错误导致IIS无法启动，那么我们的网站就无法访问了，这就是一种比较低的可用性。那么利用负载均衡，放在我们Web服务器的前面，由它来收集所有的请求，然后转发给我们的Web服务器， 这时候我们就可以添加两台Web服务器，如果其中有一台坏了，至少还有另一台在工作，也不至于导致我们的网络无法访问。
当然，有人可能会问，如果那台Load balancer坏了怎么办？那不是还是访问不了网站么？我们这里讨论的是提高可用性，在做到365天*24小时不间断的服务，需要有另外的组件来支撑，我们留在后面讨论。除了可用性以外，负载均衡还可以帮助我们提高可扩展性，当然这个可扩展性同样是指的Web服务器层面。从网站性能的角度来讲，好几个程序员花上好几天的时间做了一些优化所带来的效果有时候可能还没有直接加一根内存条来的快。内存加完了没什么影响，我们还可以换更好的CPU，CPU换完了，我们还可以用固态硬盘，甚至很多公司已经开始直接把数据放到内存中了（注：具体场景具体对待）。 如果这些都不可以再加了呢？那就再加机器吧，一台服务器可以处理1000个并发，那么两台理论上是2000了，所以这就有了我们的横向扩展。
所有的请求首先全部到达Load balancer，再由它转发到具体的Web服务器，转发的方式分为以下几种：
我们还可以根据负载均衡器所使用的技术将它们分为以下几类：
我们可以从一个网站的最初级版本开始说起，最开始的时候我们决定搭建一个网站，但是我们也不知道效果会怎么样，光键是那时候，我们很穷，于是我们租用了一台托管主机，它可能承担了至少三个或以上的角色：WEB服务器、静态资源服务器，以及数据库服务器。我们可以用ASP.NET MVC4 + SQL 2008来做一个基本的电子商务网站，基本够用了。但是能够承载多大的访问量呢？下面我们来做一个简单的测试（注意：本文以后本系列所面所有的测试都是在虚拟机上进行的，忽略网络的因素，以及多台虚拟机同时运行时CPU资源的因素，所以测试结果只是一个参考）。
在我的机器上有一台虚拟机配置如下：
CPU: Intel
Core I5- 4570, 3.19GHz,
内存: 4G
硬盘：20G (ShineDisk 固态硬盘)
测试页面没有什么复杂的逻辑，利用ASP.NET MVC4 + Entityframework 6.0 + SQL 2008 + IIS8.5来实现， 我们的页面也只是一个简单的列表页，列出系统里面所有的商品。
Home Controller
代码
Index.cshtml
代码
在数据库初始化的时候插入500条测试数据
连接字符串就使用本地连接就可以了。
|
1
2
3 |
<connectionStrings> <add name="CarolContext" connectionString="Server=localhost;database=carol;trusted_connection=true" providerName="System.Data.SqlClient" /></connectionStrings> |
我们使用的轻量级的ab来做压力测试，如果不熟悉ab的可以点这里，下面是测试的结果：
ab -n1000 -c100
http://192.168.1.131
通过测试发现，我们这单个服务器的吞吐率接近在110~130之间，而一旦并发数达到200以后，每个请求的处理时间就达到1.5s多了，400个并发用户的时候每个请求要花上3s多的时间。如果在真实的网络环境中可能会更差。由此我们可以得出我们这个服务器可能最大支持120人左右同时访问。
现在我们来做一个花费不是很大，又空间做的扩展，也不需要改任何架构，我们只是再加一台专门的数据库服务器。
下面我们再来看一下测试结果：
大家可以看到，这里我们的吞吐率(每秒处理请求数已经提升到了150左右)，并发处理能力提升了50%，并且300和400并发的时候响应时间也比上面的架构要好一些。
上面我们一台独立的Web服务器和一台独立的数据库服务器的组合已经可以处理150左右的并发了，现在我们假想一下如果网站的的知名度越来越大，如果同时有400个用户来访问怎么办？
从上面的图中我们可以看到400个并发的时候服务器的处理时间为2582.637ms（实现上这是拿到响应的时间，因为我们是一台机器上的不同虚拟机，我是在主机上做测试，所以我们就忽略网络传输的时间，假设这个就是我们的服务器处理时间），这个服务器响应时间也就是我们通过F12->网络 中看到的等待时间
。
页面什么时候能拿到这个响应还要加上网络传输的时间，也就是Receiving。1ms的传输时间堪称神速啊！我家用的长城宽带10M，总是早上网络出奇的好，一到晚上就挂掉了，还有可能就是你们现在都没有上博客园
:)
用户体验黄金法则之一:
网站加载时间 = 用户体验，别说3S，可能等个2S你页面还不出来，用户准备离开了，下面是淘宝购物车页面的加载时间 。
国内很多大型的网站的响应时间基本上都控制在100ms以内，基本达到那种一输入地址敲回车，眨眼之间页面就出来了。当然这并不是光有个负载均衡加几台web服务器就能解决的，我们后来再来一步一步的实践下去。 话说回来，我们上面的测试结果基本上只有并发为10的时候响应时间是在100ms以内的， 看来我们还有很长的一段路要走啊。
正所谓“最好的架构是进化而来的，而不是设计出来的” ，面对我们现在的瓶颈暂时通过负载均衡添加多台Web服务器就可以了。我们上面讲到负载均衡器类型的时候有一种 Microsoft负载均衡，我们可以很轻松的通过服务器管理器来将这些组件安装到我们的服务器中。 安装我们就不讲了，就是通过服务器管理-> 添加角色和功能->在功能中选择“网络负载均衡” 然后安装就可以了。
注意：图中的Load balancer实际上是不存在的，因为只要我们2台Web服务器安装了网络负载平衡组件，在其中任意一台上建立群集就可以了，图是为了方便大家理解。
这样的话我们的服务器架构就成了下面这个样子：
192.168.1.254
就是我们暴露的外部IP地址，访问192.168.1.254的请求就会转发给后面的两台WEB服务器。
配置网络负载均衡
在我们为上面2台WEB服务器安装NLB之后，我们在其中任意一台上来新建群集，然后将另外一台加入到这个群集中即可，我们就在web-01(192.168.1.130)上来新建这个群集。在建立群集之前，我们要确保这2台服务器都是使用的静态IP，否则无法将他们加入到群集中。
现在我们就可以到我们的真实机器上去访问192.168.1.254了，也就是说马上我们就进入测试环节了。
本文中所有的测试结果都没有取第一次的结果，EF也需要预热，同样的查询在EF中也是有缓存的，所以第一次的结果会与后面的测试结果有很大的区别，后面的几次（在相同参数下）基本差别就不大了。
可以看到现在我们的吞吐率大概平均在230左右，与一台WEB服务器+一台DB服务器相比，处理能力又提高了50%，为什么不是100%呢？一台WEB服务器能处理150的并发，那两台应该是300才对呀？我能够想到以下原因：
为了验证一下，我再扩展了一台WEB服务器，我们使用3台WEB服务器+1台DB服务器看看是什么效果。
我们新建一台虚拟机web-03，然后将它也加入到我们的群集中。
测试开始！
在加入第三台WEB服务器之后，我们的吞吐率（每秒处理请求数）再次得到提升从230升至360，并发处理能力再次提升56%，并且大家可以看到，400并发以下的平均每请求处理时间都在1s以内，可喜可贺啊！
最后上两图让大家更直观的看一下这些性能的变化：
以上数据均来自本人机器上的测试，虚拟机全部采用与第一台服务器同样的配置。
在网站架构的不断演变中，负载均衡起着非常重要的位置，不仅仅为我们提升可靠性和可扩展性，有一些比较强大的硬件设备还能提供缓存，以及session机制。今天我们用到的负载均衡是Windows Server自带的一个组件，它是最简单实现负载均衡的方式，但是功能不是特别完善，而且一旦NLB本身发生错误那么将导致所有的网站都不能访问，我们后面就来通过引入APR(Application Request Router)来解决这个问题，想要真正了解大型网站的架构实现，而不是仅仅知道负载均衡，分布式缓存，数据库分离这些名词么？那就来跟我一起学习吧！另外我们今天只是用一个简单的页面做了压力测试，只有读数据的操作，还没有写的操作，也没有任何复杂的事务，但是别担心，我们一步一步来 :) 。
Windows平台分布式架构实践 - 负载均衡(转),布布扣,bubuko.com
原文地址：http://www.cnblogs.com/wsfjlagr/p/3746887.html
