第一種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產品需要自研或者開源產品