从0开始学架构
李运华
资深技术专家
立即订阅
38899 人已学习
课程目录
已完结 59 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 照着做,你也能成为架构师!
免费
基础架构 (13讲)
01 | 架构到底是指什么?
02 | 架构设计的历史背景
03 | 架构设计的目的
04 | 复杂度来源:高性能
05 | 复杂度来源:高可用
06 | 复杂度来源:可扩展性
07 | 复杂度来源:低成本、安全、规模
08 | 架构设计三原则
09 | 架构设计原则案例
10 | 架构设计流程:识别复杂度
11 | 架构设计流程:设计备选方案
12 | 架构设计流程:评估和选择备选方案
13 | 架构设计流程:详细方案设计
高性能架构模式 (8讲)
14 | 高性能数据库集群:读写分离
15 | 高性能数据库集群:分库分表
16 | 高性能NoSQL
17 | 高性能缓存架构
18 | 单服务器高性能模式:PPC与TPC
19 | 单服务器高性能模式:Reactor与Proactor
20 | 高性能负载均衡:分类及架构
21 | 高性能负载均衡:算法
高可用架构模式 (10讲)
22 | 想成为架构师,你必须知道CAP理论
23 | 想成为架构师,你必须掌握的CAP细节
24 | FMEA方法,排除架构可用性隐患的利器
25 | 高可用存储架构:双机架构
26 | 高可用存储架构:集群和分区
27 | 如何设计计算高可用架构?
28 | 业务高可用的保障:异地多活架构
29 | 异地多活设计4大技巧
30 | 异地多活设计4步走
31 | 如何应对接口级的故障?
可扩展架构模式 (6讲)
32 | 可扩展架构的基本思想和模式
33 | 传统的可扩展架构模式:分层架构和SOA
34 | 深入理解微服务架构:银弹 or 焦油坑?
35 | 微服务架构最佳实践 - 方法篇
36 | 微服务架构最佳实践 - 基础设施篇
37 | 微内核架构详解
架构实战 (13讲)
38 | 架构师应该如何判断技术演进的方向?
39 | 互联网技术演进的模式
40 | 互联网架构模板:“存储层”技术
41 | 互联网架构模板:“开发层”和“服务层”技术
42 | 互联网架构模板:“网络层”技术
43 | 互联网架构模板:“用户层”和“业务层”技术
44 | 互联网架构模板:“平台”技术
45 | 架构重构内功心法第一式:有的放矢
46 | 架构重构内功心法第二式:合纵连横
47 | 架构重构内功心法第三式:运筹帷幄
48 | 再谈开源项目:如何选择、使用以及二次开发?
49 | 谈谈App架构的演进
50 | 架构实战:架构设计文档模板
特别放送 (7讲)
架构专栏特别放送 | “华仔,放学别走!”第1期
架构专栏特别放送 | “华仔,放学别走!” 第2期
如何高效地学习开源项目 | “华仔,放学别走!” 第3期
架构师成长之路 | “华仔,放学别走!” 第4期
架构师必读书单 | “华仔,放学别走!” 第5期
新书首发 | 《从零开始学架构》
致「从0开始学架构」专栏订阅用户
结束语 (1讲)
结束语 | 坚持,成就你的技术梦想
从0开始学架构
登录|注册

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

李运华 2018-06-12
单服务器无论如何优化,无论采用多好的硬件,总会有一个性能天花板,当单服务器的性能无法满足业务需求时,就需要设计高性能集群来提升系统整体的处理性能。
高性能集群的本质很简单,通过增加更多的服务器来提升系统整体的计算能力。由于计算本身存在一个特点:同样的输入数据和逻辑,无论在哪台服务器上执行,都应该得到相同的输出。因此高性能集群设计的复杂度主要体现在任务分配这部分,需要设计合理的任务分配策略,将计算任务分配到多台服务器上执行。
高性能集群的复杂性主要体现在需要增加一个任务分配器,以及为任务选择一个合适的任务分配算法。对于任务分配器,现在更流行的通用叫法是“负载均衡器”。但这个名称有一定的误导性,会让人潜意识里认为任务分配的目的是要保持各个计算单元的负载达到均衡状态。而实际上任务分配并不只是考虑计算单元的负载均衡,不同的任务分配算法目标是不一样的,有的基于负载考虑,有的基于性能(吞吐量、响应时间)考虑,有的基于业务考虑。考虑到“负载均衡”已经成为了事实上的标准术语,这里我也用“负载均衡”来代替“任务分配”,但请你时刻记住,负载均衡不只是为了计算单元的负载达到均衡状态
今天我先来讲讲负载均衡的分类及架构,下一期会讲负载均衡的算法。

