zoukankan      html  css  js  c++  java
  • 快速理解高性能HTTP服务端的负载均衡技术原理(转)

    1、前言


    在一个典型的高并发、大用户量的Web互联网系统的架构设计中,对HTTP集群的负载均衡设计是作为高性能系统优化环节中必不可少的方案。HTTP负载均衡的本质上是将Web用户流量进行均衡减压,因此在互联网的大流量项目中,其重要性不言而喻。

    本文将以简洁通俗的文字,为你讲解主流的HTTP服务端实现负载均衡的常见方案,以及具体到方案中的负载均衡算法的实现原理。理解和掌握这些方案、算法原理,有助于您今后的互联网项的技术选型和架构设计,因为没有哪一种方案和算法能解决所有问题,只有针对特定的场景使用合适的方案和算法才是最明智的选择。

    即时通讯网注:本文中所提及的HTTP负载均衡方案和算法,并不完全适用IM即时通讯Socket长连接的负载均衡,因为IM长连接、有状态的特性,跟HTTP这种短连接、无状态的特征是矛盾的,所以请勿盲目套用。但,一个完整的IM系统是由HTTP短连接+IM长连接组成,因而本文内容虽不能套用于IM长连接的负载均衡方案,但可以用于您IM的高并发、大用户量的HTTP短连接的方案设计。

    2、相关文章


    深入阅读以下文章,有助于您更好地理解本篇内容:


    3、什么是负载均衡?


    早期的互联网应用,由于用户流量比较小,业务逻辑也比较简单,往往一个单服务器就能满足负载需求。随着现在互联网的流量越来越大,稍微好一点的系统,访问量就非常大了,并且系统功能也越来越复杂,那么单台服务器就算将性能优化得再好,也不能支撑这么大用户量的访问压力了,这个时候就需要使用多台机器,设计高性能的集群来应对。

    那么,多台服务器是如何去均衡流量、如何组成高性能的集群的呢?

    此时就需要请出 「负载均衡器」 入场了。

    负载均衡(Load Balancer)是指把用户访问的流量,通过「负载均衡器」,根据某种转发的策略,均匀的分发到后端多台服务器上,后端的服务器可以独立的响应和处理请求,从而实现分散负载的效果。负载均衡技术提高了系统的服务能力,增强了应用的可用性。

    负载均衡的基本原理就像下图这样:
    <ignore_js_op>快速理解高性能HTTP服务端的负载均衡技术原理_1.jpeg 

    4、主流负载均衡方案有几种?


    目前市面上最常见的负载均衡技术方案主要有三种:

    • 1)基于DNS负载均衡;
    • 2)基于硬件负载均衡:比如F5
    • 3)基于软件负载均衡:比如Nginx、Squid。

    三种方案各有优劣,DNS负载均衡可以实现在地域上的流量均衡,硬件负载均衡主要用于大型服务器集群中的负载需求,而软件负载均衡大多是基于机器层面的流量均衡。在实际场景中,这三种是可以组合在一起使用。

    下面分别来详细讲讲这些方案。

    4.1基于DNS负载均衡


    <ignore_js_op>快速理解高性能HTTP服务端的负载均衡技术原理_2.png 

    基于DNS来做负载均衡其实是一种最简单的实现方案,通过在DNS服务器上做一个简单配置即可

    其原理就是:当用户访问域名的时候,会先向DNS服务器去解析域名对应的IP地址,这个时候我们可以让DNS服务器根据不同地理位置的用户返回不同的IP。比如南方的用户就返回我们在广州业务服务器的IP,北方的用户来访问的话,我就返回北京业务服务器所在的IP。

    在这个模式下,用户就相当于实现了按照「就近原则」将请求分流了,既减轻了单个集群的负载压力,也提升了用户的访问速度。

    使用DNS做负载均衡的方案,天然的优势就是配置简单,实现成本非常低,无需额外的开发和维护工作。

    但是它也有一个明显的缺点:当配置修改后,生效不及时。这个是由于DNS的特性导致的,DNS一般会有多级缓存,所以当我们修改了DNS配置之后,由于缓存的原因,会导致IP变更不及时,从而影响负载均衡的效果。

    另外,使用DNS做负载均衡的话,大多是基于地域或者干脆直接做IP轮询,没有更高级的路由策略,所以这也是DNS方案的局限所在。

    4.2基于硬件负载均衡


    <ignore_js_op>快速理解高性能HTTP服务端的负载均衡技术原理_3.jpg 

    硬件的负载均衡那就比较牛逼了,比如大名鼎鼎的 F5 Network Big-IP,也就是我们常说的 F5,它是一个网络设备,你可以简单的理解成类似于网络交换机的东西,完全通过硬件来抗压力,性能是非常的好,每秒能处理的请求数达到百万级,即 几百万/秒 的负载,当然价格也就非常非常贵了,十几万到上百万人民币都有。

    因为这类设备一般用在大型互联网公司的流量入口最前端,以及政府、国企等不缺钱企业会去使用。一般的中小公司是不舍得用的。

    采用 F5 这类硬件做负载均衡的话,主要就是省心省事,买一台就搞定,性能强大,一般的业务不在话下。而且在负载均衡的算法方面还支持很多灵活的策略,同时还具有一些防火墙等安全功能。但是缺点也很明显,一个字:贵。

    4.3基于软件负载均衡


    <ignore_js_op>快速理解高性能HTTP服务端的负载均衡技术原理_4.jpeg 

    软件负载均衡是指使用软件的方式来分发和均衡流量。软件负载均衡分为7层协议 和 4层协议。

    网络协议有七层,基于第四层传输层来做流量分发的方案称为4层负载均衡,例如 LVS;而基于第七层应用层来做流量分发的称为7层负载均衡,例如 Nginx。这两种在性能和灵活性上是有些区别的。

    基于4层的负载均衡性能要高一些,一般能达到 几十万/秒 的处理量,而基于7层的负载均衡处理量一般只在 几万/秒 。

    基于软件的负载均衡的特点也很明显,便宜。在正常的服务器上部署即可,无需额外采购,就是投入一点技术去优化优化即可,因此这种方式是互联网公司中用得最多的一种方式。

    5、常用的均衡算法有哪些?


    上面讲完了常见的负载均衡技术方案,那么接下来咱们看一下,在实际方案应用中,一般可以使用哪些均衡算法?

    主要的均衡算法有:

    • 1)轮询策略;
    • 2)负载度策略;
    • 3)响应策略;
    • 4)哈希策略。

    下面来分别介绍一下这几种均衡算法/策略的特点。

    5.1轮询策略


    轮询策略其实很好理解,就是当用户请求来了之后,「负载均衡器」将请求轮流的转发到后端不同的业务服务器上。这个策略在DNS方案中用的比较多,无需关注后端服务的状态,只药有请求,就往后端轮流转发,非常的简单、实用。

    在实际应用中,轮询也会有多种方式,有按顺序轮询的、有随机轮询的、还有按照权重来轮询的。前两种比较好理解,第三种按照权重来轮询,是指给每台后端服务设定一个权重值,比如性能高的服务器权重高一些,性能低的服务器给的权重低一些,这样设置的话,分配流量的时候,给权重高的更多流量,可以充分的发挥出后端机器的性能。

    5.2负载度策略


    负载度策略是指当「负载均衡器」往后端转发流量的时候,会先去评估后端每台服务器的负载压力情况,对于压力比较大的后端服务器转发的请求就少一些,对于压力比较小的后端服务器可以多转发一些请求给它。

    这种方式就充分的结合了后端服务器的运行状态,来动态的分配流量了,比轮询的方式更为科学一些。

    但是这种方式也带来了一些弊端,因为需要动态的评估后端服务器的负载压力,那这个「负载均衡器」除了转发请求以外,还要做很多额外的工作,比如采集 连接数、请求数、CPU负载指标、IO负载指标等等,通过对这些指标进行计算和对比,判断出哪一台后端服务器的负载压力较大。

    因此这种方式带来了效果优势的同时,也增加了「负载均衡器」的实现难度和维护成本。

    5.3响应策略


    响应策略是指,当用户请求过来的时候,「负载均衡器」会优先将请求转发给当前时刻响应最快的后端服务器。

    也就是说,不管后端服务器负载高不高,也不管配置如何,只要觉得这个服务器在当前时刻能最快的响应用户的请求,那么就优先把请求转发给它,这样的话,对于用户而言,体验也最好。

    那「负载均衡器」是怎么知道哪一台后端服务在当前时刻响应能力最佳呢?
    这就需要「负载均衡器」不停的去统计每一台后端服务器对请求的处理速度了,比如一分钟统计一次,生成一个后端服务器处理速度的排行榜。然后「负载均衡器」根据这个排行榜去转发服务。

    那么这里的问题就是统计的成本了,不停的做这些统计运算本身也会消耗一些性能,同时也会增加「负载均衡器」的实现难度和维护成本。

    5.4哈希策略


    Hash策略也比较好理解,就是将请求中的某个信息进行hash计算,然后根据后端服务器台数取模,得到一个值,算出相同值的请求就被转发到同一台后端服务器中。

    常见的用法是对用户的IP或者ID进行这个策略,然后「负载均衡器」就能保证同一个IP来源或者同一个用户永远会被送到同一个后端服务器上了,一般用于处理缓存、会话等功能的时候特别好用。

    6、本文小结


    基于运营成本的考虑,目前在互联网项目中,HTTP服务端的负载均衡的具体解决方案,用的最多的还是Nginx(及其分支,比如淘宝的Tengin),如果有时间,建议可以把Nginx下载下来,仔细研究研究它的负载均衡原理,以及它所提供的几种负载均衡算法,理论联系实际来学习就更能促进你对相关知识的理解和掌握了。

    得益于Nginx这种开源免费的高性能方案,它们间接地促进了互联网的繁荣,感谢这些伟大开源方案背后的无私贡献者们!

    附录:更多架构设计方案的文章精选


    浅谈IM系统的架构设计
    简述移动端IM开发的那些坑:架构设计、通信协议和客户端
    一套海量在线用户的移动端IM架构设计实践分享(含详细图文)
    一套原创分布式即时通讯(IM)系统理论架构方案
    从零到卓越:京东客服即时通讯系统的技术架构演进历程
    蘑菇街即时通讯/IM服务器开发之架构选择
    腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT
    微信后台基于时间序的海量数据冷热分级架构设计实践
    微信技术总监谈架构:微信之道——大道至简(演讲全文)
    如何解读《微信技术总监谈架构:微信之道——大道至简》
    快速裂变:见证微信强大后台架构从0到1的演进历程(一)
    17年的实践:腾讯海量产品的技术方法论
    移动端IM中大规模群消息的推送如何保证效率、实时性?
    现代IM系统中聊天消息的同步和存储方案探讨
    IM开发基础知识补课(二):如何设计大量图片文件的服务端存储架构?
    IM开发基础知识补课(三):快速理解服务端数据库读写分离原理及实践建议
    IM开发基础知识补课(四):正确理解HTTP短连接中的Cookie、Session和Token
    WhatsApp技术实践分享:32人工程团队创造的技术神话
    微信朋友圈千亿访问量背后的技术挑战和实践总结
    王者荣耀2亿用户量的背后:产品定位、技术架构、网络方案等
    IM系统的MQ消息中间件选型:Kafka还是RabbitMQ?
    腾讯资深架构师干货总结:一文读懂大型分布式系统设计的方方面面
    以微博类应用场景为例,总结海量社交系统的架构设计步骤
    快速理解高性能HTTP服务端的负载均衡技术原理
    >> 更多同类文章 ……

    即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

  • 相关阅读:
    15. DML, DDL, LOGON 触发器
    5. 跟踪标记 (Trace Flag) 834, 845 对内存页行为的影响
    4. 跟踪标记 (Trace Flag) 610 对索引组织表(IOT)最小化日志
    14. 类似正则表达式的字符处理问题
    01. SELECT显示和PRINT打印超长的字符
    3. 跟踪标记 (Trace Flag) 1204, 1222 抓取死锁信息
    2. 跟踪标记 (Trace Flag) 3604, 3605 输出DBCC命令结果
    1. 跟踪标记 (Trace Flag) 1117, 1118 文件增长及空间分配方式
    0. 跟踪标记 (Trace Flag) 简介
    SpringBoot + Redis + Shiro 实现权限管理(转)
  • 原文地址:https://www.cnblogs.com/wangbin/p/10727898.html
Copyright © 2011-2022 走看看