一个服务,当请求量不大时,单机系统轻松搞定。
当请求量越来越大,单机系统的性能难以招架。换成性能更好的机器,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。
具体不展开了。
本文的扩容流程并不是最佳实践,只是通过这个例子说明,业务量对系统架构的影响,系统架构随着业务量的增加,不断地演化。
领取专属 10元无门槛券
私享最新 技术干货