项目背景:
链路流程: vip —>nginx—>upstream—>server—>ip+port
1.目前还没做路由功能,分组是按服务器分组(不是按用户分组),分组发布过程一个队列形式,这里提供自定义规则切换服upstrem。
2.不管是全量发布,分组发布,快速发布,lb只做一件事:切换upstream(running_upstream与standy_upstream
3.动态切换LB,做法两种,一是直接操作upstream,二是操作upstream里的server.
4.与ci集成方式:超链接web
方案一:模块fly操作upstream,web方式增删查改upsterem里的server
无drop重启nginx
kill -HUP `cat /data/nginx/logs/nginx.pid`
#!/bin/sh
BASE_DIR='/usr/local/'
${BASE_DIR}nginx/sbin/nginx -t -c ${BASE_DIR}nginx/conf/nginx.
conf >& ${BASE_DIR}nginx/logs/nginx.start
conf >& ${BASE_DIR}nginx/logs/nginx.start
info=`cat ${BASE_DIR}nginx/logs/nginx.start`
if [ `echo $info | grep -c "syntax is ok" ` -eq 1 ]; then
if [ `ps aux|grep "nginx"|grep -c "master"` == 1 ]; then
kill -HUP `cat ${BASE_DIR}nginx/logs/nginx.pid`
echo "ok"
else
killall -9 nginx
sleep 1
${BASE_DIR}nginx/sbin/nginx
fi
else
echo "######## error: ########"
cat ${BASE_DIR}nginx/logs/nginx.start
方案二:模块ngx_dynamic_upstream,api+python方式(直接操作upstream里的server)
因为api接口操作不是太直观,在django上以web方式增删查改upstream
HTTP APIs
You can operate upstreams dynamically with HTTP APIs.
list
$ curl "http://127.0.0.1:6000/dynamic?upstream=zone_for_backends" server 127.0.0.1:6001; server 127.0.0.1:6002; server 127.0.0.1:6003; $
verbose
$ curl "http://127.0.0.1:6000/dynamic?upstream=zone_for_backends&verbose=" server 127.0.0.1:6001 weight=1 max_fails=1 fail_timeout=10; server 127.0.0.1:6002 weight=1 max_fails=1 fail_timeout=10; server 127.0.0.1:6003 weight=1 max_fails=1 fail_timeout=10; $
update_parameters
$ curl "http://127.0.0.1:6000/dynamic?upstream=zone_for_backends&server=127.0.0.1:6003&weight=10&max_fails=5&fail_timeout=5" server 127.0.0.1:6001 weight=1 max_fails=1 fail_timeout=10; server 127.0.0.1:6002 weight=1 max_fails=1 fail_timeout=10; server 127.0.0.1:6003 weight=10 max_fails=5 fail_timeout=5; $
The supported parameters are blow.
- weight
- max_fails
- fail_timeout
down
$ curl "http://127.0.0.1:6000/dynamic?upstream=zone_for_backends&server=127.0.0.1:6003&down=" server 127.0.0.1:6001 weight=1 max_fails=1 fail_timeout=10; server 127.0.0.1:6002 weight=1 max_fails=1 fail_timeout=10; server 127.0.0.1:6003 weight=1 max_fails=1 fail_timeout=10 down; $
up
$ curl "http://127.0.0.1:6000/dynamic?upstream=zone_for_backends&server=127.0.0.1:6003&up=" server 127.0.0.1:6001 weight=1 max_fails=1 fail_timeout=10; server 127.0.0.1:6002 weight=1 max_fails=1 fail_timeout=10; server 127.0.0.1:6003 weight=1 max_fails=1 fail_timeout=10; $
add
$ curl "http://127.0.0.1:6000/dynamic?upstream=zone_for_backends&add=&server=127.0.0.1:6004" server 127.0.0.1:6001; server 127.0.0.1:6002; server 127.0.0.1:6003; server 127.0.0.1:6004; $
remove
$ curl "http://127.0.0.1:6000/dynamic?upstream=zone_for_backends&remove=&server=127.0.0.1:6003"
server 127.0.0.1:6001;
server 127.0.0.1:6002;
server 127.0.0.1:6004;
server 127.0.0.1:6001;
server 127.0.0.1:6002;
server 127.0.0.1:6004;
reference:
方案三:lua(lua_code_cache)热装载+upstream ,直接操作upstream
简说热装载(热加载) :lua代码产生变更,利用lua_code_cache on ,实现自动加载,不用reload nginx。
亮点: 通过lua处理,不用重启nginx,利用api进行增删查改
不足:操作还是基于命令方式,后期还得加上web操作
restful interface
GET
-
/detail
get all upstreams and their servers -
/list
get the list of upstreams -
/upstream/name
find the upstream by it's name
POST
-
/upstream/name
update one upstream -
body
commands; -
body
server ip:port;
DELETE
-
/upstream/name
delete one upstream
Call the interface, when you get the return code is HTTP_INTERNAL_SERVER_ERROR 500
, you need to reload nginx to make the Nginx work at a good state.
If you got HTTP_CONFLICT 409
, you need resend the same commands again latter.
The /list and /detail interface will return HTTP_NO_CONTENT 204
when there is no upstream.
Other code means you should modify your commands and call the interface again.
ATTENEION
: You also need a third-party
to generate the new config and dump it to Nginx'conf directory.
Sample
» curl -H "host: dyhost" 127.0.0.1:8080 <html> <head><title>502 Bad Gateway</title></head> <body bgcolor="white"> <center><h1>502 Bad Gateway</h1></center> <hr><center>nginx/1.3.13</center> </body> </html> » curl -d "server 127.0.0.1:8089;server 127.0.0.1:8088;" 127.0.0.1:8081/upstream/dyhost success » curl -H "host: dyhost" 127.0.0.1:8080 8089 » curl -H "host: dyhost" 127.0.0.1:8080 8088 » curl 127.0.0.1:8081/detail host1 server 127.0.0.1:8088 host2 server 127.0.0.1:8089 dyhost server 127.0.0.1:8089 server 127.0.0.1:8088 » curl -i -X DELETE 127.0.0.1:8081/upstream/dyhost success » curl 127.0.0.1:8081/detail host1 server 127.0.0.1:8088 host2 server 127.0.0.1:8089
API
extern ngx_flag_t ngx_http_dyups_api_enable; ngx_int_t ngx_dyups_update_upstream(ngx_str_t *name, ngx_buf_t *buf, ngx_str_t *rv); ngx_int_t ngx_dyups_delete_upstream(ngx_str_t *name, ngx_str_t *rv); extern ngx_dyups_add_upstream_filter_pt ngx_dyups_add_upstream_top_filter; extern ngx_dyups_del_upstream_filter_pt ngx_dyups_del_upstream_top_filter;
Lua API Example
NOTICE: you should add the directive dyups_interface
into your config file to active this feature
content_by_lua '
local dyups = require "ngx.dyups"
local status, rv = dyups.update("test", [[server 127.0.0.1:8088;]]);
ngx.print(status, rv)
if status ~= ngx.HTTP_OK then
ngx.print(status, rv)
return
end
ngx.print("update success")
status, rv = dyups.delete("test")
if status ~= ngx.HTTP_OK then
ngx.print(status, rv)
return
end
ngx.print("delete success")
local dyups = require "ngx.dyups"
local status, rv = dyups.update("test", [[server 127.0.0.1:8088;]]);
ngx.print(status, rv)
if status ~= ngx.HTTP_OK then
ngx.print(status, rv)
return
end
ngx.print("update success")
status, rv = dyups.delete("test")
if status ~= ngx.HTTP_OK then
ngx.print(status, rv)
return
end
ngx.print("delete success")
';
reference:
方案四:自研
自已写lua+redis,再封装一层api,供业务插入标签,再进行增删查改
相关推荐
**Nginx配置Upstream负载均衡详解** 在现代Web服务架构中,负载均衡是一项至关重要的技术,它能够有效地分散...通过合理的配置和运维,Nginx的Upstream功能能够为各种规模的Web服务提供高效、可靠的负载均衡解决方案。
"nginx-upstream-jvm-route-1.15"项目很可能提供了解决这个问题的解决方案,可能包括修改Nginx配置模板、添加特定的模块或者提供一种新的路由策略。 在提供的压缩包文件"nginx-upstream-jvm-route-master"中,可能...
"nginx-upstream-fair-master.zip"是一个包含Nginx公平负载均衡(fair)第三方模块的压缩包,该模块使得Nginx可以根据服务器的实际响应时间来分配请求,从而实现更公平的负载均衡策略。 公平负载均衡(fair)模块...
官方nginx 镜像不带主动健康,本镜像将 nginx_upstream_check健康检查 打包到了镜像中。
此资源有两个文件,含 nginx-upstream-jvm-route 和 nginx 对应版本,都是tar.gz文件。 安装方法网上很多就不写了,亲测可用。 不用担心版本不匹配造成安装失败,再浪费积分去到处下载尝试的烦恼。 此资源有两个文件...
Nginx实现负载均衡 web均衡负载 webservice负载均衡 Nginx实现负载均衡配制全说明 为了多台后台的web、webservice服务能均衡负载,可以使用nginx进行处理 1)配置文件全配制ok 2)有两个完整的web服务做例子,可以...
基于lua的nginx自定义负载均衡基于lua的nginx自定义负载均衡
动态管理nginx负载均衡.zip动态管理nginx负载均衡.zip动态管理nginx负载均衡.zip动态管理nginx负载均衡.zip动态管理nginx负载均衡.zip动态管理nginx负载均衡.zip动态管理nginx负载均衡.zip动态管理nginx负载均衡.zip...
**Nginx Upstream Check Module** 是一个由淘宝团队开发的插件,专门用于Nginx服务器,旨在增强其反向代理功能,提供对后端服务器节点的健康检查。这个模块使得运维人员能够实时监控后端服务器的状态,确保在将请求...
Nginx 支持多种负载均衡算法,其中之一就是 **Fair**(公平)调度算法。此算法的主要优势在于它可以更智能地将请求分配给后端服务器,避免了传统轮询(Round Robin, RR)方法可能导致的部分服务器过载的问题。 ####...
为了实现更灵活的负载均衡策略,Nginx提供了一系列的upstream模块,其中,`nginx_upstream_hash`模块是其中的一种,用于根据请求的某些参数进行哈希计算,进而将请求定向到特定的后端服务器。本文将深入探讨`nginx_...
nginx经常用到的负载均衡的5种策略,注意细节,部分属性不能一起使用。
这些模块内嵌于nginx之中,提供了核心的代理和负载均衡功能。通过配置文件nginx.conf中的upstream指令块,用户可以定义服务器组和权重,使得nginx根据相应的算法将客户端请求均衡地分配到各个服务器上。 在传统的...
在 Nginx 的配置文件中,我们需要定义一个 upstream 模块来指定后端服务器列表,并选择合适的负载均衡策略。例如: ```nginx upstream backend { server backend1.example.com weight=3; server backend2.example...
### Nginx安装与后端健康检查模块配置详解 #### 一、Nginx环境搭建与核心组件安装 **1.1 基础环境准备** - **操作系统**: CentOS 6.5 - **基本服务器配置**: 在安装过程中选择了“基本服务器”配置。 **1.2 安装...
为了满足动态负载均衡的需求,nginx提供了丰富的upstream模块,其中,nginx_upstream_hash模块是其一,它允许我们基于特定的请求参数来分配请求到不同的后端服务器,实现更为灵活的负载策略。本文将详细介绍nginx_...
其中,Nginx的负载均衡功能是其核心特性之一,它能够有效地在多台服务器之间分发网络请求,提高系统的可用性和响应速度,实现高并发场景下的应用服务集群。 **负载均衡的基本概念** 1. **服务器集群**:将多台...
四、Nginx+Tomcat 实现负载均衡 要实现负载均衡,需要在 Nginx 服务器上配置 upstream 模块,以便将请求分配到多台 Tomcat 服务器上。具体配置如下: 1. upstream netitcast.com { server 127.0.0.1:18080 weight...