负载均衡器/LB - 学习/实践

1.应用场景

主要用于学习Loader Balance的分类，应用场景，以及应用在大型项目中。

2.学习/操作

1.文档阅读 20 | 高性能负载均衡：分类及架构-极客时间 第26讲 | 如何用网关服务器进行负载均衡？-极客时间 极客时间-负载均衡器搜索 15 | 可编程的互联网世界-极客时间 https://blog.csdn.net/william_n/article/details/127387009 What is a Reverse Proxy vs. Load Balancer? - NGINX Beginner’s Guide dns - Load balancer and API Gateway confusion - Stack Overflow https://medium.com/@LadyNoBug/api-gateway-vs-load-balancer-5bbb2c6f0850 2.整理输出 文章一 20 | 高性能负载均衡：分类及架构 单服务器无论如何优化，无论采用多好的硬件，总会有一个性能天花板，当单服务器的性能无法满足业务需求时，就需要设计高性能集群来提升系统整体的处理性能。 高性能集群的本质很简单，通过增加更多的服务器来提升系统整体的计算能力。由于计算本身存在一个特点：同样的输入数据和逻辑，无论在哪台服务器上执行，都应该得到相同的输出。因此高性能集群设计的复杂度主要体现在任务分配这部分，需要设计合理的任务分配策略，将计算任务分配到多台服务器上执行。 高性能集群的复杂性主要体现在需要增加一个任务分配器，以及为任务选择一个合适的任务分配算法。对于任务分配器，现在更流行的通用叫法是“负载均衡器”。但这个名称有一定的误导性，会让人潜意识里认为任务分配的目的是要保持各个计算单元的负载达到均衡状态。而实际上任务分配并不只是考虑计算单元的负载均衡，不同的任务分配算法目标是不一样的，有的基于负载考虑，有的基于性能（吞吐量、响应时间）考虑，有的基于业务考虑。考虑到“负载均衡”已经成为了事实上的标准术语，这里我也用“负载均衡”来代替“任务分配”，但请你时刻记住，负载均衡不只是为了计算单元的负载达到均衡状态。 今天我先来讲讲负载均衡的分类及架构，下一期会讲负载均衡的算法。 负载均衡分类 常见的负载均衡系统包括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万的论坛的负载均衡集群，你的方案是什么？设计理由是什么？ 欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。（编辑乱入：精彩的留言有机会获得丰厚福利哦！） 笔记 * 根据负载均衡达到的目的可分四类     * 任务平分类：负载均衡系统收到任务平均分配给服务器进行处理，可以是绝对的平均，也可以是按比例的“加权”平均     * 负载均衡类：突出负载的均衡，根据当前系统压力         * CPU负载         * IO负载         * 网卡吞吐量     * 性能最优类：根据服务器响应时间来任务分配     * Hash类：根据某些关键信息进行Hash运算，同一个放在同一服务器上处理         * 源地址hash         * 目标地址hash         * session ID hash         * 用户ID hash * 轮询     * 优点简单     * 缺点不关心服务器状态         * 如果有一个服务器死循环CPU过高，还是会发送任务 * 加权轮询     * 根据不通服务器的配置差异，不同的权重设置 * 负载最低优先     * 不同任务类型、不同业务场景、选择不同指标         * LVS是4层负载，以连接数来判断服务器状态         * Nginx是7层负载，以HTTP请求数来判断服务器状态     * 自己开发，还需要注意，考虑选择的指标         * IO密集型         * CPU密集型     * 复杂性问题：         * 连接数优先算法             * 要求：每个请求都会发送给服务器进行处理             * 不适合：固定连接池方式         * CPU负载             * 收集信息的方式                 * 收集时间长度                     * 1分钟长度与15分钟长度效果不同，并不一定15分钟就好                 * 收集动作消耗性能         * 代码复杂度             * 轮询可能10行代码             * 负载可能1000行                 * 并且需要多方面调试 * 性能最优类     * 站在客户端进行分配任务     * 谁的性能此时最好，分配给谁     * 高复杂度         * 收集分析过程中，本身收集就会消耗性能         * 为了减少性能消耗             * 设置合适的采样率                 * 越大性能消耗越大             * 合适的周期                 * 多久采样一次 * Hash类     * 源地址Hash         * 适合存在事务、会话业务         * 网上银行：生成临时会话信息     * ID Hash         * 根据某个ID的业务分配服务器处理         * session ID也可以解决网上银行的例子 后续做成图表/思维导图 文章二 第26讲 | 如何用网关服务器进行负载均衡？ TBD 临时 使用chrome输入 ningxiaofa.top 多次返回的内容不同，有时返回之前的博客内容，有时返回目前的博客内容， 经过排查如下，手下，看了chrome中缓存的DNS的记录 可以看到，有两条记录，而且查询IP可知，分别是华为云和阿里云   怀疑是自己的华为云HECS还没到期，登陆华为云发现确实如此「以为到期了，有点尬」 然后查看了下，域名解析记录，可以看到，自己配置同一个域名多个IP地址。 但是两台服务器上的内容并不是完全相同的，所以，出现上面的情况。   这也是通过DNS实现负载均衡的手段   后续补充 ...

