负载均衡应用场景

一、背景

这两天在盘点IT资产，发现阿里云SLB每天在扣费，这个SLB是以前用来做公众号&小程序服务端负载均衡用的，现在牛奶业务处于维护老客户阶段，ECS只用一台就可以，SLB其实可以释放了。

二、负载均衡概念

负载均衡：对外部请求的流量分发到不同的后端服务器来扩展应用的吞吐能力以及消除单点故障。
DNS轮询负载均衡：DNS服务器将解析请求按照A记录的顺序，随机分配到不同的IP上。
四层负载均衡：四层指OSI的TCP层，四层负载均衡服务器接受客户端请求后，修改数据包的地址信息（IP+端口）将流量转发到应用服务器，一般可以将一个公网的IP映射成多个内部服务器地址。
七层负载均衡：七层指OSI的应用层，七层负载均衡服务器可以根据客户请求的URL或HTTP报头来做分发。
硬件四/七层负载均衡：通过智能交换机实现，处理能力强，但是很贵，最出名的就是F5,咱也没玩过。

三、DNS轮询配置例子

对同一主机名添加多条A记录，下面是我在35互联上做的一个解析。

将lb.vanmilk.com解析到  118.178.255.158和121.40.77.22,使用dig命令检查发现确实被解析到两个IP地址上了。

 

这是相对来讲成本最低的一种负载均衡做法，但存在两个很明显的缺点

1、可靠性低：当一台服务器挂了，你必须去DNS去下掉该IP，但DNS有缓存，需要一些时间后才会生效。
2、负载分配不均衡：采用简单轮询算法，不能为性能较好的服务器多分配请求。

四、软件四层负载均衡

最出名的就是LVS，是章文嵩开发的，大神级别的人物，阿里云很多基础设施都是他主导搭建的吧，膜拜一下。
阿里云的SLB：支持TCP/UDP四层负载，强大的四层处理能力，也支持HTTP/HTTPS七层负载但对七层的支持能力较弱，仅支持基于域名和URL转发，单实例连接数可以达500万，如果我没猜错的话这个应该是来源于LVS，更强大的面向应用ALB，咱也还没玩过。

SLB配置方法：

1、创建SLB实例，如果流量比较小，直接用按量付费就可以。
2、DNS解析指向SLB的公网IP。
3、配置监听，指定监听端口，如果是443要配置一下SSL证书，然后配置后端服务器，配置健康检查（当后端服务挂了，它就不会再向该台服务器转发请求）。

4、可以设置每台服务器的权重，应用发布的时候，把权重设置为0，等发布完了再调回去，这样就是不停机发布。
5、SLB配置好了基本就不用管了，然后每年SSL证书有变更，这里需要重新把证书推送上去。

五、Nginx反向代理实现软件七层负载均衡

前端部署Nginx服务器，后端部署Tomcat应用，用户访问时静态资源由Nginx直接返回，动态资源分发到Tomcat服务器，处理完成后返回数据组Nginx，Nginx再返回给浏览器。

Nginx配置负载主要有几下几种方式

1、轮询 

实验环境
121.40.77.25       搭建Nginx服务器做负载
121.40.77.25       应用1 
118.178.255.158    应用2
为了方便实验，在两台机器用nc -l 9999启动端口在监听，nc的具体应用可以参见 瑞士军刀。

upstream polling{
  server 121.40.77.25:9999 weight=1;
  server 118.178.255.158:9999 weight=2;
}
server {
  listen 80;
  server_name 121.40.77.25;
  location /{
    proxy_pass http://polling;
  }
}

默认就是轮询方式，weight不配置按请求时间均匀分配到对应的服务器，如果服务器down掉会自动剔除，这种配置一个问题是同一个客户端每次请求不一定分发到后端同一台服务器。

2、ip_hash

请求按IP 哈希结果分配，这样每个客户请求会被固定到访问某一台服务器，如果后端服务器down掉，需要手工将其标记为down状态，这种配置就不用解决会话同步的问题。

upstream polling{
  ip_hash;
  server 121.40.77.25:9999; 
  server 118.178.255.158:9999;
}

3、url_hash

可以将相同的URL映射到后端一台固定服务器，这个是Nginx第三方插件，需要编译时安装该插件。 

4、Nginx负载一个案例

我们的Vistablinds网站，当时有一个Php版本和一个Java版本，需要用Java版本替换掉Php版本，但又不能一次性全部切换，当时就用Nginx反向代理来实现，并且做了根据Cookie来保证原来访问Php版本的用户让其继续访问Php版本。