浅谈负载均衡

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

当请求量越来越大,单机系统的性能难以招架。换成性能更好的机器,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。

具体不展开了。

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

  • 发表于:
  • 原文链接:https://kuaibao.qq.com/s/20180615G1ONQX00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

同媒体快讯

扫码关注云+社区

领取腾讯云代金券