Windows平台分布式架构实践 - 负载均衡

本文涉及的产品
应用型负载均衡 ALB,每月750个小时 15LCU
网络型负载均衡 NLB,每月750个小时 15LCU
传统型负载均衡 CLB,每月750个小时 15LCU
简介: 原文:Windows平台分布式架构实践 - 负载均衡概述   最近.NET的世界开始闹腾了,微软官方终于加入到了对.NET跨平台的支持,并且在不久的将来,我们在VS里面写的代码可能就可以通过Mono直接在Linux和Mac上运行。
原文: Windows平台分布式架构实践 - 负载均衡

概述

  最近.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服务器,转发的方式分为以下几种:

  • 轮转调度(Round-robin):最简单的方式,这种方式基本上不能算是负载均衡。第一个请求给web1,下一个给web2,再下一个给web3... 不会考虑某 一个服务器是不是负荷太重等等。
  • 基于权重的分配(Weight-based): 可以配置每一台服务器处理请求数据的比例,特别适合那种有某台服务器配置不一样的场景。比如说某台服务器配置特别好,那我们可以让它多处理一些请求。
  • 随机(Random): 随机分配。
  • 粘性session(Sticky Session): Load balancer会跟踪请求,确保同一个session id的请求都交给同一样服务器。
  • 最空闲优先(Least current request)将最新的请求转发给当前处理请求数量最小的那个服务器。
  • 响应时间优先(Response time):哪台服务器当前响应时间最短就给哪台。
  • 用户或URL参数选择(User or URL information)部分负载均衡器还提供根据一些参数来决定哪台服务器来处理,比如说根据用户信息,地址位置,URL参数,cookie信息等 。

  我们还可以根据负载均衡器所使用的技术将它们分为以下几类:

  • 反向代理:负载均衡器作为一个代理,同时维持着两个TCP请求,从客户端接收请求,然后将请求转发给相应的Web 服务器,等Web返回Response的时候是返回给了代理服务器,然后再由代理服务器转交给真正的客户端。这样就会导致有一些功能不可用,比如在WEB服务器环境查看请求的来源IP实际上成了我们代理服务器的IP等。 
  • 透明反向代理:和上面的代理服务器一样,只不过WEB服务器从Request中获取到的信息是真正客户端的信息,就是好像没有使用代理一样的。
  • 直接服务器返回:通过更改WEB服务器的MAC 地址来实现分发请求,在这种方式下,WEB服务器不会像上面使用代理服务器一样,请求处理完之后是直接返回给客户端的,所有相对于反向代理来说这种方式的性能会更快一些。 
  • NAT 负载均衡:NAT(Network Address Translation网络地址转换),将网络包(可以理解成TCP包)中的目标IP地址变成实现要处理这个请求的WEB服务器的地址。
  • 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,否则无法将他们加入到群集中。

  • 在web-01(192.168.1.130)上从管理工具中打开 网络负载均衡器
  • 右击“网络负载平衡群集”,选择“新建群集”
  • 在“新群集:连接”窗口中将 192.168.1.130添加为主机,点击下一步
  • 进入 “新群集:主机参数”,直接下一步
  • 进入 “新群集:群集IP地址”, 添加窗口中的“添加” 将192.168.1.254 添加到窗口中然后点击下一步

  • 进入 “新群集:群集参数”,选择“多播”然后点击下一步
  • 进入 “新群集:端口规则”,选中全部,然后点击编辑
  • 将端口范围改成 80~80,协议选 “TCP”,相关性选“无”
  • 点击确定回到主窗口,然后点击完成。
  • 通过上面的步骤,我们已经建立了一个群集,并且将web-01加入到了群集中,我们还需要手动将web-02也加入到群集中。


  • 在群集(192.168.1.254)上右键点击“添加主机到群集”
  • 在“将主机添加到群集:连接”窗口中的 主机中输入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)来解决这个问题,想要真正了解大型网站的架构实现,而不是仅仅知道负载均衡,分布式缓存,数据库分离这些名词么?那就来跟我一起学习吧!另外我们今天只是用一个简单的页面做了压力测试,只有读数据的操作,还没有写的操作,也没有任何复杂的事务,但是别担心,我们一步一步来 :) 。

