2. 負(fù)載均衡
我們主要用到了balance_by_lua_，一個(gè)請(qǐng)求過來(lái)，通過upstream的C模塊，然后把這個(gè)請(qǐng)求往這里發(fā)，下圖這個(gè)配置文件，剛剛也有一個(gè)類似的，就是在這里寫了地址。通過balance_by_lua_指令，我們會(huì)把它攔到這個(gè)文件里，就可以在這個(gè)lua文件里頭用lua代碼選一個(gè)，這就是自身的一個(gè)checkups的選擇的過程。
大概的流程見下圖，可以先看下邊部分，一開始的時(shí)候，checkups.select_peer是我們的模塊，然后根據(jù)這個(gè)host再到當(dāng)前的peer，就跳出去了，這樣就實(shí)現(xiàn)了用lua控制。上面部分是要知道它是成功還是失敗的，如果它失敗了，我要對(duì)這個(gè)狀態(tài)進(jìn)行反饋。
3. 動(dòng)態(tài)lua加載
這個(gè)主要是用到lua的三個(gè)函數(shù)，分別是loadfile、loadstring和setfenv。loadfile是加載本地的lua代碼，loadstring是從consul或HTTP請(qǐng)求body加載代碼，setfenv設(shè)置代碼的執(zhí)行環(huán)境，通過這三個(gè)函數(shù)就可以加載，具體的實(shí)踐細(xì)節(jié)我就不再介紹。
這是我們做的輪子，主要用到checkups的模塊和balance_by_lua_，它有這些優(yōu)勢(shì)：
首先， 純lua實(shí)現(xiàn)，不依賴第三方C模塊， 二次開發(fā)非常高效，減少維護(hù)負(fù)擔(dān)。
第二是 可以用nginx原生的proxy， 因?yàn)槲覀冎辉谡?qǐng)求的選peer的那個(gè)階段做，peer選完之后，發(fā)數(shù)據(jù)的那個(gè)階段是直接走nginx自己的指令的，所以它可以用到nginx原生的proxy指令。
最后，它 適用于幾乎任何的ngx_lua項(xiàng)目。
在微服務(wù)架構(gòu)里，slardar能做什么?
我們目前也在把之前的一些服務(wù)改造成微服務(wù)模式。微服務(wù)其實(shí)就是源于一個(gè)比較大的服務(wù)，把它拆分成一些小的服務(wù)，它的擴(kuò)容跟遷移也不一樣，微服務(wù)的擴(kuò)容可以只擴(kuò)容其中一部分，如果需要比較多的一些功能，就擴(kuò)得多一點(diǎn)，需要少的，就擴(kuò)得少一點(diǎn)。
我們現(xiàn)在正在嘗試的一個(gè)方案，這個(gè)方案背景是這樣子，我們有做圖的一些需求，做圖這個(gè)功能有很多，比如說(shuō)美化，各種需求，如果說(shuō)要對(duì)這個(gè)做圖的服務(wù)進(jìn)行優(yōu)化是非常困難的，因?yàn)樗δ芴嗔?，如果我們把它拆成微服?wù)就不一樣了，比如說(shuō)這個(gè)虛線上面的是我們現(xiàn)在的服務(wù)，這個(gè)是微服務(wù)的一個(gè)網(wǎng)關(guān)，下面是一些小的服務(wù)。
比如說(shuō)美化，它的運(yùn)算比較復(fù)雜，耗CPU比較多，我們肯定選擇一些CPU比較好的機(jī)器;用GPU來(lái)做縮略圖，這個(gè)性能可能提高幾十倍;最后是一個(gè)中規(guī)中矩的做圖，那就普通的一些就夠了。
還有一些比較偏門的，比如說(shuō)梯度，可能只要保證下服務(wù)可以用就行了，通過這個(gè)微服務(wù)的路由，我們根據(jù)后面的區(qū)分把之前的一個(gè)服務(wù)，以及它的參數(shù)拆成三個(gè)小的服務(wù)，這樣通過三個(gè)步驟可以完成一個(gè)做圖的服務(wù)。
當(dāng)然我們?cè)趪L試這個(gè)方案其實(shí)也有很多的問題，比如一個(gè)服務(wù)原來(lái)用一個(gè)程序就可以做了，現(xiàn)在變成了三個(gè)，勢(shì)必內(nèi)網(wǎng)的帶寬要增加了，中間的圖片要被導(dǎo)來(lái)導(dǎo)去，這個(gè)怎么辦呢?我們現(xiàn)在想到的辦法就是做一些本地優(yōu)先的調(diào)度策略，就是說(shuō)你做完之后，本地有一些水印的，那就優(yōu)先用本地的。
套用大師的一句話：Talk is cheap，Show me the code。開源!
好的，謝謝大家!