記一次nginx中proxy_pass的使用問(wèn)題
最近排查一個(gè)web服務(wù)的問(wèn)題,webserver使用的nginx,最終發(fā)現(xiàn)是踩了nginx中proxy_pass的一個(gè)坑,這里記錄下來(lái)。
踩坑經(jīng)過(guò)
一個(gè)線上的http服務(wù),示例nginx關(guān)鍵配置如下:
server { listen 80; server_name ligang.gdemo.com; server_tokens off; keepalive_timeout 5; charset utf-8; include /home/ligang/devspace/gobox-demo/conf/http/general/gzip.conf; access_log logs/ligang.gdemo.com.log combinedio buffer=1k; error_log logs/ligang.gdemo.com.log.err; location / { include /home/ligang/devspace/gobox-demo/conf/http/general/http_proxy.conf; proxy_intercept_errors on; proxy_pass http://ligang.proxy.gdemo.com; } }
這里可以看到,請(qǐng)求 ligang.gdemo.com
時(shí),nginx把請(qǐng)求反向代理到 ligang.proxy.gdemo.com 去做處理。
ligang.proxy.gdemo.com
這個(gè)服務(wù)在線上部署并解析到了A、B、C這3個(gè)機(jī)房,現(xiàn)在我想調(diào)整解析,去掉C機(jī)房,僅留A、B兩個(gè)機(jī)房。
調(diào)整解析后,查看新的解析已經(jīng)生效,但觀察C機(jī)房的請(qǐng)求量,發(fā)現(xiàn)和之前一樣,沒(méi)有任何變化。
于是我觀察C機(jī)房的nginx的log,發(fā)現(xiàn)請(qǐng)求來(lái)源還是 ligang.gdemo.com
的機(jī)器,域名解析調(diào)整后nginx那邊依舊使用之前的IP。
于是我將 ligang.gdemo.com
的機(jī)器上的nginx全部reload后,C機(jī)房的請(qǐng)求終于沒(méi)有了。
問(wèn)題說(shuō)明
上面的問(wèn)題,說(shuō)明在nginx的proxy_pass中如果使用了域名,那么nginx會(huì)把解析的結(jié)果緩存下來(lái),貌似不會(huì)更新,因?yàn)樯厦娴睦又?,我調(diào)整解析后是幾乎是隔了一天去看C機(jī)房的log發(fā)現(xiàn)流量沒(méi)有任何變化的。
這樣的話,如果你配置一個(gè)反向代理服務(wù)器,如果上游調(diào)整了域名,而你又沒(méi)有得到通知,那么你的代理服務(wù)相當(dāng)于不可用了。
從代碼中看下nginx是如何解析主機(jī)ip的
有點(diǎn)好奇nginx是如何解析主機(jī)ip的,所以追蹤下代碼:
proxy_pass指令定義的地方(http/modules/ngx_http_proxy_module.c):
{ ngx_string("proxy_pass"), NGX_HTTP_LOC_CONF|NGX_HTTP_LIF_CONF|NGX_HTTP_LMT_CONF|NGX_CONF_TAKE1, ngx_http_proxy_pass, //處理方法 NGX_HTTP_LOC_CONF_OFFSET, 0, NULL },
ngx_http_proxy_pass方法(http/modules/ngx_http_proxy_module.c):
static char * ngx_http_proxy_pass(ngx_conf_t *cf, ngx_command_t *cmd, void *conf) { ngx_http_proxy_loc_conf_t *plcf = conf; size_t add; u_short port; ngx_str_t *value, *url; ngx_url_t u; ngx_uint_t n; ngx_http_core_loc_conf_t *clcf; ngx_http_script_compile_t sc; ...... url = &value[1]; ...... ngx_memzero(&u, sizeof(ngx_url_t)); u.url.len = url->len - add; u.url.data = url->data + add; u.default_port = port; u.uri_part = 1; u.no_resolve = 1; plcf->upstream.upstream = ngx_http_upstream_add(cf, &u, 0); }
這里繼續(xù)追蹤ngx_http_upstream_add方法(http/ngx_http_upstream.c):
ngx_http_upstream_srv_conf_t * ngx_http_upstream_add(ngx_conf_t *cf, ngx_url_t *u, ngx_uint_t flags) { ngx_uint_t i; ngx_http_upstream_server_t *us; ngx_http_upstream_srv_conf_t *uscf, **uscfp; ngx_http_upstream_main_conf_t *umcf; if (!(flags & NGX_HTTP_UPSTREAM_CREATE)) { if (ngx_parse_url(cf->pool, u) != NGX_OK) { if (u->err) { ngx_conf_log_error(NGX_LOG_EMERG, cf, 0, "%s in upstream \"%V\"", u->err, &u->url); }
繼續(xù)追蹤ngx_parse_url方法(core/ngx_inet.c):
ngx_int_t ngx_parse_url(ngx_pool_t *pool, ngx_url_t *u) { u_char *p; p = u->url.data; if (ngx_strncasecmp(p, (u_char *) "unix:", 5) == 0) { return ngx_parse_unix_domain_url(pool, u); } if (p[0] == '[') { return ngx_parse_inet6_url(pool, u); } return ngx_parse_inet_url(pool, u); }
然后是ngx_parse_inet_url方法(core/ngx_inet.c):
static ngx_int_t ngx_parse_inet_url(ngx_pool_t *pool, ngx_url_t *u) { ...... if (ngx_inet_resolve_host(pool, u) != NGX_OK) { return NGX_ERROR; } ...... }
然后是ngx_inet_resolve_host方法(core/ngx_inet.c):
#if (NGX_HAVE_GETADDRINFO && NGX_HAVE_INET6) ngx_int_t ngx_inet_resolve_host(ngx_pool_t *pool, ngx_url_t *u) { ...... if (getaddrinfo((char *) host, NULL, &hints, &res) != 0) { u->err = "host not found"; ngx_free(host); return NGX_ERROR; } ...... } #else /* !NGX_HAVE_GETADDRINFO || !NGX_HAVE_INET6 */ ngx_int_t ngx_inet_resolve_host(ngx_pool_t *pool, ngx_url_t *u) { ...... h = gethostbyname((char *) host); ...... }
思考下如何解決這個(gè)問(wèn)題
最簡(jiǎn)單的解決方法,我想到如下幾種:
執(zhí)行 nginx reload
這種方法優(yōu)缺點(diǎn)都很明顯:
優(yōu)點(diǎn):操作簡(jiǎn)單。
缺點(diǎn):屬于我們常說(shuō)的后手,需要做好監(jiān)控。
配置resolver
可以通過(guò)在nginx中配置resolver來(lái)動(dòng)態(tài)更新解析,大致做法如下:
server { listen 80; server_name ligang.gdemo.com; resolver 8.8.8.8 valid=60s; resolver_timeout 3s; set $gproxy "ligang.proxy.gdemo.com"; location / { proxy_pass http://$gproxy; } }
這個(gè)方法優(yōu)缺點(diǎn)如下:
優(yōu)點(diǎn):解析地址每隔一段時(shí)間自動(dòng)更新,無(wú)需人工做 nginx reload 。
缺點(diǎn):需要指定DNS服務(wù)器地址,如果這個(gè)服務(wù)器掛了,或是地址變了,則需要修改nginx配置后reload。
結(jié)束語(yǔ)
上面這兩個(gè)方法是無(wú)須額外開發(fā),直接簡(jiǎn)單可用的,成本上比較低,但都有不完美的地方。
這里我想到是否可以自行開發(fā)一個(gè)nginx擴(kuò)展,用來(lái)動(dòng)態(tài)更新從DNS獲取的IP地址,這樣就能解決這個(gè)問(wèn)題了,但有一定的開發(fā)成本,但個(gè)人覺(jué)得對(duì)提升技術(shù)能力又很有價(jià)值。
如果大家有什么好方法,也歡迎來(lái)一起討論。以上就是本文的全部?jī)?nèi)容,希望對(duì)大家的學(xué)習(xí)有所幫助,也希望大家多多支持腳本之家。
相關(guān)文章
在Nginx服務(wù)器上配置Google反向代理的基本方法
這篇文章主要介紹了在Nginx服務(wù)器上配置Google反向代理的基本方法,文中使用到了SSL來(lái)加密反向代理,需要的朋友可以參考下2015-12-12lnmp環(huán)境中如何為nginx開啟pathinfo
這篇文章主要介紹了lnmp環(huán)境中如何為nginx開啟pathinfo的方法,操作很簡(jiǎn)單,需要的朋友可以參考下2015-01-01Nginx配置WebSocket反向代理的實(shí)現(xiàn)示例
本文主要介紹了Nginx配置WebSocket反向代理的實(shí)現(xiàn)示例,文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧2023-08-08nginx配置gzip壓縮優(yōu)化傳輸效率加快頁(yè)面訪問(wèn)速度的問(wèn)題
本文介紹了如何在nginx服務(wù)器中配置gzip壓縮,通過(guò)壓縮HTTP響應(yīng)內(nèi)容,減少數(shù)據(jù)傳輸大小和響應(yīng)時(shí)間,從而提升網(wǎng)站性能和訪問(wèn)速度,感興趣的朋友跟隨小編一起看看吧2024-09-09詳解NGINX如何統(tǒng)計(jì)網(wǎng)站的PV、UV、獨(dú)立IP
做網(wǎng)站的都知道,平常經(jīng)常要查詢下網(wǎng)站PV、UV等網(wǎng)站的訪問(wèn)數(shù)據(jù),這篇文章主要介紹了詳解NGINX如何統(tǒng)計(jì)網(wǎng)站的PV、UV、獨(dú)立IP ,具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2019-05-05如何配置Nginx每個(gè)進(jìn)程最多打開的文件數(shù)量
這篇文章主要介紹了配置Nginx每個(gè)進(jìn)程最多打開的文件數(shù)量,本文通過(guò)實(shí)例代碼給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2020-06-06