相关实践学习
小试牛刀,一键部署电商商城
SAE 仅需一键,极速部署一个微服务电商商城,体验 Serverless 带给您的全托管体验,一起来部署吧!
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
目录
相关文章
|
2月前
|
消息中间件 运维 Kafka
直播预告|Kafka+Flink双引擎实战:手把手带你搭建分布式实时分析平台!
在数字化转型中,企业亟需从海量数据中快速提取价值并转化为业务增长动力。5月15日19:00-21:00,阿里云三位技术专家将讲解Kafka与Flink的强强联合方案,帮助企业零门槛构建分布式实时分析平台。此组合广泛应用于实时风控、用户行为追踪等场景,具备高吞吐、弹性扩缩容及亚秒级响应优势。直播适合初学者、开发者和数据工程师,参与还有机会领取定制好礼!扫描海报二维码或点击链接预约直播:[https://developer.aliyun.com/live/255088](https://developer.aliyun.com/live/255088)
249 35
直播预告|Kafka+Flink双引擎实战:手把手带你搭建分布式实时分析平台!
|
2月前
|
人工智能 安全 应用服务中间件
阿里巴巴 MCP 分布式落地实践:快速转换 HSF 到 MCP server
本文分享了阿里巴巴内部将大规模HSF服务快速转换为MCP Server的实践经验,通过Higress网关实现MCP协议卸载,无需修改代码即可接入MCP生态。文章分析了MCP生态面临的挑战,如协议快速迭代和SDK不稳定性,并详细介绍了操作步骤及组件功能。强调MCP虽非终极解决方案,但作为AI业务工程化的起点具有重要意义。最后总结指出,MCP只是AI原生应用发展的第一步,未来还有更多可能性值得探索。
868 48
|
2月前
|
消息中间件 运维 Kafka
直播预告|Kafka+Flink 双引擎实战:手把手带你搭建分布式实时分析平台!
直播预告|Kafka+Flink 双引擎实战:手把手带你搭建分布式实时分析平台!
104 11
|
8天前
|
Ubuntu 编译器 C语言
在Ubuntu22.04平台上交叉编译针对Rv1126架构的GCC13.2.0编译器的步骤。
遵循上述步骤,您应该能够在Ubuntu 22.04平台上成功交叉编译适用于RISC-V架构RV1126的GCC 13.2.0编译器,允许您为目标硬件构建应用程序和操作系统组件。
41 10
|
2月前
|
监控 Linux 应用服务中间件
Linux多节点多硬盘部署MinIO:分布式MinIO集群部署指南搭建高可用架构实践
通过以上步骤,已成功基于已有的 MinIO 服务,扩展为一个 MinIO 集群。该集群具有高可用性和容错性,适合生产环境使用。如果有任何问题,请检查日志或参考MinIO 官方文档。作者联系方式vx:2743642415。
589 57
|
2月前
|
安全 JavaScript 前端开发
HarmonyOS NEXT~HarmonyOS 语言仓颉:下一代分布式开发语言的技术解析与应用实践
HarmonyOS语言仓颉是华为专为HarmonyOS生态系统设计的新型编程语言,旨在解决分布式环境下的开发挑战。它以“编码创造”为理念,具备分布式原生、高性能与高效率、安全可靠三大核心特性。仓颉语言通过内置分布式能力简化跨设备开发,提供统一的编程模型和开发体验。文章从语言基础、关键特性、开发实践及未来展望四个方面剖析其技术优势,助力开发者掌握这一新兴工具,构建全场景分布式应用。
313 35
|
3月前
|
弹性计算 负载均衡 网络协议
阿里云SLB深度解析:从流量分发到架构优化的技术实践
本文深入探讨了阿里云负载均衡服务(SLB)的核心技术与应用场景,从流量分配到架构创新全面解析其价值。SLB不仅是简单的流量分发工具,更是支撑高并发、保障系统稳定性的智能中枢。文章涵盖四层与七层负载均衡原理、弹性伸缩引擎、智能DNS解析等核心技术,并结合电商大促、微服务灰度发布等实战场景提供实施指南。同时,针对性能调优与安全防护,分享连接复用优化、DDoS防御及零信任架构集成的实践经验,助力企业构建面向未来的弹性架构。
330 76
|
2月前
|
安全 前端开发 Linux
Immunity CANVAS Professional 7.27 (macOS, Linux, Windows) - 渗透测试和漏洞利用平台
Immunity CANVAS Professional 7.27 (macOS, Linux, Windows) - 渗透测试和漏洞利用平台
100 3
Immunity CANVAS Professional 7.27 (macOS, Linux, Windows) - 渗透测试和漏洞利用平台
|
17天前
|
运维 监控 Java
初创代购选单体,千万级平台用微服务:一张表看懂架构选型红线
在跨境电商代购系统年交易额超3.2万亿元的背景下,本文对比微服务与单体架构的技术原理、适用场景及实战案例,结合性能、运维、成本等维度,为企业提供架构选型指南,助力实现高效扩展与稳定运营。
|
1月前
|
运维 监控 Linux
WGCLOUD运维平台的分布式计划任务功能介绍
WGCLOUD是一款免费开源的运维监控平台,支持主机与服务器性能监控,具备实时告警和自愈功能。本文重点介绍其计划任务功能模块,可统一管理Linux和Windows主机的定时任务。相比手动配置crontab或Windows任务计划,WGCLOUD提供直观界面,通过添加cron表达式、执行指令或脚本并选择主机,即可轻松完成任务设置,大幅提升多主机任务管理效率。

热门文章

最新文章