最后一個，是luasocket，千萬不能在nginx在處理請求的時候用。
簡單介紹一下lua_resty_checkups這個模板，它有幾個功能：
第一個是 動態(tài)upstream管理， 基于共享內(nèi)存實(shí)現(xiàn)worker間同步;
然后是 被動健康檢查， 這個是nginx自身的一個特性;
第三是 主動健康檢查 ，這個模塊會主動給你的后端發(fā)心跳包，可以定時，15秒發(fā)一次，你后端的服務(wù)是不是存活。我們還可以有一些個性化的檢查，然后heratbeat定時給上游發(fā)送心跳包檢測服務(wù)是否存活。
最后是 負(fù)載均衡算法， 本地優(yōu)先可節(jié)約內(nèi)網(wǎng)流量等等。
以Host區(qū)分服務(wù)：比如說這兩個curl往同一個地址去發(fā)，這兩者之間是不一樣的。
這個圖簡單講一下，它是一個請求的流程，可以分為三個部分，最上面是接收請求，我們會加載一個worker代碼，在worker代碼執(zhí)行完之后，會根據(jù)這個host找對應(yīng)的列表，然后把這個請求代理給服務(wù)端。
這個跟dyups的C模塊一樣，也是通過HTTP接口動態(tài)更新upstream列表，加完之后，可以在管理頁面看一下，就可以看到剛剛加進(jìn)去的兩個服務(wù)，這里面有server地址，一些健康檢查的消息，還有它的狀態(tài)變更的時間，以及它失敗的次數(shù)，這是主動健康檢查的一個記錄。那為什么會有主動健康檢查呢?我稍微介紹一下，大家平時用的就是一些被動的健康檢查，就是說我這個請求發(fā)出去之后失敗了才知道失敗了，主動的就是我發(fā)心跳包，在請求之前，我就可以知道你這個服務(wù)是不是出問題了。
動態(tài)lua加載，這個在做游戲的時候會經(jīng)常用到，在一開始的時候，我們的程序里面跑了一些lua的代碼，給后端的程序做參數(shù)轉(zhuǎn)化和做兼容用，比如有一個小調(diào)整不樂意去改，就拿前面的路由去做，首先我可以對請求做改寫，因?yàn)槲铱梢阅玫秸麄€的請求的，它的請求體可以做任意的事情，這樣的話，我可以跟一些權(quán)限控制結(jié)合起來，還有一個就是可以做一些簡單的參數(shù)檢查。據(jù)我們的統(tǒng)計(jì)，我們大概有至少10%是重復(fù)的請求，那這些重復(fù)請求如果都去做的話就是無謂的消耗，我們會返一個304，表示結(jié)果跟之前的一樣，用之前的結(jié)果就好了。在返304的時候，如果說我們是需要后端的服務(wù)去判斷，勢必會把整個請求給收下來，然后再往后面發(fā)，相當(dāng)于是內(nèi)網(wǎng)帶寬要增加一些，這樣其實(shí)就已經(jīng)節(jié)省了帶寬，可以不往后面發(fā)了，主要是這幾個原因。
這是一個動態(tài)負(fù)載加載的例子，我如果把這段代碼推到Slardar里面的話，它會執(zhí)行，如果你進(jìn)行一個刪除操作，它會返403，也就是說可以立即通過這個代碼禁掉這個操作，那還有什么功能呢?你可以想象到的功能都可以做，而且這個過程是動態(tài)的，如果代碼加載，也可以從狀態(tài)頁里看到它的信息。
剛剛講的都是這個項(xiàng)目的特性，接下來想簡單介紹一下實(shí)現(xiàn)過程，有一些可能比較深入，我盡量把一些深入的地方帶過去，動態(tài)upstream管理，分三個部分，三個步驟。
1. 動態(tài)upstream管理
啟動時從consul加載配置文件，如果你沒有任何理由的掛了，掛了之后你剛起來時，你怎么知道你剛剛怎么了呢?所以得有一個地方去固化這些東西，而我們選的就是consul，所以它啟動的時候必須從consul加載，啟動之后一個就是監(jiān)聽管理的端口，還有一個就是要啟動一個定時器，這個定時器做worker間同步的，定時從共享內(nèi)存看一下有沒有更新，有更新的話可以同步在自己的worker里頭。
這是一個簡單的流程圖，最開始的時候從consul加載，在完成fork之后，就到了worker進(jìn)程，也就是剛剛你初始化加載的那些每個worker都有了，另外一部分啟動定時器，一旦有更新就會進(jìn)入到這個里面。