负载均衡LB的几种做法

上一篇 / 下一篇  2017-06-21 13:43:19

当一个网络服务,用户数量上升到一定规模,或者要考虑高可用的情况下,一定要考虑使用负载均衡, 将用户的大量请求,分担到可以水平扩展的前置服务器中,而且当某台前置服务器下线,对用户的正常使用没有影响。  所以一个大用户的系统和一个高可用的系统,一定必不可少的要使用负载均衡。  

负载均衡有几种做法,在这简单的介绍并讨论各自的优缺点。 


1 基于智能域名解析的负载均衡 

DNS将一个域名解析为一个或多个ip地址, 用这个来实现负载均衡。 这个做法的好处是简单,只管水平扩展前置服务器,每个前置服务器配置公网ip,然后这个ip地址添加到dns解析列表中,让dns按某种策略解析给用户。 缺点是,流量无法均匀分担到前置服务器上; dns全网域名的更新不可控,可能某个ip主机要下线,但域名更改到生效慢的要几天到几十天;前置服务器无法做到高可用,一旦出问题,该ip上的用户都会断服; F16C  D E 基本都是这样情况,pusher A B 也同样; 


2 应用层做负载均衡

在所有前置服务器前,配置一个接入服务器,可以用 nginx httpd来实现,作为应用层LBS。用nginx的 rewrite模块实现请求的转发,也可以返回给浏览器redirect。这种做法的好处是,真正的前置服务器隐藏在LB的后面,可以快速的扩大、收缩。没有用域名解析负载均衡方案中的缺点。 本方案的缺点是, 负载均衡本身(nginx)也会成为性能的瓶颈,前置服务器的数量也不能持续增加;另外nginx的tcp句柄的数量会翻倍,既要保持与客户的tcp连接,又要保持与真正的前置服务器的连接;


3 基于ip层的负载均衡  LVS

LVS是国内章博士开源的一个很有名的一个项目, 我个人理解,这个负载均衡器就是一个特殊网关,在IP层对请求的报文做一些修改,然后转发到真实服务器。网上很多文章可以参考。 LVS单节点很高效,因为工作在网络层,只做报文的修改和分发,与可靠性相比,性能问题基本可以忽略。而为了达到LVS的高可用, 一般通过部署主备2台,然后相互监控心跳,一旦主设备下线,把主设备的浮动ip,动态变更到被设备上,实现高可用; 这个方案已经很完美解决性能与高可用的问题, 如果找缺点,那,在浮动ip切换的场景下,估计会有10秒左右的时间,服务不可用 。  


上面的几种做法都算是比较通用的做法,不需要太多的开发就可以快速实现。另外还有几种方法可以考虑。  


4 动态分配接入点 

这个做法是云吧创始人张虎在一次分享会中提到的。 做法的主要思路是,server端部署一个ticket服务器,在这保存所有前置服务器列表,各个服务器kpi指标(负载算法用)。而在用户测app,通过域名先请求ticket,并求ticket返回给用户一个真实的前置服务器ip地址。 同时在app中预埋一个 ticket的ip地址,当全网DNS异常的情况下,用户请求也不受影响。 


5 前置服务器同时做接入和负载均衡,每个前置服务器都有负载均衡的任务

每一个前置服务器节点,通常用一个高性能的web容器,比如nginx管理大量的连接, 然后nginx把请求转给本机的业务服务器比如ruby的unicorn进程。 在这种情况下,可以考虑在nginx上做些调整,同时做接入和负载均衡。 所有前置服务器构成一个集群,在这个集群中用户的请求是可以被转发的,在请求的头参数中增加一个转发计数器,每转一次加一, 假定用户的请求最多只允许转发一次。 在nginx收到请求后,如果后端的业务服务器正常,且有空余能力的情况下, 直接转给业务服务器处理,否则计数器加一,随机转发给集群中的另一个节点。 

集群中的节点,要相互感知,要知道哪些伙伴在,这样才能正确做出转发请求;

每个节点要知道自己业务服务器是否正常,这样才能知道哪些请求要处理,哪些要转走; 

业务服务器unicorn异常,那本节点通知伙伴自己下线,同时前置服务器进入全转发模式;

缺点是稍微有点复杂, 而且也只能应对单节点应用服务故障,对节点都异常的情况,对用户还是有影响的。 


TAG:

 

评分:0

我来说两句

日历

« 2024-03-26  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 80302
  • 日志数: 94
  • 文件数: 1
  • 建立时间: 2017-04-14
  • 更新时间: 2020-11-17

RSS订阅

Open Toolbar