服务器负载均衡原理及实现

原文:https://blog.csdn.net/Gy__My/article/details/78790280


背景:当系统面临大量用户访问,负载过高的时候,通常会使用增加服务器数量来进行横向扩展,使用集群和负载均衡提高整个系统的处理能力。

在此先感谢两位作者:
1.作者:知乎用户
链接:https://www.zhihu.com/question/22610352/answer/138542422
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处

2.作者:GiraffeLin
链接:https://www.douban.com/note/325866291/?type=like
来源:豆瓣
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处

而我们讨论的负载均衡一般分为两种,一种是基于DNS,另一种基于IP报文。更详细的在这里就不说了。

下面给出几种负载均衡的原理图,也是我从网上扒的。
1.HTTP重定向


7059927-5fb6d7e74fe6e887.png
HTTP重定向

2.DNS负载均衡


7059927-81425dcdba985163.png
DNS负载均衡

3.反向代理负载均衡


7059927-b30ad243e36fae12.png
反向代理负载均衡
  1. IP负载均衡


    7059927-799dbeca1688a931.png
    IP负载均衡

5.直接路由


7059927-a9715bb3ef73432d.png
直接路由

这是我在网上查到的几种负载均衡原理图,还是挺直观的。下面说具体实现,也为了以后自己可以方便查阅

测试环境
由于没有服务器,所以本次测试直接host指定域名,然后在VMware里安装了三台CentOS。
测试域名 :a.com
A服务器IP :192.168.5.149 (主)
B服务器IP :192.168.5.27
C服务器IP :192.168.5.126
部署思路
A服务器做为主服务器,域名直接解析到A服务器(192.168.5.149)上,由A服务器负载均衡到B服务器(192.168.5.27)与C服务器(192.168.5.126)上。

域名解析
由于不是真实环境,域名就随便使用一个a.com用作测试,所以a.com的解析只能在hosts文件设置。
打开:C:WindowsSystem32driversetchosts
在末尾添加
192.168.5.149 a.com
保存退出,然后启动命令模式ping下看看是否已设置成功

从截图上看已成功将a.com解析到192.168.5.149IP
A服务器nginx.conf设置
打开nginx.conf,文件位置在nginx安装目录的conf目录下。
在http段加入以下代码

upstream a.com { 
server 192.168.5.126:80; 
server 192.168.5.27:80; 
}

server{ 
listen 80; 
server_name a.com; 
location / { 
proxy_pass http://a.com; 
proxy_set_header Host host;proxysetheaderX−Real−IPhost;proxysetheaderX−Real−IPremote_addr; 
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
} 
} 

保存重启nginx
B、C服务器nginx.conf设置
打开nginx.confi,在http段加入以下代码

server{ 
listen 80; 
server_name a.com; 
index index.html; 
root /data0/htdocs/www; 
} 

保存重启nginx
测试
当访问a.com的时候,为了区分是转向哪台服务器处理我分别在B、C服务器下写一个不同内容的index.html文件,以作区分。
打开浏览器访问a.com结果,刷新会发现所有的请求均分别被主服务器(192.168.5.149)分配到B服务器(192.168.5.27)与C服务器(192.168.5.126)上,实现了负载均衡效果。
B服务器处理页面

C服务器处理页面

假如其中一台服务器宕机会怎样?
当某台服务器宕机了,是否会影响访问呢?
我们先来看看实例,根据以上例子,假设C服务器192.168.5.126这台机子宕机了(由于无法模拟宕机,所以我就把C服务器关机)然后再来访问看看。
访问结果:

我们发现,虽然C服务器(192.168.5.126)宕机了,但不影响网站访问。这样,就不会担心在负载均衡模式下因为某台机子宕机而拖累整个站点了。
如果b.com也要设置负载均衡怎么办?
很简单,跟a.com设置一样。如下:
假设b.com的主服务器IP是192.168.5.149,负载均衡到192.168.5.150和192.168.5.151机器上
现将域名b.com解析到192.168.5.149IP上。
在主服务器(192.168.5.149)的nginx.conf加入以下代码:

