浅谈负载均衡

一个服务，当请求量不大时，单机系统轻松搞定。

当请求量越来越大，单机系统的性能难以招架。换成性能更好的机器，cpu频率更高、核数更多，磁盘更大、转得更快。暂时消停了。

当请求量继续增加时，要么难以找到满足性能要求的机器了，要么高性能的服务器太昂贵了用不起，这时就需要负载均衡器了。

负载均衡器，这个名字具有误导性，并不是单指均衡不同机器的负载，而是一个任务分发/调度器。业务请求向进入负载均衡器，负载均衡器根据调度策略，将请求转发不同的业务服务器上，多台业务服务共同承载业务服务。这样就形成一个业务服务集群，业务服务器的台数与服务集群的处理能力大致成正比。

这个阶段的负载均衡器，多是七层负载均衡器，类如nginx、haproxy等，其性能大致为5万qps。

如下图所示：

事情还没完，业务量继续增加，超过单台负载均衡器的处理能力了。按照负载均衡的思路，需要多个负载均衡器共同承载转发工作。

怎么给(七层)负载均衡器进行负载均衡呢？这时四层负载均衡器可以大展拳脚了。

(四层负载均衡器，有F5和A10以及LVS。前两个是硬货，是硬件负载均衡器，性能可达百万级以上，牛的不要不要的，问题是贵的要死，不差钱的银行和一些国有企业才用的起。我久闻其名，未曾亲眼见过。

LVS属于linux内核模块，据说调优后的最高性能可达80万，没有测试过)

将四层负载均衡器部署在七层负载均衡器前，这样由多了一层，有点像不断膨胀的管理层级。

如下图所示：

好了，又可以轻松一阵了。业务请求继续增加，单台LVS也抗不住了。怎么办？

优化LVS，使用DPDK绕过linux复杂的通用的协议栈，直接从网卡拿到数据，进行转发，性能可以百万级以上了！

又可以轻松了，业务继续增长，新搞的牛气冲天的LVS又被压趴下了。

怎么办？对LVS进行负载均衡！！？

利用交换机加OSPF协议，对多台LVS进行负载均衡。哦，天！又多了一层。

如下图所示：

业务继续增加，交换机也不行了等等等等。

最后不断负载均衡的思路，终于走不下去。

且慢，为什么非要用一个外网IP呢？

使用DNS负载均衡，一个域名对应多个IP，每个IP对应一套LVS集群。客户端发起请求之前，对该域名进行域名解释时，DNS依次返回不同的IP，客户端使用不同的IP发起业务请求，业务请求被分流到不同的LVS集群了。

如下图所示，其中DNS至交换机的线为虚线，从DNS到交换机不是真正的数据流。

业务不断发展壮大，大量的用户遍布全国，服务器的机房发生几次断电、光纤被老鼠咬断(好厉害的老鼠)的情况，某某公司决定部署异地机房，进行多机房异地容灾。

此时仍然可以使用DNS配置多机房的服务IP。DNS可以按照用户的IP地址归属地，给用户返回物理较近的机房IP。例如北京用户，请求域名解释时，返回北京机房的IP，北京用户的请求就被引导到北京机房了。就近服务，时延更短、用户体验更好。

现在的问题是当一个机房的服务不可用时，由于dns服务缓存了该机房的IP，当用户请求时，dns仍然返回这个不可用的服务IP，用户将访问不可用的机房，多机房容灾的目的就落空了。

怎么办？更智能的DNS或者自建HTTPDNS。

具体不展开了。

本文的扩容流程并不是最佳实践，只是通过这个例子说明，业务量对系统架构的影响，系统架构随着业务量的增加，不断地演化。