关于负载均衡:高并发系统设计负载均衡架构

37次阅读

共计 2378 个字符，预计需要花费 6 分钟才能阅读完成。

一个零碎倒退初期，往往都是单机零碎。利用和数据库在一台服务器上，随着业务的倒退，访问量的增大，一台服务器性能就会呈现天花板，往往曾经难以撑持业务量了。这个时候就要思考把数据库和应用服务器离开，拜访持续减少，就会思考数据库分库分表，应用服务器做负载平衡，其实这也属于分布式系统的一个领域。分布式系统的外围概念就是一个“分”字，一台服务器撑持不住，那就两台，三台，四台 …. 当然分之后会带来其余问题，比方最常见的数据一致性问题，调用链监控等问题，这些不在今日的探讨范畴内，有趣味的同学请移步百度。

很多我的项目做“分布式”部署进步零碎性能，首期采纳的往往是负载平衡策略。

负载平衡，英文名称为 Load Balance，其含意就是指将负载（工作工作）进行均衡、摊派到多个操作单元上进行运行，例如 FTP 服务器、Web 服务器、企业外围应用服务器和其它次要工作服务器等，从而协同实现工作工作。负载平衡构建在原有网络结构之上，它提供了一种通明且便宜无效的办法扩大服务器和网络设备的带宽、增强网络数据处理能力、减少吞吐量、进步网络的可用性和灵活性。

负载平衡既然属于“分”策略的一种表现形式，就会波及到工作的调配者，工作执行者，调配算法。这里的任务分配者就是咱们常说的负载均衡器，工作执行者就是解决工作的服务器，调配算法就是常说的轮训等调配策略。这里把工作的调配者叫做负载均衡器其实是不正确的，负载均衡器这个概念重视的更多是平均分配任务，让每个工作的计算单元的任务量达到平衡状态，而事实中工作的调配更多是出于每个计算单元的性能或者业务来思考。让每个计算单元解决简直雷同数量的工作只是分布式均衡器其中的一部分内容。

以 http 申请为例，在一个 http 申请的过程中，其实会遇到有很多负载平衡的过程，一个零碎在什么阶段做负载平衡取决于它的申请量，这和常说的 QPS/TPS/DAU 等有间接关系，假如零碎的申请量非常少，其实齐全没有必要做负载平衡，当然有时候为了达到高可用的目标也做负载平衡，这里不在展开讨论。那一个 http 申请到底能够通过哪些负载均衡器呢？http 申请的过程如下图所示

DNS 负载平衡

当一个 client 向一个 url 发动申请（这里不思考间接申请 IP 地址的状况），第一步须要做的就是申请 DNS 服务器去做域名解析，把申请的域名转换成 IP 地址。DNS 解析同一个域名能够依据起源返回不同的 IP 地址，利用这个个性能够做 DNS 负载平衡。client 申请离本人最近的资源才是最快的，所以能够把零碎部署在不同区域的机房，每个 client 通过 DNS 解析只申请离本人最近的机房资源，比申请异地的机房资源要快的多。例如：一个网站能够同时部署在北京机房和深圳机房，河北的用户申请网站的时候都会被导向北京机房，比拜访深圳的速度要快的多。

DNS 负载平衡仅限于解析域名的机会，所以它的力度是很粗的，相应的负载平衡算法也无限。然而这种计划实现起来比较简单，老本也很低，而且在肯定水平了缩短了用户的响应工夫，放慢了访问速度。因为 DNS 信息都有很长时间的缓存，所以更新的时候会有一段时间的信息差别，会导致局部用户失常业务的拜访的谬误。

硬件负载平衡

当一个申请晓得了要拜访的指标 IP，便会通过层层的网关和路由器达到指标 IP 的机房，在这之前属于网络传输的领域，个别很难进行干涉。有很多机房都通过硬件设施来实现负载平衡的目标，这和路由器、交换机相似，也能够了解为底层的设施。目前最罕用的莫过于 F5 了，这样的硬件设施个别都出产于大公司，性能都通过严格测试，功能强大，然而很贵，个别的中小公司不会更没有必要应用这种土豪设施。

硬件负载平衡性能很弱小，撑持的并发个别都在每秒几百万，而且反对的负载算法也很多，而且个别都配套的有平安防护措施，比方防火墙，防攻打等平安性能。

软件负载平衡

相比于硬件负载平衡，当初每个公司更常见的是软件负载平衡，根本过程就是独立出一个负载平衡服务器或者集群，装置上有负载平衡性能的软件来进行散发。最罕用的 4 层负载平衡软件 LVS，简直所有应用层的负载平衡都能够做，目前 LVS 曾经被集成到 Linux 内核模块中。该我的项目在 Linux 内核中实现了基于 IP 的数据申请负载平衡调度计划。还有处于 7 层的 nginx 也能够实现负载平衡，Nginx 反对 HTTP、E-mail 协定，当然当初有相应的 nginx 做 4 层负载平衡的模块。

与硬件想比，软件负载平衡的吞吐量要小很多，就算是 4 层的 LVS 的性能也只在几十万而已，nginx 在几万，不过这对于个别公司的业务也足够了，当一个公司的业务量申请量达到几百万，预计也有钱买 F5 硬件了。软件负载平衡的最大劣势在于配置灵便，可扩展性强，可定制性比拟强，而且老本还很低。这也是中小公司首选的计划。

说了这么多，其实以上几种计划是基于 http 申请的途经来解决问题，每种计划都有它本人的毛病和长处，设计一个零碎的时候初期就把以上计划全副采纳以达到高性能的要求，兴许并不是什么坏事，每一个零碎都是随着业务的增长而逐步扭转架构状态，而这个过程采纳的负载计划个别过程都是软件负载 -> 硬件负载 ->DNS 负载，当然这里的硬件和 DNS 兴许有时候会颠倒过去，然而软件必定是首当其冲的。随着业务量的增大，以上三种计划更多的是互相配合，相互补充的，就像微信这种业务，不可能独自的应用硬件负载就能达到业务要求的。

至于什么阶段采纳什么计划，还是要依据具体业务的申请量来决定，比方：以后我的 QPS 在一万左右，齐全能够用 nginx 或者 LVS 去解决，当回升到百万级别，能够尝试着用硬件 + 软件的形式去解决，当达到千万甚至更高，就要思考多机房部署 DNS 负载平衡了，没有一种计划是完满的，然而能够采纳多种计划混用的形式来达到近乎完满的状况。