概述
系统的扩展可以分为纵向扩展和横向扩展。
- 纵向扩展是从单机的角度出发，通过增加系统的硬件处理能力来提升服务器的处理能力
- 横向扩展是通过添加机器来满足大型网站服务的处理能力。
这里面涉及到两个重要的角色分别是"应用集群"和"负载均衡器"。
- 应用集群：将同一应用部署到多台机器上，组成处理集群，接收负载均衡设备分发的请求，进行处理并返回响应的数据。
- 负载均衡器:将用户访问的请求根据对应的负载均衡算法，分发到集群中的一台服务器进行处理。
- 负载均衡的优势
- 解决服务器的高并发压力，提高应用程序的处理性能。
- 提供故障转移，实现高可用。
- 通过添加或减少服务器数量，增强网站的可扩展性。
- 在负载均衡器上进行过滤，可以提高系统的安全性。
- 负载均衡的方式
- 用户手动选择
在网站主页上面提供不同线路、不同服务器链接方式，让用户来选择自己访问的具体服务器，来实现负载均衡。
- DNS轮询方式
大多域名注册商都支持对同一个主机名添加多条A记录，这就是DNS轮询，DNS服务器将解析请求按照A记录的顺序，随机分配到不同的IP上，这样就能完成简单的负载均衡。DNS轮询的成本非常低，在一些不重要的服务器，被经常使用。虽然DNS轮询成本低廉，但是可靠性低，负载均衡不均衡
四层负载均衡
在OSI七层模型中的传输层中主要是基于IP+PORT的负载均衡
所谓四层负载均衡，也就是主要通过报文中的目标地址和端口，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。
以常见的TCP为例，负载均衡设备在接收到第一个来自客户端的SYN 请求时，即通过上述方式选择一个最佳的服务器，并对报文中目标IP地址进行修改(改为后端服务器IP），直接转发给该服务器。TCP的连接建立，即三次握手是客户端和服务器直接建立的，负载均衡设备只是起到一个类似路由器的转发动作。在某些部署情况下，为保证服务器回包可以正确返回给负载均衡设备，在转发报文的同时可能还会对报文原来的源地址进行修改。
实现四层负载均衡的方式：
- 硬件：F5 BIG-IP、Radware等
- 软件：LVS、Nginx、Hayproxy等
七层负载均衡
在OSI七层模型中的应用层中主要是基于虚拟的URL或主机IP的负载均衡
所谓七层负载均衡，也称为“内容交换”，也就是主要通过报文中的真正有意义的应用层内容，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。
以常见的TCP为例，负载均衡设备如果要根据真正的应用层内容再选择服务器，只能先代理最终的服务器和客户端建立连接(三次握手)后，才可能接收到客户端发送的真正应用层内容的报文，然后再根据该报文中的特定字段，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。负载均衡设备在这种情况下，更类似于一个代理服务器。负载均衡和前端的客户端以及后端的服务器会分别建立TCP连接。所以从这个技术原理上来看，七层负载均衡明显的对负载均衡设备的要求更高，处理七层的能力也必然会低于四层模式的部署方式
实现七层负载均衡的方式：
- 软件：Nginx、Hayproxy等
- 四层和七层负载均衡的区别
四层负载均衡数据包是在底层就进行了分发，而七层负载均衡数据包则在最顶端进行分发，所以四层负载均衡的效率比七层负载均衡的要高。
四层负载均衡不识别域名，而七层负载均衡识别域名。
Nginx七层负载均衡
Nginx要实现七层负载均衡需要用到proxy_pass代理模块配置。Nginx默认安装支持这个模块，不需要再做任何处理。Nginx的负载均衡是在Nginx的反向代理基础上把用户的请求根据指定的算法分发到一组【upstream虚拟服务池】。
upstream指令
用来定义一组服务器，它们可以是监听不同端口的服务器，并且也可以是同时监听TCP和Unix socket的服务器。服务器可以指定不同的权重，默认为1。
| 语法 | upstream name {…} |
|---|---|
| 默认值 | — |
| 位置 | http |
server指令
用来指定后端服务器的名称和一些参数，可以使用域名、IP、端口或者unix socket
| 语法 | server name [paramerters] |
|---|---|
| 默认值 | — |
| 位置 | upstream |
负载均衡状态
代理服务器在负责均衡调度中的状态有以下几个：
| 状态 | 概述 |
|---|---|
| down | 当前的server暂时不参与负载均衡 |
| backup | 预留的备份服务器 |
| max_fails | 允许请求失败的次数 |
| fail_timeout | 经过max_fails失败后, 服务暂停时间 |
| max_conns | 限制最大的接收连接数 |
- down
将该服务器标记为永久不可用，那么该代理服务器将不参与负载均衡。
- backup
将该服务器标记为备份服务器，当主服务器不可用时，将用来传递请求
- max_fails
设置允许请求代理服务器失败的次数，默认为1。
- fail_timeout
设置经过max_fails失败后，服务暂停的时间，默认是10秒。
- max_conns
设置代理服务器同时活动链接的最大数量，默认为0，表示不限制，使用该配置可以根据后端服务器处理请求的并发量来进行设置，防止后端服务器被压垮。
负载均衡策略
| 算法名称 | 说明 |
|---|---|
| 轮询 | 默认方式 |
| weight | 权重方式 |
| ip_hash | 依据ip分配方式 |
| least_conn | 依据最少连接方式 |
| url_hash | 依据URL分配方式 |
| fair | 依据响应时间方式 |
- 轮询
是upstream模块负载均衡默认的策略。每个请求会按时间顺序逐个分配到不同的后端服务器。轮询不需要额外的配置
- weight
设置服务器的权重，默认为1，权重数据越大，被分配到请求的几率越大；该权重值，主要是针对实际工作环境中不同的后端服务器硬件配置进行调整的，所有此策略比较适合服务器的硬件配置差别比较大的情况
- ip_hash
能够将某个客户端IP的请求通过哈希算法定位到同一台后端服务器上。例如：当来自某一个IP的用户在后端Web服务器A上登录后，在访问该站点的其他URL，能保证其访问的还是后端web服务器A。
- 案例
ip_hash指令无法保证后端服务器的负载均衡，可能导致有些后端服务器接收到的请求多，有些后端服务器接收的请求少，而且设置后端服务器权重等方法将不起作用。
upstream backend{
ip_hash;
server 172.41.100.14:9001;
server 172.41.100.14:9002;
server 172.41.100.14:9003;
}
server {
listen 8083;
server_name localhost;
location /{
proxy_pass http://backend;
}
}
- least_conn
最少连接，把请求转发给连接数较少的后端服务器。轮询算法是把请求平均的转发给各个后端，使它们的负载大致相同；但是，有些请求占用的时间很长，会导致其所在的后端负载较高。这种情况下，least_conn这种方式就可以达到更好的负载均衡效果。
- 案例
upstream backend{
least_conn;
server 172.41.100.14:9001;
server 172.41.100.14:9002;
server 172.41.100.14:9003;
}
server {
listen 8083;
server_name localhost;
location /{
proxy_pass http://backend;
}
}
- url_hash
按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，要配合缓存命中来使用。同一个资源多次请求，可能会到达不同的服务器上，导致不必要的多次下载，缓存命中率不高，以及一些资源时间的浪费。而使用url_hash，可以使得同一个url（也就是同一个资源请求）会到达同一台服务器，一旦缓存住了资源，再此收到请求，就可以从缓存中读取
- 案例
upstream backend{
hash &request_uri;
server 172.41.100.14:9001;
server 172.41.100.14:9002;
server 172.41.100.14:9003;
}
server {
listen 8083;
server_name localhost;
location /{
proxy_pass http://backend;
}
}
- fair
fair采用的不是内建负载均衡使用的轮换的均衡算法，而是可以根据页面大小、加载时间长短智能的进行负载均衡。那么如何使用第三方模块的fair负载均衡策略。需要安装nginx-upstream-fair 模块
编译可能会出现如下错误，ngx_http_upstream_srv_conf_t结构中缺少default_port
- 解决方案:
在Nginx的源码中 src/http/ngx_http_upstream.h,找到ngx_http_upstream_srv_conf_s，在模块中添加添加default_port属性。
in_port_t default_port
Nginx四层负载均衡
Nginx在1.9之后，增加了一个stream模块，用来实现四层协议的转发、代理、负载均衡等。stream模块的用法跟http的用法类似，允许我们配置一组TCP或者UDP等协议的监听，然后通过proxy_pass来转发我们的请求，通过upstream添加多个后端服务，实现负载均衡。
Nginx四层负载均衡需要用到stream，默认Nginx没有安装该模块，需要手动安装即在编译的时候加上--with-stream
安装stream模块
stream模块的安装参考《Nginx基本概念》的Nginx热部署 或者《Nginx安全控制》使用SSL对流量进行加密 或者《Nginx静态资源压缩》的Gzip和sendfile共存
1. 将原有$NGINX_PATH/sbin/nginx进行备份
2. 拷贝nginx之前的配置信息
3. 在nginx的安装源码进行配置指定对应模块 ./configure --with-stream
4. 通过make模板进行编译
5. 将objs下面的nginx移动到/usr/local/nginx/sbin下
6. 在源码目录下执行 make upgrade进行升级，这个可以实现不停机添加新模块的功能
stream指令
提供在其中指定流服务器指令的配置文件上下文。和http指令同级。
| 语法 | stream { … } |
|---|---|
| 默认值 | — |
| 位置 | main |
upstream指令
与http的upstream指令是类似的。
七层负载均衡案例
七层负载均衡，Nginx充当的是代理服务器的作用，所有的客户端请求都是由Nginx代理处理的。例如TCP的连接，客户端与Nginx保持一套连接，Nginx与服务端保持一套连接
两台Nginx，172.41.100.15模拟代理服务器，172.41.100.14模拟服务端，172.41.100.14多个端口模拟不同的服务。
- 轮询负载均衡
upstream backend{
server 172.41.100.14:9001;
server 172.41.100.14:9002;
server 172.41.100.14:9003;
}
server {
listen 8083;
server_name localhost;
location /{
proxy_pass http://backend;
}
}
- 加权轮询负载均衡
upstream backend{
server 172.41.100.14:9001 weight=5;
server 172.41.100.14:9002 weight=15;
server 172.41.100.14:9003 weight=9;
}
server {
listen 8083;
server_name localhost;
location /{
proxy_pass http://backend;
}
}
- 对特定请求实现负载均衡
upstream song{
server 172.41.100.14:9001;
server 172.41.100.14:9002;
}
upstream hong{
server 172.41.100.14:9002 weight=15;
server 172.41.100.14:9003;
}
server {
listen 8084;
server_name localhost;
location ~^/song {
proxy_pass http://song;
}
location ~*^/hong {
proxy_pass http://hong;
}
}
- 对不同域名实现负载均衡
upstream song{
server 172.41.100.14:9001;
server 172.41.100.14:9002;
}
upstream hong{
server 172.41.100.14:9002 weight=15;
server 172.41.100.14:9003;
}
server {
listen 8084;
server_name www.song.com;
location ~^/ {
proxy_pass http://song;
}
}
server {
listen 8085;
server_name www.hong.com;
location ~^/ {
proxy_pass http://hong;
}
}
# /etc/hosts配置
127.0.0.1 www.song.com
127.0.0.1 www.hongwei.com
127.0.0.1 www.song.cn
127.0.0.1 abc.song.com
127.0.0.1 www.hongwei.cn
127.0.0.1 www.hong.com
- 带有URL重写的负载均衡
upstream backend{
server 172.41.100.14:9001 weight=5;
server 172.41.100.14:9002 weight=15;
server 172.41.100.14:9003 weight=9;
}
upstream hong{
server 172.41.100.14:9002 weight=15;
server 172.41.100.14:9003;
}
server {
error_log /home/error.log info;
rewrite_log on;
listen 8087;
server_name localhost;
location /song {
rewrite ^/song/(.*) /hong/$1 last;
}
location /hong {
proxy_pass http://backend;
}
location /hong/wei {
proxy_pass http://hong;
}
}
四层负载均衡案例
四层负载均衡实际上Nginx只相当于做了报文转发的作用，类似于路由器的路由选择和报文转发，实际上建立tcp连接的还是客户端和服务端。
使用Nginx转发redis请求，使用不同端口号的redis代替多redis服务器。
安装Redis
wget https://download.redis.io/releases/redis-6.2.5.tar.gz
tar -xvf redis-6.2.5.tar.gz
cd redis-6.2.5/
make
make PREFIX=/home/redis install
启动Redis
分别在3台redis上存储同一个key，但是value值不一致。
例如：6379端口的存
key：songhongwei value：6379
6378端口的存
key：songhongwei value：6378
6377端口的存
key：songhongwei value：6377
配置Nginx
stream {
upstream redis {
server 172.41.100.14:6379;
server 172.41.100.14:6378;
}
upstream redis2 {
server 172.41.100.14:6377;
}
server {
listen 8089;
proxy_pass redis;
}
server {
listen 8099;
proxy_pass redis2;
}
}
使用redis客户端访问8089和8099端口
扫一扫
3万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
