负载均衡_Maglev

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/StanleyHuNju/article/details/53354578

昨天在开发者头条上看到了一篇关于G家的负载均衡的介绍:Google 是如何做负载均衡的? 又勾起了之前对负载均衡的研究回忆,因此把负载均衡总结一下,并加入G家的Maglev。(我之前虽然预研了这些负载均衡的技术,但是并未在高并发的生产环境实践过,有不当的地方欢迎指出吐舌头

一、负载均衡之What 

负载均衡(Load Balancing)用于改进多个服务之间的负载分布。负载均衡的目标是优化资源利用率,最大化吞吐量,降低响应时间,避免单个服务出现过载。

二、 负载均衡之Why 

随着网站的访问量增加,当原先的单机部署的网站已很难承受高请求量时,目前常用的做法已经不是去购买容量更高、性能更好,但同时价格也贵很多的服务设备,而是转向分布式部署。在进行了服务拆分、分布式部署时,需要解决业务单点问题和访问的统一入口问题。为了解决业务服务单点的可用性问题,通常采用资源冗余的思路,将业务服务部署到多个机器上;对于统一入口问题,采用负载均衡设备,实现流量的分发。

三、常用的负载均衡实现技术

3.1 从整个互联网系统的使用范围来看,使用负载均衡的范围通常有:DNS负载均衡、客户端负载均衡、服务端负载均衡。

DNS主要是使用Round-Robin算法来对网站提供的ip列表进行轮询,响应当前轮询到的ip地址给请求的客户端。另一种是更加高效的是DNS托管服务,这种方法会根据后端服务状态决定是否将请求流量导过去,同时根据后端服务到DNS解析服务器的响应包时间来决定流量转发给哪个后端,从而实现了地理位置敏感的DNS负载均衡。一般DNS负载均衡是作为大型网站的第一级负载均衡。

客户端负载均衡,是通过一些途径,将服务端的机器ip列表发送至客户端,客户端按照一定算法选择机器,若服务请求不通,则在剩下的ip列表中继续选择。

服务端负载均衡,是大家最常见的负载均衡应用,一般是在服务端监听一个统一的入口,然后对接收到的请求,按照调度算法转发到后端的服务器去处理。顺便说一下,反向代理一般是用于隔离服务的内部网络跟外部网络,在反向代理服务转发给后端服务时,若是后端有多个服务,则也达到了负载均衡的目的。

3.2 由于本人接触比较多的还是服务端负载均衡,因此我对服务端负载均衡再进一步总结一下。

服务端的负载均衡技术,按照OSI网络协议栈所在层次,大致可分为四层负载均衡和七层负载均衡技术。

四层负载均衡,主要是基于IP+端口进行流量转发,一般使用的有:硬件负载均衡F5(性能非常好,价格也不菲),LVS;七层负载均衡,主要是基于URL应用层信息进行流量转发,一般使用的有:Nginx, HAProxy。

七层负载均衡的Nginx和HAProxy对于中小型的网站系统一般足够了,可以根据URL进行一些分流策略,比如针对域名、目录结构,而且抗并发能力较强;另外通过结合KeepAlived组件消除单点问题。存在的问题是,Nginx不支持session粘滞,对后端服务的检测只支持根据端口,而HAProxy则支持。

四层负载均衡中的LVS是章文嵩博士发起的开源项目(致敬!),在Linux操作系统的核心层工作,将收到的网络数据进行处理然后转发,因而效率非常高。LVS基于IP负载均衡的技术,主要的三种机制为:VS/NAT,VS/TUN,VS/DR,这部分网上资料很多,不细说了。LVS+KeepAlived是实际中使用较多的负载均衡方式。

四、Maglev

终于轮到今天的主角了,G家公布的Maglev! 

Maglev是Google在数据中心使用的软件负载均衡服务,自2008年就已在其生产环境使用。我从参考的博客中对Maglev有了一些了解,个人感觉Maglev相对于现有的负载均衡技术,亮点在于(1) 更高效的请求转发,(2) Maglev自身支持集群化,达到了高可用及负载均衡节点的高利用率。

下图是Google文章中介绍网络请求的数据流图,这个是个整个涉及流程的介绍:


细节可以参考下面的参考文章,这里主要说一下大致思路。

LVS支撑的并发请求量已经非常高,但是Google发现Linux系统是其瓶颈,为了突破这一瓶颈,他们可能做了如下分析:他们期待的是使用通用的服务器来实现网络请求的负载均衡功能,LVS是在Linux内核层,处理通过网络协议栈向操作系统传递的数据包,这中间从网卡接收到数据,到经过TCP/IP网络协议栈的向上层传递,以及内核的一系列filter模块,才能实际处理转发,他们认为其中可以省略不必要的步骤,因而他们在网卡层面处理,直接对接网卡的输入、输出队列,而且只对数据包的<源地址,源端口,目标地址,目标端口,协议号>这五元组处理后即可交由网卡进行转发。这真的做的很极致...这也让人想起奥卡姆剃须刀原理,“如无必要,勿增实体”,我们在平时工作中处理问题,也尽可能多去想想,那么也可能做出简单但却更好的作品。

集群化,主要需要解决会话保持以及集群中节点的加入退出问题,这里Google通过查找表和改进的一致性Hash算法---Maglev Hashing来实现的,佩服。

这次主要是对负载均衡技术的总体回顾,并简单介绍了令人兴奋的Maglev,后面会进一步研究Maglev,并补充Maglev的一些具体技术实现。


【文章参考】

  1.  Google是如何做负载均衡的?
  2.  负载均衡的一点整理
  3.  Google shares software network load balancer design powering GCP networking
  4.  Morning Paper: Maglev: A Fast and Reliable Software Network Load Balancer 
  5.  [論文中文導讀] Maglev : A Fast and Reliable Software Network Load Balancer (using Consistent Hashing)
  6.  wiki-负载均衡


展开阅读全文

没有更多推荐了,返回首页