upstream b.com { 
server 192.168.5.150:80; 
server 192.168.5.151:80; 
}

server{ 
listen 80; 
server_name b.com; 
location / { 
proxy_pass http://b.com; 
proxy_set_header Host host;proxysetheaderX−Real−IPhost;proxysetheaderX−Real−IPremote_addr; 
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
} 
} 

保存重启nginx
在192.168.5.150与192.168.5.151机器上设置nginx,打开nginx.conf在末尾添加以下代码:

server{ 
listen 80; 
server_name b.com; 
index index.html; 
root /data0/htdocs/www; 
} 

保存重启nginx
完成以后步骤后即可实现b.com的负载均衡配置。
主服务器不能提供服务吗?
以上例子中,我们都是应用到了主服务器负载均衡到其它服务器上,那么主服务器本身能不能也加在服务器列表中,这样就不会白白浪费拿一台服务器纯当做转发功能,而是也参与到提供服务中来。
如以上案例三台服务器:
A服务器IP :192.168.5.149 (主)
B服务器IP :192.168.5.27
C服务器IP :192.168.5.126
我们把域名解析到A服务器,然后由A服务器转发到B服务器与C服务器,那么A服务器只做一个转发功能,现在我们让A服务器也提供站点服务。
我们先来分析一下,如果添加主服务器到upstream中,那么可能会有以下两种情况发生:
1、主服务器转发到了其它IP上,其它IP服务器正常处理;
2、主服务器转发到了自己IP上,然后又进到主服务器分配IP那里,假如一直分配到本机,则会造成一个死循环。
怎么解决这个问题呢?因为80端口已经用来监听负载均衡的处理,那么本服务器上就不能再使用80端口来处理a.com的访问请求,得用一个新的。于是我们把主服务器的nginx.conf加入以下一段代码:

server{ 
listen 8080; 
server_name a.com; 
index index.html; 
root /data0/htdocs/www; 
}

重启nginx,在浏览器输入a.com:8080试试看能不能访问。结果可以正常访问
既然能正常访问,那么我们就可以把主服务器添加到upstream中,但是端口要改一下,如下代码:

upstream a.com { 
server 192.168.5.126:80; 
server 192.168.5.27:80; 
server 127.0.0.1:8080; 
} 

由于这里可以添加主服务器IP192.168.5.149或者127.0.0.1均可以,都表示访问自己。
重启Nginx,然后再来访问a.com看看会不会分配到主服务器上。

主服务器也能正常加入服务了。
最后
一、负载均衡不是nginx独有,著名鼎鼎的apache也有,但性能可能不如nginx。
二、多台服务器提供服务,但域名只解析到主服务器,而真正的服务器IP不会被ping下即可获得,增加一定安全性。

三、upstream里的IP不一定是内网,外网IP也可以。不过经典的案例是,局域网中某台IP暴露在外网下,域名直接解析到此IP。然后又这台主服务器转发到内网服务器IP中。
四、某台服务器宕机、不会影响网站正常运行,Nginx不会把请求转发到已宕机的IP上

最后推荐一本书:《构建高性能Web站点》,里面有很多醍醐灌顶的东西。


      每天坚持学习1小时Go语言,大家加油,我是彬哥,下期见!如果文章中不同观点、意见请文章下留言或者关注下方订阅号反馈!


社区交流群:221273219
Golang语言社区论坛 :
www.Golang.Ltd
LollipopGo游戏服务器地址:
https://github.com/Golangltd/LollipopGo
社区视频课程课件GIT地址:
https://github.com/Golangltd/codeclass


7059927-6b4f6fae486a718c.png
Golang语言社区

猜你喜欢

转载自blog.csdn.net/weixin_33850890/article/details/87094686