docker动态更新lb

第一种DNS方案

容器里面通过向DNS做注册,然后nginx 里面配置upstream的时候写上域名,然后在添加nginx的resolver 来自动解析pass的域名,pass的域名通过dns轮训.
Example:
Nginx 代理配置
Upstream www {
Server www.michael.com;
}
Proxy_pass http://www;
启动2个www的后端服务,比如ip是1.1.1.1和1.1.1.2 那么dns里面解析

1.1.1.1 www.michael.com.
1.1.1.2 www.michael.com.

类似上面这种格式,第一次解析www.michael.com 解析的为1.1.1.1,第二次解析www.michael.com 为1.1.1.2,轮训解析

优点: 简单方便,容易配置,容错性强,
缺点: 实时性比较差,dns的压力随并发的增加而增加

第二种方案API 动态upstream调整

ngx_http_dyups_module
ngx_dynamic_upstream
以上两种模块实现了动态upstream,dyups测试未通过dynamic需要nginx1.9以上版本才支持,不支持tengine,因为tengine版本的不是最新版本的nginx分支,没有zone变量.
优点:可以通过api去注册删除服务,简单方便易操作
缺点:文件没有持久化,当restart后upstream丢失(开源可二次开发)
Dynamic测试案例:

第三种通过配置管理实现

方式一,consul+consul-template
方式二,(consul/etcd)+ nginx-upsync-module
上面两种方式,存在使用案例
方式三,直接封装在java代码里面,通过服务启动向zookeeper注册临时节点,并维护一个长连接,当服务down后,zookeeper自动删除此节点,然后前段lb根据zookeeper里面的去消费.(研发力量)
前两种方式都是通过配置管理,docker容器,通过api或者consul agent来向consul注册,申明自己的服务,ip和端口,然后consul-template或者upsync来通过consul来进行获取信息来进行lb的更新.
Consul-template 需要reload,reload操作会造成CPU瞬时暴增,大量连接retry,work进行新旧替换,支持haproxy lvs nginx
Upsync 定时去拉配置文件,进行配置文件的持久化,不需要reload nginx. 为nginx的一个模块,其他的lb产品需要自研或者开源产品