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

一个系统发展初期，每每都是单机系统。应用和数据库在一台服务器上，随着业务的发展，访问量的增大，一台服务器性能就会出现天花板，每每已经难以支撑业务量了。这个时候就要考虑把数据库和应用服务器分开，访问继续增长，就会考虑数据库分库分表，应用服务器作负载均衡，其实这也属于分布式系统的一个范畴。分布式系统的核心概念就是一个“分”字，一台服务器支撑不住，那就两台，三台，四台....固然分以后会带来其余问题，好比最多见的数据一致性问题，调用链监控等问题，这些不在今日的讨论范围内，有兴趣的同窗请移步百度。

不少项目作“分布式”部署提升系统性能，首期采用的每每是负载均衡策略。

负载均衡

负载均衡，英文名称为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负载均衡了，没有一种方案是完美的，可是能够采用多种方案混用的方式来达到近乎完美的状况。

更多精彩文章

• 分布式大并发系列
• 架构设计系列
• 趣学算法和数据结构系列
• 设计模式系列