http://scyuan.info/2016/03/07/openresty-cdn-original.html

年前粗略看了一下《OpenResty最佳實(shí)踐》，感覺(jué)OpenResty是個(gè)好東西呀，但是一下子又找不到使用場(chǎng)景，所以就放到一邊了。最近遇到一個(gè)需求，感覺(jué)用OpenResty正合適，所以終于在生產(chǎn)環(huán)境實(shí)踐了一把。

需求

一個(gè)javaScript腳本分發(fā)服務(wù)：

        key瀏覽器 --------------> 分發(fā)服務(wù)GET /js?key=xxxx        302 CDN地址瀏覽器 <-------------- 分發(fā)服務(wù)Location: cdn.x.com/digest/xxxx.js//分發(fā)服務(wù)根據(jù)key獲取用戶的配置（用戶可以通過(guò)web界面修改，需要盡快生效）//以及配置對(duì)應(yīng)的靜態(tài)js文件（分布在分發(fā)服務(wù)的本地硬盤），//計(jì)算配置和靜態(tài)內(nèi)容的摘要，拼接到CDN的URL中，//當(dāng)配置或靜態(tài)內(nèi)容更新后，重定向新的URL，CDN將觸發(fā)回源流程。        CDN地址              回源瀏覽器 --------------> CDN --------------> 分發(fā)服務(wù)
