亿级流量--------负载均衡与反向代理

一，nginx 负载均衡配置

1，upstream模块配置上有服务器

修改配置文件，vi nginx.conf 内容如下：

#user  nobody;
worker_processes  1;

#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;

#pid        logs/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       mime.types;
    default_type  application/octet-stream;

    #log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
    #                  '$status $body_bytes_sent "$http_referer" '
    #                  '"$http_user_agent" "$http_x_forwarded_for"';

    #access_log  logs/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;

    #gzip  on;
upstream epass-api {
        server 127.0.0.1:8081;
        server 127.0.0.1:8082;
        server 127.0.0.1:8083;
    }

    server {
        listen 80;
        server_name  epass-api;   
        location / {
            proxy_pass http://epass-api;
        }
    }

}

配置后启动nginx，打开浏览器，访问：http://127.0.0.1/epass-api/,效果如下：

2，负载均衡算法

负载均衡算法用来处理当用户的请求到来时如何选择后端的上游服务器进行服务，默认采用的是轮询（round-robin）,同时还有其他几种算法，供不同的场景使用

1，round-robin:轮询，默认的负载均衡算法，即以轮询的方式将请求转发到上游服务器，通过配合weight配置可以实现基于权重的轮询。

2，ip_hash:根据客户端ip进行负载均衡，即相同的ip负载均衡到相同的upstream server:

    upstream epass-api {
        ip_hash;
        server 127.0.0.1:8081 weight=1;
        server 127.0.0.1:8082 weight=2;
        server 127.0.0.1:8083 weight=2;
}

3,hash key [consistent] :对于某一key进行hash或者一致性hash进行负载均衡，使用hash key的问题是当添加或删除一台服务器的时候会导致很多key重新负载均衡到不同的服务器（从而导致后端可能会出现问题）；因此建议使用一致性hash算法进行负载均衡，这样当添加/删除一台服务器是只有少量key会重新负载均衡到不同的服务器

3.1hash算法,如更具uri进行hash,可以使用nginx的变量，如：

upstream epass-api {
        hash $uri;
        server 127.0.0.1:8081 weight=1;
        server 127.0.0.1:8082 weight=2;
        server 127.0.0.1:8083 weight=2;
    }

3.2一致性hash:consistent_key动态指定

    upstream epass-api {
        hash $consistent_key consistent;
        server 127.0.0.1:8081 weight=1;
        server 127.0.0.1:8082 weight=2;
        server 127.0.0.1:8083 weight=2;
    }

如上配置，还需要在location节点下设置一致性hash key,此次优先考虑请求参数cat,如果没有则再更具uri进行一致性hash如：

    location / {
        set $consistent_key $arg_cat;
        if($consistent_key=""){
            set $consistent_key $uri;
        }
    }

还可以使用lua脚本来设置一致性hash key

3.3 least_conn:将请求负载均衡到最少活跃连接的上游服务器。nginx商业版还提供least_time的策略，即基于最小平均响应时间来进行负载均衡

3，失败重试

主要配置有upstream server和proxy_pass
upstream epass-api {
    hash $uri;
    server 127.0.0.1:8081  max_fails = 2 fail_timeout=10s weight=1;
    server 127.0.0.1:8082 max_fails = 2 fail_timeout=10s weight=2;
    server 127.0.0.1:8083 max_fails = 2 fail_timeout=10s weight=2;
}

##4，健康检查
nginx_upstream_check_module支持基于tcp心跳和http心跳的健康检查

5，其他配置

1. 域名上游服务器
2. 备份上游服务器
3. 不可用上游服务器
4. 长连接

二，动态负载均衡

对于如上的负载均衡实现中，，每次upstream有变动时，都需要到服务器进行修改，非常不方便，而且对于upstream服务上线无法自动注册发哦nginx的服务列表中，因此，我们需要一种服务可以将upstream 动态注册到nginx服务列表，从而实现upstream服务的自动发现。
consul是一款开运的分布式服务注册于发现系统，通过http api可以使得服务注册发现非常方便，支持如下特性：
1，服务注册
2，服务发现
3，故障检测
4，k/v存储
5，多数据中心
6，Raft算法

利用consul实现的服务注册于发现架构图如下：

最好使用springboot+Consul java client实现服务的注册于发现，并在服务停止是自动摘除服务。

对于这种方式的服务发现与摘除在服务发生变化是需要reload,如果能够不reload就能进行服务注册于摘除就完美了，答案就长连接

三，nginx四层负载均衡

nginx 1.9.0版本起支持四层负载均衡，从而使得nginx变得更加强大。目前，四层负载均衡器用的比较多的是HaProxy;而nginx也支持四层负载均衡，一般场景下使用nginx就够了(实际工作中还是haproxy用的比较多)

3.1静态负载均衡

3.2 使用nginx-strem-upsync-module实现动态负载均衡