20 | 高性能负载均衡：分类及架构

Jun 12, 2018

20 | 高性能负载均衡：分类及架构-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

20 | 高性能负载均衡：分类及架构

2018-06-12 李运华来自北京

《从0开始学架构》

课程介绍



讲述：黄洲君

时长09:15大小4.23M



单服务器无论如何优化，无论采用多好的硬件，总会有一个性能天花板，当单服务器的性能无法满足业务需求时，就需要设计高性能集群来提升系统整体的处理性能。
高性能集群的本质很简单，通过增加更多的服务器来提升系统整体的计算能力。由于计算本身存在一个特点：同样的输入数据和逻辑，无论在哪台服务器上执行，都应该得到相同的输出。因此高性能集群设计的复杂度主要体现在任务分配这部分，需要设计合理的任务分配策略，将计算任务分配到多台服务器上执行。
高性能集群的复杂性主要体现在需要增加一个任务分配器，以及为任务选择一个合适的任务分配算法。对于任务分配器，现在更流行的通用叫法是“负载均衡器”。但这个名称有一定的误导性，会让人潜意识里认为任务分配的目的是要保持各个计算单元的负载达到均衡状态。而实际上任务分配并不只是考虑计算单元的负载均衡，不同的任务分配算法目标是不一样的，有的基于负载考虑，有的基于性能（吞吐量、响应时间）考虑，有的基于业务考虑。考虑到“负载均衡”已经成为了事实上的标准术语，这里我也用“负载均衡”来代替“任务分配”，但请你时刻记住，负载均衡不只是为了计算单元的负载达到均衡状态。
今天我先来讲讲负载均衡的分类及架构，下一期会讲负载均衡的算法。
负载均衡分类常见的负载均衡系统包括 3 种：DNS 负载均衡、硬件负载均衡和软件负载均衡。
DNS 负载均衡
DNS 是最简单也是最常见的负载均衡方式，一般用来实现地理级别的均衡。例如，北方的用户访问北京的机房，南方的用户访问深圳的机房。DNS 负载均衡的本质是 DNS 解析同一个域名可以返回不同的 IP 地址。例如，同样是 www.baidu.com，北方用户解析后获取的地址是 61.135.165.224（这是北京机房的 IP），南方用户解析后获取的地址是 14.215.177.38（这是深圳机房的 IP）。
下面是 DNS 负载均衡的简单示意图：
DNS 负载均衡实现简单、成本低，但也存在粒度太粗、负载均衡算法少等缺点。仔细分析一下优缺点，其优点有：
简单、成本低：负载均衡工作交给 DNS 服务器处理，无须自己开发或者维护负载均衡设备。
就近访问，提升访问速度：DNS 解析时可以根据请求来源 IP，解析成距离用户最近的服务器地址，可以加快访问速度，改善性能。
缺点有：
更新不及时：DNS 缓存的时间比较长，修改 DNS 配置后，由于缓存的原因，还是有很多用户会继续访问修改前的 IP，这样的访问会失败，达不到负载均衡的目的，并且也影响用户正常使用业务。
扩展性差：DNS 负载均衡的控制权在域名商那里，无法根据业务特点针对其做更多的定制化功能和扩展特性。
分配策略比较简单：DNS 负载均衡支持的算法少；不能区分服务器的差异（不能根据系统与服务的状态来判断负载）；也无法感知后端服务器的状态。
针对 DNS 负载均衡的一些缺点，对于时延和故障敏感的业务，有一些公司自己实现了 HTTP-DNS 的功能，即使用 HTTP 协议实现一个私有的 DNS 系统。这样的方案和通用的 DNS 优缺点正好相反。
硬件负载均衡
硬件负载均衡是通过单独的硬件设备来实现负载均衡功能，这类设备和路由器、交换机类似，可以理解为一个用于负载均衡的基础网络设备。目前业界典型的硬件负载均衡设备有两款：F5 和 A10。这类设备性能强劲、功能强大，但价格都不便宜，一般只有“土豪”公司才会考虑使用此类设备。普通业务量级的公司一是负担不起，二是业务量没那么大，用这些设备也是浪费。
硬件负载均衡的优点是：
功能强大：全面支持各层级的负载均衡，支持全面的负载均衡算法，支持全局负载均衡。
性能强大：对比一下，软件负载均衡支持到 10 万级并发已经很厉害了，硬件负载均衡可以支持 100 万以上的并发。
稳定性高：商用硬件负载均衡，经过了良好的严格测试，经过大规模使用，稳定性高。
支持安全防护：硬件均衡设备除具备负载均衡功能外，还具备防火墙、防 DDoS 攻击等安全功能。
硬件负载均衡的缺点是：
价格昂贵：最普通的一台 F5 就是一台“马 6”，好一点的就是“Q7”了。
扩展能力差：硬件设备，可以根据业务进行配置，但无法进行扩展和定制。
软件负载均衡
软件负载均衡通过负载均衡软件来实现负载均衡功能，常见的有 Nginx 和 LVS，其中 Nginx 是软件的 7 层负载均衡，LVS 是 Linux 内核的 4 层负载均衡。4 层和 7 层的区别就在于协议和灵活性，Nginx 支持 HTTP、E-mail 协议；而 LVS 是 4 层负载均衡，和协议无关，几乎所有应用都可以做，例如，聊天、数据库等。
软件和硬件的最主要区别就在于性能，硬件负载均衡性能远远高于软件负载均衡性能。Nginx 的性能是万级，一般的 Linux 服务器上装一个 Nginx 大概能到 5 万 / 秒；LVS 的性能是十万级，据说可达到 80 万 / 秒；而 F5 性能是百万级，从 200 万 / 秒到 800 万 / 秒都有（数据来源网络，仅供参考，如需采用请根据实际业务场景进行性能测试）。当然，软件负载均衡的最大优势是便宜，一台普通的 Linux 服务器批发价大概就是 1 万元左右，相比 F5 的价格，那就是自行车和宝马的区别了。
除了使用开源的系统进行负载均衡，如果业务比较特殊，也可能基于开源系统进行定制（例如，Nginx 插件），甚至进行自研。
下面是 Nginx 的负载均衡架构示意图：
软件负载均衡的优点：
简单：无论是部署还是维护都比较简单。
便宜：只要买个 Linux 服务器，装上软件即可。
灵活：4 层和 7 层负载均衡可以根据业务进行选择；也可以根据业务进行比较方便的扩展，例如，可以通过 Nginx 的插件来实现业务的定制化功能。
其实下面的缺点都是和硬件负载均衡相比的，并不是说软件负载均衡没法用。
性能一般：一个 Nginx 大约能支撑 5 万并发。
功能没有硬件负载均衡那么强大。
一般不具备防火墙和防 DDoS 攻击等安全功能。
负载均衡典型架构前面我们介绍了 3 种常见的负载均衡机制：DNS 负载均衡、硬件负载均衡、软件负载均衡，每种方式都有一些优缺点，但并不意味着在实际应用中只能基于它们的优缺点进行非此即彼的选择，反而是基于它们的优缺点进行组合使用。具体来说，组合的基本原则为：DNS 负载均衡用于实现地理级别的负载均衡；硬件负载均衡用于实现集群级别的负载均衡；软件负载均衡用于实现机器级别的负载均衡。
我以一个假想的实例来说明一下这种组合方式，如下图所示。
整个系统的负载均衡分为三层。
地理级别负载均衡：www.xxx.com 部署在北京、广州、上海三个机房，当用户访问时，DNS 会根据用户的地理位置来决定返回哪个机房的 IP，图中返回了广州机房的 IP 地址，这样用户就访问到广州机房了。
集群级别负载均衡：广州机房的负载均衡用的是 F5 设备，F5 收到用户请求后，进行集群级别的负载均衡，将用户请求发给 3 个本地集群中的一个，我们假设 F5 将用户请求发给了“广州集群 2”。
机器级别的负载均衡：广州集群 2 的负载均衡用的是 Nginx，Nginx 收到用户请求后，将用户请求发送给集群里面的某台服务器，服务器处理用户的业务请求并返回业务响应。
需要注意的是，上图只是一个示例，一般在大型业务场景下才会这样用，如果业务量没这么大，则没有必要严格照搬这套架构。例如，一个大学的论坛，完全可以不需要 DNS 负载均衡，也不需要 F5 设备，只需要用 Nginx 作为一个简单的负载均衡就足够了。
小结今天我为你讲了负载均衡的常见分类以及典型架构，希望对你有所帮助。
这就是今天的全部内容，留一道思考题给你吧，假设你来设计一个日活跃用户 1000 万的论坛的负载均衡集群，你的方案是什么？设计理由是什么？
欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。（编辑乱入：精彩的留言有机会获得丰厚福利哦！）