负载均衡分类

常见的负载均衡系统包括 3 种:DNS 负载均衡、硬件负载均衡和软件负载均衡。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学架构》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(48)

  • 鹅米豆发
    日活千万的论坛,这个流量不低了。

    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,确定实例。

    作者回复: 思路不错👍👍

    2018-06-12
    2
    149
  • 无聊夫斯基
    我还是不是很理解TPS和QPS具体的区别

    作者回复: T=transaction,代表写请求
    Q=query,代表读请求

    2018-08-27
    30
  • 孙振超
    这篇文章最大的收获是分析问题的思路,从dau出发,结合业务的特点,计算出来总的qps和tps,而后再根据通常规律计算出qps和tps的峰值,加上一定的未来发展空间和高可用冗余,结合单机能够支撑的qps和tps量,就可以计算出来整个集群的规模,有了这些数据就可以制定出比较合理的负载均衡的策略,而不是无的放矢,凭空猜测。



    作者回复: 最常用的方式

    2018-07-21
    17
  • plflying
    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万是用户数量,不是访问次数,访问次数会多很多,其它分析都可以

    2018-06-12
    8
  • 食指可爱多
    请问老师后面会有容量规划方面文章吗?日活用户1000w转换成日请求量(这一步我没啥经验),再计算平均qps,考虑请求的波峰波谷,波峰取qps均值的5倍。1000x10000x10*24*60*60x5~5700得到qps峰值5700。不考虑后端应用层和更下层数据库缓存这些,接入层一个nginx就可以搞定了?

    作者回复: 同样1000万日活用户,不同业务特点的QPS差异很大,例如抖音的访问量会明显高于支付业务,论坛业务明显高于工具类业务

    2018-06-12
    1
    8
  • ant
    日活跃用户1000万应该就是国家级应用了,面向全国活跃或者全球用户,比如最大的Xxx网站github。这个时候钱应该都不是问题了。我觉得可以考虑异地多机房部署。这样导流之后每个机房的日活就少很多。其实我在想如果在每个机房不加入负载硬件用多个ngnix集群来实现,每个ngnix上会有我们自定义的路由算法。ngnix也架设多层,逐层导流,比如我们一个机房设计承受200万,那么我们可以架设3层ngnix,第一层基于自己的路由算法导流到第2层ngnix。第2层又导流到第3层。为了避免ngnix单点,每一层ngnix部署多。这样导流下流每台服务器所承认的访问不会很多。不知道这样的设计能不能达到要求,老师点评下

    作者回复: 可以达到,但有点复杂,nginx做级联不太合适,因为顶层的nginx性能是瓶颈,多级导流一般用在处理能力有差异的系统上,例如一级用F5,二级用LVS,三级用nginx

    2018-06-12
    7
  • 何国平
    nginx也支持4层反向代理了

    作者回复: 我宁愿用LVS,久经考验,性能强大😄

    2018-06-14
    5
  • 低调的大老刘
    华哥,看到很多DNS+Nginx做负载,但是这种方式没办法预防DDOS攻击,你的Ip都暴露了

    作者回复: 谁都没法防DDOS攻击呀,不暴露ip,正常用户也访问不了啊😄

    2018-06-29
    3
  • xinsz08
    并发测试如何来做,怎么知道自己设计的数据库,或者架构能支撑多少并发

    作者回复: 基于业务场景进行性能压测,了解大概量级即可,不需要很精确

    2018-06-13
    3
  • 星火燎原
    不差钱的话可以考虑文中DNS +F5+ ngnix ,一般这种日活还是考虑DNS+LVS+Nginx

    作者回复: 论坛不怎么赚钱啊😂

    2018-06-12
    3
  • 一叶
    dear 华哥:文中说的一般的linux服务器 nginx 5w/s ,lvs 80w/s,这个一般的linux服务器能再具体一点吗,比如你们通常用的多少核多少g内存呢?3Q

    作者回复: 与时俱进,现在基本都是32核48g内存了

    2018-09-23
    2
  • 交叉路口
    论坛这种业务的接口响应应该比较短,预计平均100ms ,超时限制500ms 。日活千万,预计峰值QPS 4000/s,按照超时500ms ,并发估算2000。采取dns+nginx 足够,具体实例根据 staging 压测来评估。dns 一是为了地理位置负载均衡,还有为了扩展性(客户端通过域名访问,后端需要拓展机器对客户端透明)。Nginx :应用负载均衡,打到某个服务实例,利用其故障转移(可检测实例状态进行剔除)、并发限制等特性来保证服务稳定性,同时还可以利用它做其他事情(access log 做日志行为分析)。希望华哥指出不足😃

    作者回复: 基本OK

    2018-06-18
    2
  • 公号-代码荣耀
    通过容量规划,并考虑到高性能、高可用的要求,Web最前端可采用HAProxy+Keepalived双机(实现故障转移,保证高可用)作为负载均衡器;
    后端的数据库架构采用MySQL一主多从,读写分离的方式,可采用LVS+Keepalived的方式实现读数据库的负载均衡与故障转移。
    2018-06-12
    2
  • 肖一林
    峰值大概就是5000/s~20000/s,要看论坛活跃度。所以一个ng就够了。dns负载均衡也不一定就要支持异地多活吧,同一个机房多台主机也是可以的,所以最多dns+ng就可以很完美。需要异地多活的项目应该非常少。

    作者回复: 这种方式也可以,dns做同机房多入口负载均衡

    2018-06-12
    2
  • 三水
    老师,流行的SLB还有HAProxy,我们用LVS做DNS的LB,Nginx和HAProxy做HTTP的LB。

    作者回复: HAProxy也很成熟,可以用

    2018-06-12
    2
  • 黄金的太阳
    假设论坛的用户平均分布在全国各地(东,西,南,北四个区域),1000万的日活跃用户平均分散到每个区域后可近似估计并发量在2.5万~5万用户,可以采用两级嵌套的负载均衡架构
    1.利用DNS达到四个地域的负载均衡
    2.利用Nginx的方式达到本区域内的负载均衡
    此方案未考虑西部地区用户少,东部地区用户多的情况,在并发量尚可接受的范围内,可以考虑将单台Nginx集群化以增强并发负载支持能力

    不知道理解的对不对

    作者回复: 基本正确,中国一般分南北区域接入,西部用户确实少很多

    2018-06-12
    2
  • 飞翔
    微服务的服务发现是不是也算一类负载均衡?

    作者回复: 服务发现用了负载均衡

    2019-07-08
    1
  • lyshrine
    老师画的这些有服务器的图,是哪那个软件画的?还是libreoffice?

    作者回复: 是的,LibreOffice Draw

    2018-10-18
    1
  • 小橙橙
    老师,有个问题一直不是很清楚,如果用nginx轮询做负载均衡,下游某个服务挂掉了,那就会导致某些请求无法响应,这样的问题要如何解决呢?

    作者回复: 查询nginx官方文档,里面有介绍health check

    2018-07-27
    1
  • Ezekiel
    还是要具体看业务,这个论坛是关于什么内容的论坛,是否有区域量级不同的情况,如果存在则考虑下DNS均衡,论坛应该都不怎么赚钱的,硬件均衡可以不考虑,请求量较大,LVS做集群均衡,Nginx做机器均衡感觉就可以了。论坛个人觉得做好读写分离和缓存设计才是重点。
    2018-07-19
    1
收起评论
48
返回
顶部