负载均衡_Maglev

昨天在开发者头条上看到了一篇关于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-负载均衡