分享给需要的人，Ta购买本课程，你将得20元

生成海报并分享

赞 43

提建议

19 | 单服务器高性能模式：Reactor与Proactor

21 | 高性能负载均衡：算法

 写留言

精选留言(68)

鹅米豆发
2018-06-12
日活千万的论坛，这个流量不低了。 1、首先，流量评估。 1000万DAU，换算成秒级，平均约等于116。考虑每个用户操作次数，假定10，换算成平均QPS=1160。考虑峰值是均值倍数，假定10，换算成峰值QPS=11600。考虑静态资源、图片资源、服务拆分等，流量放大效应，假定10，QPS*10=116000。 2、其次，容量规划。考虑高可用、异地多活，QPS*2=232000。考虑未来半年增长，QPS*1.5=348000。 3、最后，方案设计。三级导流。第一级，DNS，确定机房，以目前量级，可以不考虑。第二级，确定集群，扩展优先，则选Haproxy/LVS，稳定优先则选F5。第三级，Nginx+KeepAlived，确定实例。
展开
作者回复: 思路不错👍👍
共 24 条评论
366
无聊夫斯基
2018-08-27
我还是不是很理解TPS和QPS具体的区别
作者回复: T=transaction，代表写请求 Q=query，代表读请求
共 4 条评论
80
孙振超
2018-07-21
这篇文章最大的收获是分析问题的思路，从dau出发，结合业务的特点，计算出来总的qps和tps，而后再根据通常规律计算出qps和tps的峰值，加上一定的未来发展空间和高可用冗余，结合单机能够支撑的qps和tps量，就可以计算出来整个集群的规模，有了这些数据就可以制定出比较合理的负载均衡的策略，而不是无的放矢，凭空猜测。
展开
作者回复: 最常用的方式
共 2 条评论
51
ant
2018-06-12
日活跃用户1000万应该就是国家级应用了，面向全国活跃或者全球用户，比如最大的Xxx网站github。这个时候钱应该都不是问题了。我觉得可以考虑异地多机房部署。这样导流之后每个机房的日活就少很多。其实我在想如果在每个机房不加入负载硬件用多个ngnix集群来实现，每个ngnix上会有我们自定义的路由算法。ngnix也架设多层，逐层导流，比如我们一个机房设计承受200万，那么我们可以架设3层ngnix，第一层基于自己的路由算法导流到第2层ngnix。第2层又导流到第3层。为了避免ngnix单点，每一层ngnix部署多。这样导流下流每台服务器所承认的访问不会很多。不知道这样的设计能不能达到要求，老师点评下
展开
作者回复: 可以达到，但有点复杂，nginx做级联不太合适，因为顶层的nginx性能是瓶颈，多级导流一般用在处理能力有差异的系统上，例如一级用F5，二级用LVS，三级用nginx
共 3 条评论
30
何国平
2018-06-14
nginx也支持4层反向代理了
作者回复: 我宁愿用LVS，久经考验，性能强大😄
17
plflying
2018-06-12
1、首先分析论坛系统的需求：高可用、扩展性、常规安全性、高性能。以上需求优先级依次降低。 2、并发计算： 1）、首先计算每秒并发量：1000万/(10*60*60)=278qps. (此处每天按照10个小时计算) 2）、计算每秒最大并发量：278*5=1390. （此处的5为经验值，按照论坛的用户使用特点多集中晚上小部分时段，该值已尽量取大。同时网上也有按照时间和并发数的二八原则计算，本人按照第一种计算） 3、容量规划： 1、前端2台nginx负载均衡，利用keepalive保证高可用。同时可用做静态资源缓存服务器。 2、后端tomcat部署应用，按照单台tomcat支撑1200并发，需要2台。考虑冗余，此处配置3台。 3、考虑高性能应用可以集成缓存，也可以使用统一缓存。 4、数据库采用mysql，使用2台进行主从复制和读写分离。一方面满足读多写少的应用场景，另一方面在1台出现故障时，能保证高可用。以上内容请老师指正！
展开
作者回复: 1000万是用户数量，不是访问次数，访问次数会多很多，其它分析都可以
共 3 条评论
17
食指可爱多
2018-06-12
请问老师后面会有容量规划方面文章吗？日活用户1000w转换成日请求量（这一步我没啥经验），再计算平均qps，考虑请求的波峰波谷，波峰取qps均值的5倍。1000x10000x10*24*60*60x5~5700得到qps峰值5700。不考虑后端应用层和更下层数据库缓存这些，接入层一个nginx就可以搞定了？
作者回复: 同样1000万日活用户，不同业务特点的QPS差异很大，例如抖音的访问量会明显高于支付业务，论坛业务明显高于工具类业务
共 2 条评论
14
老北
2018-07-08
千万日活，论坛的时间相对比较集中，同时在线预计会达到一百万。这时候会有一半的人在操作(查看帖子之类)，每个用户操作可能会调用2-3个接口。那并发数大约就是50w*2.5=125w? 这时候nginx的5w并发就不行了。需要多个dns到不同主机，再进行nginx,lvs之类转发。另外像tomcat一般支持2000左右连接数。这样就需要600多台tomcat？总感觉哪里算的不对😂
展开
作者回复: 确实有点吓人，千万日活转换为百万同时在线这里有问题，一般把日活转换为pv，例如平均每个用户会访问100个页面，日访问量就是10亿，每秒就是大约1.2万的并发访问量，再按照峰值等于均值3倍来算，也就3.6万，远远没有125万那么夸张
共 2 条评论
12
低调的大老刘
2018-06-29
华哥，看到很多DNS+Nginx做负载，但是这种方式没办法预防DDOS攻击，你的Ip都暴露了
作者回复: 谁都没法防DDOS攻击呀，不暴露ip，正常用户也访问不了啊😄
6
一叶
2018-09-23
dear 华哥：文中说的一般的linux服务器 nginx 5w/s ，lvs 80w/s，这个一般的linux服务器能再具体一点吗，比如你们通常用的多少核多少g内存呢？3Q
作者回复: 与时俱进，现在基本都是32核48g内存了
共 2 条评论
7
交叉路口
2018-06-18
论坛这种业务的接口响应应该比较短，预计平均100ms ，超时限制500ms 。日活千万，预计峰值QPS 4000/s，按照超时500ms ，并发估算2000。采取dns+nginx 足够，具体实例根据 staging 压测来评估。dns 一是为了地理位置负载均衡，还有为了扩展性（客户端通过域名访问，后端需要拓展机器对客户端透明）。Nginx ：应用负载均衡，打到某个服务实例，利用其故障转移（可检测实例状态进行剔除）、并发限制等特性来保证服务稳定性，同时还可以利用它做其他事情（access log 做日志行为分析）。希望华哥指出不足😃
展开
作者回复: 基本OK
6
互联网老辛
2018-06-13
并发测试如何来做，怎么知道自己设计的数据库，或者架构能支撑多少并发
作者回复: 基于业务场景进行性能压测，了解大概量级即可，不需要很精确
3
星火燎原
2018-06-12
不差钱的话可以考虑文中DNS +F5+ ngnix ，一般这种日活还是考虑DNS+LVS+Nginx
作者回复: 论坛不怎么赚钱啊😂
3
lawrence.peng
2020-09-29
老师，看了前面的文章的话，经常能看到你说，linux服务器 nginx 5w/s ，lvs 80w/s 等等，并且知道这些机器是当前主流的配置 32C 48G,要求我们要把这个性能指标背熟，目地是很明显的，为了做容量规划。但现在很多创业公司，基本上都是上云的，云主机的配置基本都是4C 8G,问题来了，怎么去做这个应用的容量规划呢？或者这些指标哪里能查阅吗？
作者回复: 云主机的性能可以按照同配置的物理机80%的性能来估算
3
飞翔
2019-07-08
微服务的服务发现是不是也算一类负载均衡？
作者回复: 服务发现用了负载均衡
2
lyshrine
2018-10-18
老师画的这些有服务器的图，是哪那个软件画的？还是libreoffice？
作者回复: 是的，LibreOffice Draw
3
feifei
2018-06-13
日活跃用户千万，按14小时折算，每秒并发198，但这是平均，还有高峰时段，并发按平均并发5倍来估算，即每秒1千，然后来对比方案： Dns负载，目前单机房能够满足，没跨机房的必要，dns目前不适用。硬件负载，每秒几百万级的并非，很显然系统没有这么高的并发，硬件负载不适合。软件负载，nginx单台能支持到5万的并发，当前系统,折算最高的并发也不过千级别。经过方案的对比，软件负载使用nginx可以完全满足业务的要求，所以使用软件负载即可
展开
作者回复: 日活用户数！= 用户访问数，论坛类业务，一个用户一天可能访问几十个页面
2
公号-技术夜未眠
2018-06-12
通过容量规划，并考虑到高性能、高可用的要求，Web最前端可采用HAProxy+Keepalived双机(实现故障转移，保证高可用)作为负载均衡器；后端的数据库架构采用MySQL一主多从，读写分离的方式，可采用LVS+Keepalived的方式实现读数据库的负载均衡与故障转移。
2
张玮(大圣)
2018-06-12
看了大家的各种计算，估容量，估机器，想说的是：根据之前专栏讲到的单台高性能模式等知识，先把单台机器做到最优化，同时做好负载均衡层，然后进行压测，一步一步添加机器，均衡层 Nginx 够了，另外，要考虑成本啊，F5尽量不用，稳定性用双主克服下
作者回复: 最好算一下，当然有经验的架构师确实能够凭感觉预估
3
三月沙@wecatch
2018-06-12
不考虑多机房，不考虑不同地区，一个配置好点的nginx 就够了，防止单点，可以再加一台
作者回复: 1000万日活的业务，你真的要这么节省么？😂😂
共 2 条评论
2

