通過FastCGI Cache實現(xiàn)服務降級
在自然界中，很多生物面臨生死考驗的時候，往往會做出驚人的反應，其中最為大家熟知的當屬壁虎，危難關(guān)頭，與其坐以待斃，不如斷尾求生，通過自殘來換取活下去的希望。對于互聯(lián)網(wǎng)項目而言，同樣存在著很多生死考驗，比如：訪問量激增；數(shù)據(jù)庫宕機等等，此時如果沒有合理的降級方案，那么結(jié)局必然是死路一條。
任何問題一旦脫離了實際情況，便失去了討論的意義。在繼續(xù)之前，不妨先介紹一下案例的背景情況：一個PHP網(wǎng)站，以讀為主，原本躲在CDN后面，運行很穩(wěn)定，后來新增了很多強調(diào)實時性的需求，便去掉了CDN，進而導致系統(tǒng)穩(wěn)定性受到影響。因為歷史包袱重，所以完全廢棄以前的架構(gòu)顯得并不現(xiàn)實，解決方案***能夠盡可能透明，不能對原有架構(gòu)造成沖擊，最終我選擇了通過FastCGI Cache實現(xiàn)服務降級的方案。
關(guān)于FastCGI Cache，以前很多朋友已經(jīng)做過分享，比如：超群、莿鳥棲草堂，概念性的東西我就不再贅述了，說點與眾不同的：雖然使用了緩存，但出于實時性考慮，正常情況下緩存都是被穿透的，只有在出現(xiàn)異常情況的時候才查詢，架構(gòu)圖如下：
Degradation
實現(xiàn)的關(guān)鍵點在于通過error_page處理異常，并且完成服務降級：
- limit_conn_zone $server_name zone=perserver:1m;
- error_page 500 502 503 504 = @degradation;
- fastcgi_cache_path /tmp
- levels=1:2
- keys_zone=degradation:100m
- inactive=10d
- max_size=10g;
- upstream php {
- server 127.0.0.1:9000;
- server 127.0.0.1:9001;
- }
- server {
- listen 80;
- limit_conn perserver 1000;
- server_name *.xip.io;
- root /usr/local/www;
- index index.html index.htm index.php;
- location / {
- try_files $uri $uri/ /index.php$is_args$args;
- }
- location ~ \.php$ {
- set $cache_key $request_method://$host$request_uri;
- set $cache_bypass "1";
- if ($arg_degradation = "on") {
- set $cache_bypass "0";
- }
- try_files $uri =404;
- include fastcgi.conf;
- fastcgi_pass php;
- fastcgi_intercept_errors on;
- fastcgi_next_upstream error timeout;
- fastcgi_cache degradation;
- fastcgi_cache_lock on;
- fastcgi_cache_lock_timeout 1s;
- fastcgi_cache_valid 200 301 302 10h;
- fastcgi_cache_min_uses 10;
- fastcgi_cache_use_stale error
- timeout
- invalid_header
- updating
- http_500
- http_503;
- fastcgi_cache_key $cache_key;
- fastcgi_cache_bypass $cache_bypass;
- add_header X-Cache-Status $upstream_cache_status;
- add_header X-Response-Time $upstream_response_time;
- }
- location @degradation {
- rewrite . $request_uri?degradation=on last;
- }
- }
插播一個小技巧：設(shè)置域名時用到了xip.io，有了它就不用設(shè)置hosts了，方便調(diào)試。
代碼里用到的都是Nginx缺省包含的功能，我們可以看作是一個通用版，不過對照我們架構(gòu)圖中的目標就會發(fā)現(xiàn)：它沒有實現(xiàn)全局激活緩存的功能。如何實現(xiàn)呢？最簡單的方法就是通過單位時間內(nèi)出錯次數(shù)的多少來判斷系統(tǒng)健康以否，設(shè)置相應的閾值，一旦超過限制就全局激活緩存，通過Lua我們可以實現(xiàn)一個定制版：
- lua_shared_dict fault 1m;
- limit_conn_zone $server_name zone=perserver:1m;
- error_page 500 502 503 504 = @degradation;
- fastcgi_cache_path /tmp
- levels=1:2
- keys_zone=degradation:100m
- inactive=10d
- max_size=10g;
- upstream php {
- server 127.0.0.1:9000;
- server 127.0.0.1:9001;
- }
- init_by_lua '
- get_fault_key = function(timestamp)
- if not timestamp then
- timestamp = ngx.time()
- end
- return os.date("fault:minute:%M", timestamp)
- end
- get_fault_num = function(timestamp)
- local fault = ngx.shared.fault
- local key = get_fault_key(timestamp)
- return tonumber(fault:get(key)) or 0
- end
- incr_fault_num = function(timestamp)
- local fault = ngx.shared.fault
- local key = get_fault_key(timestamp)
- if not fault:incr(key, 1) then
- fault:set(key, 1, 600)
- end
- end
- ';
- server {
- listen 80;
- limit_conn perserver 1000;
- server_name *.xip.io;
- root /usr/local/www;
- index index.html index.htm index.php;
- location / {
- rewrite_by_lua '
- if ngx.var.arg_degradation then
- return ngx.exit(ngx.OK)
- end
- local ok = true
- for i = 0, 1 do
- local num = get_fault_num(ngx.time() - i * 60)
- if num > 1000 then
- ok = false
- break
- end
- end
- if not ok then
- local query = "degradation=on"
- if ngx.var.args then
- ngxngx.var.args = ngx.var.args .. "&" .. query
- else
- ngx.var.args = query
- end
- end
- ';
- try_files $uri $uri/ /index.php$is_args$args;
- }
- location ~ \.php$ {
- set $cache_key $request_method://$host$request_uri;
- set $cache_bypass "1";
- if ($arg_degradation = "on") {
- set $cache_bypass "0";
- }
- try_files $uri =404;
- include fastcgi.conf;
- fastcgi_pass php;
- fastcgi_intercept_errors on;
- fastcgi_next_upstream error timeout;
- fastcgi_cache degradation;
- fastcgi_cache_lock on;
- fastcgi_cache_lock_timeout 1s;
- fastcgi_cache_valid 200 301 302 10h;
- fastcgi_cache_min_uses 10;
- fastcgi_cache_use_stale error
- timeout
- invalid_header
- updating
- http_500
- http_503;
- fastcgi_cache_key $cache_key;
- fastcgi_cache_bypass $cache_bypass;
- add_header X-Cache-Status $upstream_cache_status;
- add_header X-Response-Time $upstream_response_time;
- }
- location @degradation {
- content_by_lua '
- if ngx.var.arg_degradation then
- return ngx.exit(ngx.HTTP_INTERNAL_SERVER_ERROR)
- end
- local res = ngx.location.capture(
- ngx.var.request_uri, {args = "degradation=on"}
- )
- ngx.status = res.status
- for name, value in pairs(res.header) do
- ngx.header[name] = value
- end
- ngx.print(res.body)
- incr_fault_num()
- ';
- }
- }
說明：實際上真實案例中緩存鍵名的獲取邏輯有點復雜，鑒于篇幅所限一切從簡。
當系統(tǒng)正常時，運行于動態(tài)模式，數(shù)據(jù)通過PHP-FPM渲染；當系統(tǒng)異常時，全局緩存被激活，運行于靜態(tài)模式，數(shù)據(jù)通過緩存渲染。通過測試發(fā)現(xiàn)，系統(tǒng)在從正常切換到異常時，因為舍棄了PHP-FPM，所以RPS從一千躍升到一萬。這讓我想起兒時看圣斗士的情景：每當不死鳥一輝被敵人擊倒后，他總能重新站起來，并爆發(fā)出更大的能量。
此外需要說明的是：在發(fā)生故障的時候，如果出現(xiàn)大量緩存過期的情況，那么由于涉及到緩存的重建，所以依然會和PHP-FPM發(fā)生交互行為，這可能會影響性能，此時沒有特別好的解決辦法，如果Nginx版本夠的話，可以考慮激活fastcgi_cache_revalidate，如此一來，PHP-FPM一旦判斷系統(tǒng)處于異常情況，那么可以直接返回304實現(xiàn)緩存續(xù)期。
…
通過FastCGI Cache實現(xiàn)服務降級，這是一個***的方案么？非也！它甚至有些丑陋，比如說多臺服務器時，會導致大量冗余的緩存，此外磁盤IO也需要注意。雖然這不是一個***的方案，但是它簡單，正符合我解決棘手問題時的慣用打法：先用一個土鱉一點的方案緩解問題，再用一個***的方案解決問題。稍后我會考慮使用Memcached，加上一致性哈希來替換FastCGI Cache，實現(xiàn)一個相對***的服務降級方案。
