|
概述
最近.NET的世界开始闹腾了，微软官方终于加入到了对.NET跨平台的支持，并且在不久的将来，我们在VS里面写的代码可能就可以通过Mono直接在Linux和Mac上运行。那么大家（开发者和企业）为什么那么的迫切的希望.NET跨平台呢？第一个理由是便宜，淘宝号称4万多台服务器全部运行在Linux，Linux平台下还有免费的MySql,这些都是免费的，这些省下来直接就是利润呀，做企业的成本可以降低又没有任何损失，何乐而不为呢？第二个理由是在Linux系统下还有很多非常优秀的构架（当然同样也是免费的），分布式缓存Memcached,
大数据处理构架Hadoop等等，这些都为一些大型的分布式系统提供了很好的支撑，当然还有诸如Liniux系统本身的一些安全和网络方面的优势，等等。
所以也难怪大佬们都纷纷不约而同的没有选择.NET。
但是如果.NET也支持跨平台之后，那这样的格局可能就要发生变化了。上面所有的优势依然可以保留，并且加上它语法的优越性，以及快速的开发效率等，还是会为其争得一席之地的。
但是，是不是Windows平台下就不能实现这些大型的分布式系统呢？我相信这个问题已经被广泛讨论过，但是至少我没有看到比较清晰的，完整的案例。带着这些问题，我决定升级我的机器，自己从头到尾在windows平台下搭建一个高可扩展性的分布式网站出来。我经验尚浅，很多的东西还处于摸索阶段，所以如果有错误，还请大师多多指点。
您还可以查看本篇的续篇: Windows平台下利用APM来做负载均衡方案 - 解决Session同步问题，以及彻底提高可用性。
什么是负载均衡
负载均衡可以帮我们解决两个方面的问题，第一个即提高可用性。这里面的可用性主要是从WEB服务器，的角度来讲的，如果说我们只有一台Web服务器，而它遇到了某种未知的错误导致IIS无法启动，那么我们的网站就无法访问了，这就是一种比较低的可用性。那么利用负载均衡，放在我们Web服务器的前面，由它来收集所有的请求，然后转发给我们的Web服务器，
这时候我们就可以添加两台Web服务器，如果其中有一台坏了，至少还有另一台在工作，也不至于导致我们的网络无法访问。
当然，有人可能会问，如果那台Load balancer坏了怎么办？那不是还是访问不了网站么？我们这里讨论的是提高可用性，在做到365天*24小时不间断的服务，需要有另外的组件来支撑，我们留在后面讨论。除了可用性以外，负载均衡还可以帮助我们提高可扩展性，当然这个可扩展性同样是指的Web服务器层面。从网站性能的角度来讲，好几个程序员花上好几天的时间做了一些优化所带来的效果有时候可能还没有直接加一根内存条来的快。内存加完了没什么影响，我们还可以换更好的CPU，CPU换完了，我们还可以用固态硬盘，甚至很多公司已经开始直接把数据放到内存中了（注：具体场景具体对待）。
如果这些都不可以再加了呢？那就再加机器吧，一台服务器可以处理1000个并发，那么两台理论上是2000了，所以这就有了我们的横向扩展。
负责均衡器分发请求的类型
所有的请求首先全部到达Load balancer，再由它转发到具体的Web服务器，转发的方式分为以下几种：
1.轮转调度(Round-robin):最简单的方式，这种方式基本上不能算是负载均衡。第一个请求给web1，下一个给web2，再下一个给web3...
不会考虑某 一个服务器是不是负荷太重等等。
2.基于权重的分配(Weight-based): 可以配置每一台服务器处理请求数据的比例，特别适合那种有某台服务器配置不一样的场景。比如说某台服务器配置特别好，那我们可以让它多处理一些请求。
3.随机（Random): 随机分配。
4.粘性session（Sticky Session): Load balancer会跟踪请求，确保同一个session
id的请求都交给同一样服务器。
5.最空闲优先（Least current request）：将最新的请求转发给当前处理请求数量最小的那个服务器。
6.响应时间优先(Response time)：哪台服务器当前响应时间最短就给哪台。
7.用户或URL参数选择(User or URL information)：部分负载均衡器还提供根据一些参数来决定哪台服务器来处理，比如说根据用户信息，地址位置，URL参数，cookie信息等
。
我们还可以根据负载均衡器所使用的技术将它们分为以下几类：
1.反向代理：负载均衡器作为一个代理，同时维持着两个TCP请求，从客户端接收请求，然后将请求转发给相应的Web
服务器,等Web返回Response的时候是返回给了代理服务器，然后再由代理服务器转交给真正的客户端。这样就会导致有一些功能不可用，比如在WEB服务器环境查看请求的来源IP实际上成了我们代理服务器的IP等。
2.透明反向代理：和上面的代理服务器一样，只不过WEB服务器从Request中获取到的信息是真正客户端的信息，就是好像没有使用代理一样的。
3.直接服务器返回：通过更改WEB服务器的MAC 地址来实现分发请求，在这种方式下，WEB服务器不会像上面使用代理服务器一样，请求处理完之后是直接返回给客户端的，所有相对于反向代理来说这种方式的性能会更快一些。
4.NAT 负载均衡：NAT(Network Address Translation网络地址转换)，将网络包（可以理解成TCP包）中的目标IP地址变成实现要处理这个请求的WEB服务器的地址。
5.Microsoft 网络负载均衡：Windows 自带的负载均衡组件，一会我们就用它来做测试。
不使用负载均衡的测试结果
一台独立的服务器
我们可以从一个网站的最初级版本开始说起，最开始的时候我们决定搭建一个网站，但是我们也不知道效果会怎么样，光键是那时候，我们很穷，于是我们租用了一台托管主机，它可能承担了至少三个或以上的角色：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条测试数据
连接字符串就使用本地连接就可以了。
<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人左右同时访问。
WEB服务器与数据库服务器分离
现在我们来做一个花费不是很大，又空间做的扩展，也不需要改任何架构，我们只是再加一台专门的数据库服务器。
下面我们再来看一下测试结果：
大家可以看到，这里我们的吞吐率(每秒处理请求数已经提升到了150左右)，并发处理能力提升了50%，并且300和400并发的时候响应时间也比上面的架构要好一些。
使用负载均衡的测试结果
安装网络负载均衡（NLB)
上面我们一台独立的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，否则无法将他们加入到群集中。
1.在web-01(192.168.1.130)上从管理工具中打开 网络负载均衡器
2.右击“网络负载平衡群集”，选择“新建群集”
3.在“新群集：连接”窗口中将 192.168.1.130添加为主机，点击下一步
4.进入 “新群集：主机参数”，直接下一步
5.进入 “新群集：群集IP地址”， 添加窗口中的“添加” 将192.168.1.254
添加到窗口中然后点击下一步
7.进入 “新群集：群集参数”，选择“多播”然后点击下一步
8.进入 “新群集：端口规则”，选中全部，然后点击编辑
9.将端口范围改成 80~80，协议选 “TCP”，相关性选“无”
10.点击确定回到主窗口，然后点击完成。
11.通过上面的步骤，我们已经建立了一个群集，并且将web-01加入到了群集中，我们还需要手动将web-02也加入到群集中。
12.在群集(192.168.1.254)上右键点击“添加主机到群集”
13. 在“将主机添加到群集：连接”窗口中的 主机中输入192.168.1.131然后后面一下点下一步即可。
现在我们就可以到我们的真实机器上去访问192.168.1.254了，也就是说马上我们就进入测试环节了。
测试结果
本文中所有的测试结果都没有取第一次的结果，EF也需要预热，同样的查询在EF中也是有缓存的，所以第一次的结果会与后面的测试结果有很大的区别，后面的几次（在相同参数下）基本差别就不大了。
可以看到现在我们的吞吐率大概平均在230左右，与一台WEB服务器+一台DB服务器相比，处理能力又提高了50%，为什么不是100%呢？一台WEB服务器能处理150的并发，那两台应该是300才对呀？我能够想到以下原因：
1.我们的数据库服务器只有一台，数据库的处理能力提不上去最终影响WEB服务器的处理能力
2.我们采用的是虚拟机，并非实际的机器，他们实际上是共用CPU，不知道在这种情况下对测试结果会不会有影响（虚拟化专家可以分享一下）。
为了验证一下，我再扩展了一台WEB服务器，我们使用3台WEB服务器+1台DB服务器看看是什么效果。
我们新建一台虚拟机web-03，然后将它也加入到我们的群集中。
测试开始！
在加入第三台WEB服务器之后，我们的吞吐率（每秒处理请求数）再次得到提升从230升至360，并发处理能力再次提升56%，并且大家可以看到，400并发以下的平均每请求处理时间都在1s以内，可喜可贺啊！
最后上两图让大家更直观的看一下这些性能的变化：
以上数据均来自本人机器上的测试，虚拟机全部采用与第一台服务器同样的配置。
小结
在网站架构的不断演变中，负载均衡起着非常重要的位置，不仅仅为我们提升可靠性和可扩展性，有一些比较强大的硬件设备还能提供缓存，以及session机制。今天我们用到的负载均衡是Windows
Server自带的一个组件，它是最简单实现负载均衡的方式，但是功能不是特别完善，而且一旦NLB本身发生错误那么将导致所有的网站都不能访问，我们后面就来通过引入APR(Application
Request Router)来解决这个问题，想要真正了解大型网站的架构实现，而不是仅仅知道负载均衡，分布式缓存，数据库分离这些名词么？那就来跟我一起学习吧！另外我们今天只是用一个简单的页面做了压力测试，只有读数据的操作，还没有写的操作，也没有任何复杂的事务，但是别担心，我们一步一步来
:) 。
|