由于該服務(wù)的請(qǐng)求量還是挺大的（每天的重定向請(qǐng)求量在七百六十萬(wàn)左右，回源請(qǐng)求量在八萬(wàn)左右），所以部署了兩個(gè)分發(fā)服務(wù)，前面擋了一個(gè)Nginx做負(fù)載均衡。
本來(lái)做Nginx是為了容錯(cuò)，結(jié)果就因?yàn)檫@個(gè)還帶來(lái)了一個(gè)小問(wèn)題：
由于兩臺(tái)分發(fā)服務(wù)的配置更新存在時(shí)間差，特別是靜態(tài)文件，所以設(shè)想一下，服務(wù)A配置已經(jīng)更新，而服務(wù)B沒(méi)有更新，一個(gè)請(qǐng)求來(lái)到服務(wù)A，重定向到新的URL，而回源的請(qǐng)求來(lái)到服務(wù)B，B返回舊的JS腳本，被CDN緩存，那么新配置的生效時(shí)間將會(huì)推遲到CDN緩存失效。。。
解決方案
首先想到的是將回源服務(wù)獨(dú)立出來(lái)，如果有配置更新，首先等待回源服務(wù)生效，然后再更新重定向服務(wù)。這個(gè)方案的缺點(diǎn)就是麻煩，得多部署一套服務(wù)，前端人員更新JS靜態(tài)文件得等挺久，所以否掉了。
然后想到的一個(gè)方案是，重定向的時(shí)候在URL中標(biāo)示出回源主機(jī)，舉例來(lái)說(shuō)，A返回重定向地址，回源請(qǐng)求來(lái)到Nginx，Nginx根據(jù)URL判斷需要轉(zhuǎn)發(fā)到A，而不是B，如此就不會(huì)出現(xiàn)上面提到的問(wèn)題，另外即使某臺(tái)服務(wù)宕機(jī)，另外一臺(tái)也可以正常提供服務(wù)。
這塊邏輯不應(yīng)該耦合到原有的分發(fā)服務(wù)，所以就是想到了使用OpenResty解決：
http {...    upstream js_backend {        server 10.1.1.20:8080;        server 10.1.1.21:8080;        keepalive 64;    }...    server {        listen       80;...        location ^~ /20/ {            PRoxy_pass http://10.1.1.20:8080/;            proxy_http_version 1.1;            proxy_set_header Connection "";        }        location ^~ /21/ {            proxy_pass http://10.1.1.21:8080/;            proxy_http_version 1.1;            proxy_set_header Connection "";        }        location = /js {            proxy_pass http://js_backend;            proxy_http_version 1.1;            proxy_set_header Connection "";            header_filter_by_lua_block {                if ngx.status == 302 then                    local regex = "^([0-9]+).([0-9]+).([0-9]+).([0-9]+):([0-9]+)$"                    local m, err = ngx.re.match(ngx.var.upstream_addr, regex)                    if m then                        local loc = ngx.header["Location"]                        local s = loc:find("/", 9)                        ngx.header["Location"] = table.concat({loc:sub(1, s), m[4], "/", loc:sub(s+1, -1)})                    else                        ngx.log(ngx.ERR, err)                    end                end            }        }                ...            }}    
這里沒(méi)有把upstream_addr完全拼進(jìn)去，然后根據(jù)該段轉(zhuǎn)發(fā)，主要是考慮到安全上的問(wèn)題。
服務(wù)切了過(guò)來(lái)，一切正常，性能也沒(méi)受到影響。（剛切過(guò)來(lái)時(shí)，回源請(qǐng)求比較多，受了點(diǎn)兒影響）
總的來(lái)說(shuō)，對(duì)于OpenResty印象相當(dāng)好，如果場(chǎng)景合適，以后會(huì)多多使用。
更新 0603
最近有一個(gè)后端tomcat掛掉了，然后看到error.log中大量的
2016/06/02 15:00:25 [error] 5128#0: *412855176 connect() failed (111: Connection refused) while connecting to upstream, client: 49.117.113.178, server: *.touclick.com, request: "GET /xxx HTTP/1.1", upstream: "http://10.47.64.40:8099/xxx", host: "js.touclick.com", referrer: "http://x"2016/06/02 15:00:25 [warn] 5128#0: *412855176 upstream server temporarily disabled while connecting to upstream, client: 49.117.113.178, server: *.touclick.com, request: "GET /xxx HTTP/1.1", upstream: "http://10.47.64.40:8099/xxx", host: "js.touclick.com", referrer: "http://x"2016/06/02 15:00:25 [error] 5128#0: *412855176 [lua] xxx_url_rewrite.lua:15: nil while reading response header from upstream, client: 49.117.113.178, server: *.touclick.com, request: "GET /xxx HTTP/1.1", upstream: "http://10.168.234.54:8099/xxx", host: "js.touclick.com", referrer: "http://x"
前兩行容易理解，是由于后端tomcat掛掉了，但是第三行有點(diǎn)兒奇怪，意思是正則表達(dá)式無(wú)法匹配ngx.var.upstream_addr，然后回想起平時(shí)偶爾也會(huì)看到一兩條，但是因?yàn)樘既凰詻](méi)繼續(xù)關(guān)注。
將ngx.var.upstream_addr打印出來(lái)發(fā)現(xiàn)是10.47.64.40:8099, 10.168.234.54:8099這個(gè)，查了一下文檔：
$upstream_addr
keeps the IP address and port, or the path to the UNIX-domain socket of the upstream server. If several servers were contacted during request processing, their addresses are separated by commas, e.g. “192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock”. If an internal redirect from one server group to another happens, initiated by “X-Accel-Redirect” or error_page, then the server addresses from different groups are separated by colons, e.g. “192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock : 192.168.10.1:80, 192.168.10.2:80”.
啊…… 發(fā)現(xiàn)了一個(gè)bug……
修復(fù)如下：
if ngx.status == ngx.HTTP_MOVED_TEMPORARILY then    local regex = "^([0-9]+).([0-9]+).([0-9]+).([0-9]+):([0-9]+)$"    local upstream_addr = ngx.var.upstream_addr    local i, j = upstream_addr:find(", ")    while i do        upstream_addr = upstream_addr:sub(j+1, -1)        i, j = upstream_addr:find(", ")    end    local m, err = ngx.re.match(upstream_addr, regex, "o")    if m then        local loc = ngx.header["Location"]        local i, j = loc:find("://")        local s = loc:find("/", j+1)        ngx.header["Location"] = table.concat({ngx.var.scheme, loc:sub(i, s), m[4], "/", loc:sub(s+1, -1)})    else        ngx.log(ngx.WARN, "upstream_addr: ", ngx.var.upstream_addr)        ngx.log(ngx.ERR, err)    endend