概述

系统的扩展可以分为纵向扩展和横向扩展。

  • 纵向扩展是从单机的角度出发,通过增加系统的硬件处理能力来提升服务器的处理能力
  • 横向扩展是通过添加机器来满足大型网站服务的处理能力。

image.png
这里面涉及到两个重要的角色分别是”应用集群”和”负载均衡器”。

  • 应用集群:将同一应用部署到多台机器上,组成处理集群,接收负载均衡设备分发的请求,进行处理并返回响应的数据。
  • 负载均衡器:将用户访问的请求根据对应的负载均衡算法,分发到集群中的一台服务器进行处理。
  • 负载均衡的优势
    1. 解决服务器的高并发压力,提高应用程序的处理性能。
    2. 提供故障转移,实现高可用。
    3. 通过添加或减少服务器数量,增强网站的可扩展性。
    4. 在负载均衡器上进行过滤,可以提高系统的安全性。
  • 负载均衡的方式
  1. 用户手动选择

在网站主页上面提供不同线路、不同服务器链接方式,让用户来选择自己访问的具体服务器,来实现负载均衡。
image.png

  1. 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指令无法保证后端服务器的负载均衡,可能导致有些后端服务器接收到的请求多,有些后端服务器接收的请求少,而且设置后端服务器权重等方法将不起作用。

    1. upstream backend{
    2. ip_hash;
    3. server 172.41.100.14:9001;
    4. server 172.41.100.14:9002;
    5. server 172.41.100.14:9003;
    6. }
    7. server {
    8. listen 8083;
    9. server_name localhost;
    10. location /{
    11. proxy_pass http://backend;
    12. }
    13. }
  • least_conn

最少连接,把请求转发给连接数较少的后端服务器。轮询算法是把请求平均的转发给各个后端,使它们的负载大致相同;但是,有些请求占用的时间很长,会导致其所在的后端负载较高。这种情况下,least_conn这种方式就可以达到更好的负载均衡效果。

  • 案例
    1. upstream backend{
    2. least_conn;
    3. server 172.41.100.14:9001;
    4. server 172.41.100.14:9002;
    5. server 172.41.100.14:9003;
    6. }
    7. server {
    8. listen 8083;
    9. server_name localhost;
    10. location /{
    11. proxy_pass http://backend;
    12. }
    13. }
  • url_hash

按访问url的hash结果来分配请求,使每个url定向到同一个后端服务器,要配合缓存命中来使用。同一个资源多次请求,可能会到达不同的服务器上,导致不必要的多次下载,缓存命中率不高,以及一些资源时间的浪费。而使用url_hash,可以使得同一个url(也就是同一个资源请求)会到达同一台服务器,一旦缓存住了资源,再此收到请求,就可以从缓存中读取

  • 案例
    1. upstream backend{
    2. hash &request_uri;
    3. server 172.41.100.14:9001;
    4. server 172.41.100.14:9002;
    5. server 172.41.100.14:9003;
    6. }
    7. server {
    8. listen 8083;
    9. server_name localhost;
    10. location /{
    11. proxy_pass http://backend;
    12. }
    13. }
  • 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. 1. 将原有$NGINX_PATH/sbin/nginx进行备份
  2. 2. 拷贝nginx之前的配置信息
  3. 3. nginx的安装源码进行配置指定对应模块 ./configure --with-stream
  4. 4. 通过make模板进行编译
  5. 5. objs下面的nginx移动到/usr/local/nginx/sbin
  6. 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多个端口模拟不同的服务。

  • 轮询负载均衡

    1. upstream backend{
    2. server 172.41.100.14:9001;
    3. server 172.41.100.14:9002;
    4. server 172.41.100.14:9003;
    5. }
    6. server {
    7. listen 8083;
    8. server_name localhost;
    9. location /{
    10. proxy_pass http://backend;
    11. }
    12. }
  • 加权轮询负载均衡 ```nginx

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; } }

  1. - **对特定请求实现负载均衡**
  2. ```nginx
  3. upstream song{
  4. server 172.41.100.14:9001;
  5. server 172.41.100.14:9002;
  6. }
  7. upstream hong{
  8. server 172.41.100.14:9002 weight=15;
  9. server 172.41.100.14:9003;
  10. }
  11. server {
  12. listen 8084;
  13. server_name localhost;
  14. location ~^/song {
  15. proxy_pass http://song;
  16. }
  17. location ~*^/hong {
  18. proxy_pass http://hong;
  19. }
  20. }
  • 对不同域名实现负载均衡 ```nginx 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

  1. - **带有URL重写的负载均衡**
  2. ```nginx
  3. upstream backend{
  4. server 172.41.100.14:9001 weight=5;
  5. server 172.41.100.14:9002 weight=15;
  6. server 172.41.100.14:9003 weight=9;
  7. }
  8. upstream hong{
  9. server 172.41.100.14:9002 weight=15;
  10. server 172.41.100.14:9003;
  11. }
  12. server {
  13. error_log /home/error.log info;
  14. rewrite_log on;
  15. listen 8087;
  16. server_name localhost;
  17. location /song {
  18. rewrite ^/song/(.*) /hong/$1 last;
  19. }
  20. location /hong {
  21. proxy_pass http://backend;
  22. }
  23. location /hong/wei {
  24. proxy_pass http://hong;
  25. }
  26. }

四层负载均衡案例

四层负载均衡实际上Nginx只相当于做了报文转发的作用,类似于路由器的路由选择和报文转发,实际上建立tcp连接的还是客户端和服务端。
使用Nginx转发redis请求,使用不同端口号的redis代替多redis服务器。

image.png

安装Redis

  1. wget https://download.redis.io/releases/redis-6.2.5.tar.gz
  2. tar -xvf redis-6.2.5.tar.gz
  3. cd redis-6.2.5/
  4. make
  5. make PREFIX=/home/redis install

启动Redis

image.png
分别在3台redis上存储同一个key,但是value值不一致。
例如:6379端口的存
key:songhongwei value:6379
6378端口的存
key:songhongwei value:6378
6377端口的存
key:songhongwei value:6377
image.png

配置Nginx

  1. stream {
  2. upstream redis {
  3. server 172.41.100.14:6379;
  4. server 172.41.100.14:6378;
  5. }
  6. upstream redis2 {
  7. server 172.41.100.14:6377;
  8. }
  9. server {
  10. listen 8089;
  11. proxy_pass redis;
  12. }
  13. server {
  14. listen 8099;
  15. proxy_pass redis2;
  16. }
  17. }

使用redis客户端访问8089和8099端口
image.png