3.问题/补充

1. 课后思考题：假设你来设计一个日活跃用户 1000 万的论坛的负载均衡集群，你的方案是什么？设计理由是什么？ 网友-鹅米豆发        日活千万的论坛，这个流量不低了。 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，确定实例。 作者回复: 思路不错👍👍 2. 网友-无聊夫斯基 我还是不是很理解TPS和QPS具体的区别 作者回复: T=transaction，代表写请求 Q=query，代表读请求 其他网友补充： Geek_steven_wang 论坛这类http短链接应用，两者相等。tps主要计算服务器连接能力，qps主要是服务器业务处理能力。 helloworld 同一个TPS, 可以产生多个QPS 3. 网友-孙振超 这篇文章最大的收获是分析问题的思路，从dau出发，结合业务的特点，计算出来总的qps和tps，而后再根据通常规律计算出qps和tps的峰值，加上一定的未来发展空间和高可用冗余，结合单机能够支撑的qps和tps量，就可以计算出来整个集群的规模，有了这些数据就可以制定出比较合理的负载均衡的策略，而不是无的放矢，凭空猜测。 作者回复: 最常用的方式 4. ant 日活跃用户1000万应该就是国家级应用了，面向全国活跃或者全球用户，比如最大的Xxx网站github。 这个时候钱应该都不是问题了。 我觉得可以考虑异地多机房部署。 这样导流之后每个机房的日活就少很多。 其实我在想如果在每个机房不加入负载硬件用多个ngnix集群来实现，每个ngnix上会有我们自定义的路由算法。ngnix也架设多层，逐层导流。 比如我们一个机房设计承受200万，那么我们可以架设3层ngnix，第一层基于自己的路由算法导流到第2层ngnix。第2层又导流到第3层。为了避免ngnix单点，每一层ngnix部署多。这样导流下流每台服务器所承认的访问不会很多。不知道这样的设计能不能达到要求，老师点评下 作者回复: 可以达到，但有点复杂，nginx做级联不太合适，因为顶层的nginx性能是瓶颈，多级导流一般用在处理能力有差异的系统上，例如一级用F5，二级用LVS，三级用nginx 其他网友补充： KW💤 这不脱裤子放屁码...本来就是nginx处理不了那么大的量，上层才需要硬件扛，你上层的nginx还是顶着这么大的量啊 5. 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万是用户数量，不是访问次数，访问次数会多很多，其它分析都可以 其他网友补充： 11月的萧邦 可以预估每个用户触发几次点击操作 如果是5次 那么1000万×5 另外 这些业务高峰期可能只有晚上那两个小时左右 所以把10小时替换为2小时。 刘国正 我理解，plflying算出来的278是说平均实时在线用户数，这些在用户中，同时去点击论坛里功能（也就是产生读写操作）的用户，可能占20%，那就是278x0.2=50，考虑访问高峰期，差不多50x2=100qps ，对于这个并发量，一台nginx足以抗住。 6. 食指可爱多 请问老师后面会有容量规划方面文章吗？日活用户1000w转换成日请求量（这一步我没啥经验），再计算平均qps，考虑请求的波峰波谷，波峰取qps均值的5倍。1000x10000x10*24*60*60x5~5700得到qps峰值5700。不考虑后端应用层和更下层数据库缓存这些，接入层一个nginx就可以搞定了？ 作者回复: 同样1000万日活用户，不同业务特点的QPS差异很大，例如抖音的访问量会明显高于支付业务，论坛业务明显高于工具类业务 问题： 5700是怎么计算出来的？ 7. 何国平 nginx也支持4层反向代理了 作者回复: 我宁愿用LVS，久经考验，性能强大😄 8. 老北 千万日活，论坛的时间相对比较集中，同时在线预计会达到一百万。 这时候会有一半的人在操作(查看帖子之类)，每个用户操作可能会调用2-3个接口。那并发数大约就是50w*2.5=125w? 这时候nginx的5w并发就不行了。需要多个dns到不同主机，再进行nginx,lvs之类转发。 另外像tomcat一般支持2000左右连接数。这样就需要600多台tomcat？ 总感觉哪里算的不对😂 作者回复: 确实有点吓人，千万日活转换为百万同时在线这里有问题，一般把日活转换为pv，例如平均每个用户会访问100个页面，日访问量就是10亿，每秒就是大约1.2万的并发访问量，再按照峰值等于均值3倍来算，也就3.6万，远远没有125万那么夸张 9. 低调的大老刘 华哥，看到很多DNS+Nginx做负载，但是这种方式没办法预防DDOS攻击，你的Ip都暴露了 作者回复: 谁都没法防DDOS攻击呀，不暴露ip，正常用户也访问不了啊😄 10. dear 华哥：文中说的一般的linux服务器 nginx 5w/s ，lvs 80w/s，这个一般的linux服务器能再具体一点吗，比如你们通常用的多少核多少g内存呢？3Q 作者回复: 与时俱进，现在基本都是32核48g内存了 11. 交叉路口 论坛这种业务的接口响应应该比较短，预计平均100ms ，超时限制500ms 。 日活千万，预计峰值QPS 4000/s，按照超时500ms ，并发估算2000。 采取dns+nginx 足够，具体实例根据 staging 压测来评估。 dns 一是为了地理位置负载均衡，还有为了扩展性（客户端通过域名访问，后端需要拓展机器对客户端透明）。 Nginx ：应用负载均衡，打到某个服务实例，利用其故障转移（可检测实例状态进行剔除）、并发限制等特性来保证服务稳定性，同时还可以利用它做其他事情（access log 做日志行为分析）。 希望华哥指出不足😃 作者回复: 基本OK 12. 互联网老辛 并发测试如何来做，怎么知道自己设计的数据库，或者架构能支撑多少并发 作者回复: 基于业务场景进行性能压测，了解大概量级即可，不需要很精确 13. 星火燎原 不差钱的话可以考虑文中DNS +F5+ ngnix ，一般这种日活还是考虑DNS+LVS+Nginx 作者回复: 论坛不怎么赚钱啊😂 14. 飞翔 微服务的服务发现是不是也算一类负载均衡？ 作者回复: 服务发现用了负载均衡 15. feifei 日活跃用户千万，按14小时折算，每秒并发198，但这是平均，还有高峰时段，并发按平均并发5倍来估算，即每秒1千. 然后来对比方案： Dns负载，目前单机房能够满足，没跨机房的必要，dns目前不适用。 硬件负载，每秒几百万级的并非，很显然系统没有这么高的并发，硬件负载不适合。 软件负载，nginx单台能支持到5万的并发，当前系统, 折算最高的并发也不过千级别。 经过方案的对比，软件负载使用nginx可以完全满足业务的要求，所以使用软件负载即可 作者回复: 日活用户数 != 用户访问数，论坛类业务，一个用户一天可能访问几十个页面 16. 张玮(大圣) 看了大家的各种计算，估容量，估机器， 想说的是：根据之前专栏讲到的单台高性能模式等知识，先把单台机器做到最优化，同时做好负载均衡层，然后进行压测，一步一步添加机器，均衡层 Nginx 够了，另外，要考虑成本啊，F5尽量不用，稳定性用双主克服下. 作者回复: 最好算一下，当然有经验的架构师确实能够凭感觉预估 17. 三月沙@wecatch 不考虑多机房，不考虑不同地区，一个配置好点的nginx 就够了，防止单点，可以再加一台 作者回复: 1000万日活的业务，你真的要这么节省么？😂😂 18. 肖一林 峰值大概就是5000/s～20000/s，要看论坛活跃度。所以一个ng就够了。dns负载均衡也不一定就要支持异地多活吧，同一个机房多台主机也是可以的，所以最多dns+ng就可以很完美。需要异地多活的项目应该非常少。 作者回复: 这种方式也可以，dns做同机房多入口负载均衡 19. 三水 老师，流行的SLB还有HAProxy，我们用LVS做DNS的LB，Nginx和HAProxy做HTTP的LB。 作者回复: HAProxy也很成熟，可以用 20. 黄金的太阳 假设论坛的用户平均分布在全国各地(东，西，南，北四个区域)，1000万的日活跃用户平均分散到每个区域后可近似估计并发量在2.5万～5万用户，可以采用两级嵌套的负载均衡架构 1.利用DNS达到四个地域的负载均衡 2.利用Nginx的方式达到本区域内的负载均衡 此方案未考虑西部地区用户少，东部地区用户多的情况，在并发量尚可接受的范围内，可以考虑将单台Nginx集群化以增强并发负载支持能力 不知道理解的对不对 作者回复: 基本正确，中国一般分南北区域接入，西部用户确实少很多 21. good boby 向后延伸：负载均衡还包括以下处理 1、集群调度平台（PaaS）平台 例如k8s 、docker， 可以实现动态扩容和缩减，根据事实的并发量进行处理，当然前提是包括Nginx、lvs、haproxy前端负载均衡器不能挂掉。 2、分布式框架。 例如：Spring Cloud 的ribbion、feign也可以从应用层面实现负载均衡。 作者回复: 非常棒的补充，当时写书的时候，这些还不怎么很成熟，所以没有包含，技术与时俱进，我们的认知也要不断更新 ：） 22. lawrence.peng 老师，看了前面的文章的话，经常能看到你说，linux服务器 nginx 5w/s ，lvs 80w/s 等等，并且知道这些机器是当前主流的配置 32C 48G, 要求我们要把这个性能指标背熟，目地是很明显的，为了做容量规划。但现在很多创业公司，基本上都是上云的，云主机的配置基本都是4C 8G,问题来了，怎么去做这个应用的容量规划呢？或者这些指标哪里能查阅吗？ 作者回复: 云主机的性能可以按照同配置的物理机80%的性能来估算 23. 道法自然 我也希望老师能对并发数，qps，日活等这些能够举个经典例子计算下，网上虽然有，可是总觉着讲解地不是很清楚，对这块一直都有点迷糊。 作者回复: 并发数：同一时刻的接收的访问数量，时间单位一般用秒，也可以用分钟和小时，常见有并发请求数，并发连接数. QPS：query per second，指查询类请求 日活：每日活跃用户数，指当天来访问过系统的用户，同一用户，无论用户访问多少功能和页面都只算一个用户 24. Mask 老师，这个负载均衡会涉及到数据同步吗？还是说我没搞懂😂，多台服务器其实访问的是同一个数据库服务器，不存在数据实时同步的问题。 作者回复: 负载均衡不涉及数据同步，是指将请求分发到不同服务器 25. 沐雪 千万日活 约等于 10亿级 访问量， 1万/秒的访问量；峰值4万； 若用Nginx，则有点危险，最好外面在加个 LVS ; 1个Lvs---> 4个Nginx 1个Nginx---> 10个tomcat 作者回复: Nginx顶4万没什么压力，配个64核的机器是够的. // 感觉不便宜 26. alter 老师，在DNS章节里面，是怎么保证北方用户访问的就是北方的机房，南方用户访问的就是深圳的机房? 作者回复: 可以根据用户ip解析出用户归属地，你在百度都可以搜到ip归属地查询，原理是一样的。 27. 小鬼爱风雪 1000万日活跃用户，最差情况是1000万并发，如果分散一下，500万可以了，以此量级去分析，真实场景会按照千万级设计 作者回复: 你这个估算太离谱了，1000万日活不可能有1000万并发的，如果按照你这个估算，微信和淘宝之类的业务，服务器是天文数字 个人补充： 确实有些离谱 28. 过去已落幕 示例里面硬件负载的性能比软件高，当并发足够大时候，硬件负载的下游软件负载处理不过来，会不会出现问题。 作者回复: 当然会出问题，会丢包，需要增加下游的处理能力   29. 追忆似水年华 想到一个问题，用户访问访问一个页面，浏览器本身的并发数在5～6之间，也就是会同时请求5～6个网页的静态资源，但是看大家在专栏里的讨论，好像都是把访问一个页面看做一个并发连接，这样统计没有问题么？ 作者回复: 你可以理解为大家讨论的是抽象出来的模型，假设一个页面一个连接，你说的是实际情况那就按5～6个来算 30. 脱缰的野马__ 老师，请问这三类负载均衡方式，都是怎么对目标节点存活状态进行实时监控的啊，比如心跳检测类似的。 没看到老师讲解， 如果某个地理级别的硬件负载均衡挂了、 或者硬件负载均衡中某个集群都挂了、 或者软件负载均衡中的某个机器挂了是怎么发现的呢？ 如果挂了他们都是怎么处理的呢？ 作者回复: 一看连接是否存在，二看是否能够发出去，三看响应是否快速 挂了当然是直接踢掉 31. 上班族程序员设计师的水果 怎样通过DNS来访问异地服务器？DNS服务器我们不是不能控制么？ 作者回复: DNS服务器你不能控制，但是脚本和配置都是你控制的呀 32. 慎独明强 看到华哥这章收获很大，之前见过这些名词很多次，但就是没搞清楚。DNS层应该都会有，进行域名解析为具体的ip。回头又看了公司之前运维发布的文章，公司采用的是腾讯云的组件，原理差不多，第一层有高防组件WAF并将https拆包为http，第二层是CLB(集群负载均衡)组件，第三层就是自己公司搭建的10台Nginx(8核16g)来反向代理到自己公司对应的服务器。 作者回复: 基本这已经是标配做法了 32. 古月三石 老师请教个问题，dns负载后边的数据库是一个还是多个？ 如果是多个怎么解决多个库间的同步问题，如果是一个那是不是网络延时会很大？ 作者回复: DNS本身就无法做到实时生效，而且主要是读操作，所以一个数据库和多个数据库在性能上都没问题，用一主多从就可以了，可用性和性能都能搞定  问题，DNS的并发请求不高吗？ 33. gameboy120 按照pv算一个页面一次请求，会不会不准，每个页面会有异步调用，这个不考虑进去吗？ 作者回复: pv是通用的，不一定很精确，但偏差不会太大 34. 刘鹏 老师，我有个地方不明白。现在有比如说现在有100w的并发量到 F5，绕后再分发到nginx，但nginx只能每秒5w的并发量，那说明再nginx处请求排队是吗？而且服务器就这么多，最后由nginx分发的请求 不应该和只用F5 分发是一样的吗？ 作者回复: 一个F5后面接20个nginx，每个nginx再接10个服务器，类似这种架构 35. I 上云就不用考虑这么多了 作者回复: 上云也要考虑买什么负载均衡设备呢 36. sunlight001 感觉这种设计初期，考虑用户体验，可以用dns+ha+nginx来做负载均衡，一般的可能不用dns也差不多，用了dns肯定是要快些的 作者回复: 论坛业务其实可以不用dns做地理位置负载均衡，用CDN效果更好 15 | 可编程的互联网世界-极客时间 37. Peiel Nginx 可以用作应用层网关，那么应用层网关怎么理解？ 可以理解成，我们通常在 Nginx 中对 HTTP 请求根据不同的api「uri」做相关的反向代理、负载均衡等相关配置，也就是所谓的api网关？ 作者回复: 嗯 38. X 你好老师，网关这个词一开始是在传输层接触到的，路由器起到的就是网关的作用，本质上是一个关口，数据包通过关口之后去寻找自己的目的地。 现在谈的应用层的网关，是不是就是HTTP的请求的关口，根据不同的URL映射到不同的服务端接口，可以把负载均衡器理解为应用层的网关吗？ 作者回复: 是的 个人补充： 网关，就是汇聚+转发 单台http/应用服务器的时候，就是反向代理 多台http/应用服务器的时候，就是负载均衡 39. 什么是反向代理与负载均衡器？ 同时，见下面的问题，API网关与负载均衡的区别，以及如何使用。 What is a Reverse Proxy vs. Load Balancer? - NGINX 截图 40. 负载均衡器和 API Gateway 混淆 dns - Load balancer and API Gateway confusion - Stack Overflow https://medium.com/@LadyNoBug/api-gateway-vs-load-balancer-5bbb2c6f0850 顺序可能如下： DNS -> 负载均衡器 -> API 网关 -> 后端服务 其实， 负载均衡器 与 API 网关的顺序，应该视架构而定。 您可以在 apiGateways 之前和/或之后放置负载均衡器。这些是具有其功能的术语，您希望如何放置它们取决于架构。 如果放置在 apiGateway 之前，则可以有效地平衡流向 apiGateway 的负载。在那之后，您还可以使用第 4 层负载均衡器来对您的应用程序（UI / 后端 Web 服务器）进行负载均衡。 同时请注意，负载均衡可以多级多个同时使用，但是，不得不说，由于请求路径的增加，整个请求/响应时间会增加，但是为了解决高并发问题，这是不得不平衡的事情。

4.参考

参见文档阅读列表

后续补充

...