摘要：又拍云圖片處理集群規(guī)模及架構(gòu)圖片處理集群規(guī)模臺(tái)核內(nèi)存的服務(wù)器，相當(dāng)于有核的處理能力。平時(shí)花瓣網(wǎng)的圖片處理量就已經(jīng)占集群超過，一下子翻幾十倍的處理量進(jìn)來(lái)，肯定會(huì)對(duì)作圖服務(wù)造成影響。

黃慧攀，又拍云 CTO。最早在 2001 年開始 web 開發(fā)工作；2006 年創(chuàng)辦 yo2.cn 優(yōu)博網(wǎng)（WordPress 博客平臺(tái)）；2010 年加入又拍云開始構(gòu)建第一代云存儲(chǔ)和云 CDN 服務(wù)。曾從事前端、后端和服務(wù)端等工作，目前主要從事技術(shù)架構(gòu)工作。

又拍云的云處理服務(wù)包括圖片和音視頻處理服務(wù)，其中圖片處理系統(tǒng)每秒處理圖片數(shù)量 3000 多張，一天要處理 1 億張圖片左右。圖片處理服務(wù)面向的客戶主要有電商、圖片社交兩類，他們也是圖片處理需求的大戶，其他類型的客戶對(duì)圖片處理需求比較少。

選擇適合業(yè)務(wù)場(chǎng)景的系統(tǒng)架構(gòu)

我們今天不談具體產(chǎn)品，只討論系統(tǒng)架構(gòu)，很多人關(guān)注在圖片處理領(lǐng)域選用 GraphicsMagick、ImageMagick 或者軟編碼或硬編碼的性能高低。這些方案都各有利弊，需要按業(yè)務(wù)場(chǎng)景來(lái)選擇。

又拍云因?yàn)槭枪性铺幚矸?wù)，使用場(chǎng)景和作圖功能要求很泛，什么打水印、模糊、加特效等，因此用軟編碼的方式是選擇。

對(duì)于業(yè)務(wù)只有做縮略圖功能要求的，肯定是硬編碼的性能高。

又拍云圖片處理集群規(guī)模及架構(gòu)

圖片處理集群規(guī)模

30 臺(tái) 24 核、48G 內(nèi)存的服務(wù)器，相當(dāng)于有 30 * (24 - 1) = 690 核的處理能力。

這是我們的狗眼監(jiān)控系統(tǒng)，對(duì)平臺(tái)每個(gè)子服務(wù)都有 QPS 和平均處理耗時(shí)等關(guān)鍵指標(biāo)的監(jiān)控。上圖是作圖集群的 QPS 統(tǒng)計(jì)，處理能力、處理量都很穩(wěn)定。

現(xiàn)行架構(gòu)

前端部署了 8 臺(tái) nginx 做 7 層負(fù)載均衡，這里沒用 LVS 做 4 層負(fù)載均衡，由于這個(gè)場(chǎng)景下 nginx 本身不存在瓶頸，因此我們簡(jiǎn)單使用了 IP 輪詢方式，并在業(yè)務(wù)代碼中來(lái)做容錯(cuò)。

Nginx 中配置 30 臺(tái) GmServer 的 upstream。這其中 28 臺(tái)為普通的 GmServer，另外 2 臺(tái)是 BigGmServer，這個(gè)是非常特殊的角色，Why？

因?yàn)槲覀兲峁┑氖枪性品?wù)，客戶傳什么圖進(jìn)來(lái)，我們是不知道的，各種各樣，甚至有幾十兆的 GIF 圖。但這種圖所占整體的比例非常小，遠(yuǎn)低于 1%。所以我們只部署了 2 臺(tái) BigGmServer 來(lái)做這部分的處理任務(wù)。

自研的 GmServer

GmServer 最重要的策略特性是：

Server 只并發(fā)處理 CPU 核數(shù)以內(nèi)的任務(wù)，如果超出了就返回 502，讓 nginx 做容錯(cuò)處理，選擇下一臺(tái)處理服務(wù)器。

這個(gè)架構(gòu)策略比選用哪個(gè)圖片處理庫(kù)重要得多。

因?yàn)樵诓l(fā)數(shù)超出 CPU 處理能力的時(shí)候，整體的處理性能下降比較嚴(yán)重，大家都在搶占 CPU，結(jié)果是大家都做不好。

GmServer 是基于 Linux + epoll + GraphicsMagick 開發(fā)的，在可控范圍內(nèi)做到全部?jī)?nèi)存處理圖片，不走磁盤 IO。

對(duì)于 GraphicsMagick 本身還有不少處理邏輯會(huì)使用到本地磁盤 IO，我們把這部分放到 /dev/shm 上。

服務(wù)器 48G 內(nèi)存，才 23 個(gè)并發(fā)任務(wù)，所以是夠用的。完全基于內(nèi)存做處理，可以避開磁盤 IO 的損耗，取得較高性能。

另外一個(gè)大頭是修復(fù) GraphicsMagick 的 BUG 和新功能的添加。因?yàn)槭枪性疲越邮盏膱D片各種各樣，甚至有些是缺損的或者是經(jīng)過“{{BANNED}}”壓縮的 gif，GraphicsMagick 不一定能夠識(shí)別和處理。

我們有專人長(zhǎng)期在為此而戰(zhàn)斗，并且這些 BUG 修復(fù)一般都會(huì)提交給 GraphicsMagick 官方，用以給開源社區(qū)一些貢獻(xiàn)。

比如較大的一個(gè)就是 WebP 格式的支持，是我們工程師給 GraphicsMagick 提交的。

又拍網(wǎng)到現(xiàn)在的又拍云，使用 GraphicsMagick 有 6～7 個(gè)年頭，在這方面的技術(shù)和經(jīng)驗(yàn)積累非常多。如果您在使用過程中遇到特殊無(wú)法處理的圖片，可以郵件聯(lián)系找我們看看是否能做到兼容處理：huipan.huang@upai.com。

任務(wù)調(diào)度邏輯詳解

處理圖片任務(wù) a（普通圖片）

8 臺(tái) nginx 中隨機(jī)選 1 臺(tái)，再 nginx 把任務(wù)隨機(jī)分配給 1 個(gè) GmServer，處理完成。

處理圖片任務(wù) b（大圖片或者大 GIF）

8 臺(tái) nginx 中隨機(jī)選 1 臺(tái)，再 nginx 把任務(wù)隨機(jī)分配給 1 個(gè) GmServer，處理 5 秒超時(shí)返回 413。再由 nginx 把任務(wù)分配給 BigGmServer。

這個(gè) 5 秒超時(shí)是很特殊的經(jīng)驗(yàn)值，對(duì)于小圖片處理都是幾十毫秒的事，2k 分辨率的也就百毫秒，所以 5 秒以上的圖片就特別{{BANNED}}了。

為了保障絕大部分普通圖片的處理服務(wù)，所以我們把這種{{BANNED}}圖片扔到 BigGmServer 去處理，BigGmServer 配置的任務(wù)超時(shí)時(shí)間是 60 秒。

為什么要扔到 BigGmServer？請(qǐng)想象一下普通處理集群，被{{BANNED}}圖片占滿會(huì)出現(xiàn)什么效果？

因?yàn)?nginx 的 7 層負(fù)載均衡還帶容錯(cuò)能力，1 個(gè){{BANNED}}圖片進(jìn)來(lái)處理不了，會(huì)嘗試其他機(jī)器，不一會(huì)兒整個(gè)集群都被這個(gè){{BANNED}}圖片給占了，所以我們有必要把任務(wù)分類處理的。

(任務(wù) a、b、c 示意圖)

處理圖片任務(wù) c（普通圖片）

這里有個(gè)前提假設(shè)：我們的 GmServer 只能做 2 個(gè)并發(fā)任務(wù)（否則我畫圖得畫 24 個(gè)）即目前狀態(tài)下 GmServer 不會(huì)再接收任務(wù)。新來(lái)的 c 任務(wù)會(huì)返回 502，讓 nginx 重新選擇一臺(tái) GmServer 來(lái)處理任務(wù)。即使遍歷集群也就 20ms 以內(nèi)，一般下一跳就能得到處理了。

現(xiàn)行架構(gòu)的優(yōu)缺點(diǎn)分析

一般每周 review 一下處理的 QPS，關(guān)注一下吐出的錯(cuò)誤碼比例，能準(zhǔn)確判斷到集群是否過載，提前能做好擴(kuò)容工作。

當(dāng)前架構(gòu)優(yōu)點(diǎn)

服務(wù)穩(wěn)定，過載時(shí)業(yè)務(wù)不會(huì)全面受到影響。

架構(gòu)簡(jiǎn)單、通用。

當(dāng)前架構(gòu)不足

動(dòng)態(tài)擴(kuò)容不友好，因?yàn)榧軜?gòu)太簡(jiǎn)單，動(dòng)態(tài)擴(kuò)容的實(shí)現(xiàn)復(fù)雜度高一些，因?yàn)樾枰?nginx 做聯(lián)動(dòng)。為此要配置自動(dòng)發(fā)現(xiàn)和 nginx 動(dòng)態(tài)配置 upstream 等（當(dāng)然這塊用 nginx + Lua 很好做）。

最近 Docker 很火，我們也有在關(guān)注這方面的技術(shù)。綜合分析下來(lái)，打算做一套新的架構(gòu)，把我們圖片處理和音視頻處理，原來(lái)兩套獨(dú)立的集群混合起來(lái)，把資源利用率做上去。

未來(lái)的新架構(gòu)方向

Nginx 改為使用自己研發(fā)的 ServiceServer，基于消息隊(duì)列實(shí)現(xiàn)任務(wù)排隊(duì)。此前的 GmServer 轉(zhuǎn)為 GmWorker，主動(dòng)對(duì)接消息隊(duì)列來(lái)處理任務(wù)。

這個(gè)架構(gòu)的優(yōu)點(diǎn)是：Worker 輕量級(jí)，且很容易做動(dòng)態(tài)擴(kuò)容，因?yàn)?Server 端不需要配置 Worker 信息，Worker 在啟動(dòng)時(shí)主動(dòng)向 Server 申報(bào)身份和認(rèn)領(lǐng)任務(wù)。接下去配合 Docker 的動(dòng)態(tài)擴(kuò)容就非常方便。

這里有個(gè)重點(diǎn)是

ServiceServer 可支撐圖片集群、音視頻處理，甚至普通 Web 請(qǐng)求任務(wù)。

Worker可混合部署。

Worker 不需要做服務(wù)監(jiān)聽，可以很方便的用 docker 橫行擴(kuò)展。

如果想走捷徑，可以考慮 nginx Plus 版本的 7 層負(fù)載均衡支持隊(duì)列功能，也能達(dá)到這個(gè)效果。但也有較大的缺點(diǎn)：$1900 / 單機(jī) / 年。當(dāng)然這個(gè) nginx 的方案，做 docker 的橫向擴(kuò)展時(shí)，還是逃不掉跟 nginx 做聯(lián)動(dòng)、自動(dòng)發(fā)現(xiàn)等事情。

運(yùn)營(yíng)中遇到過的坑

集群自身是沒遇到過什么大的坑，只有些小邏輯 bug 的問題。但在服務(wù)上有緩存失效和業(yè)務(wù)攻擊的問題，需要做自動(dòng)降級(jí)和適當(dāng)屏蔽。

先參考下我們的服務(wù)架構(gòu)

緩存失效時(shí)候的高可用設(shè)計(jì)

數(shù)據(jù)中心緩存有磁盤損壞或者服務(wù)器故障時(shí)，會(huì)導(dǎo)致大部分的緩存失效，從而導(dǎo)致落到作圖服務(wù)的請(qǐng)求數(shù)增大好幾倍。而作圖服務(wù)是無(wú)法承受如此大壓力的，所以我們?cè)试S向用戶吐 503 錯(cuò)誤碼。

注意這個(gè)錯(cuò)誤碼要配置起碼 1 分鐘以上的緩存失效時(shí)間，以避免用戶重復(fù)刷新請(qǐng)求。如果不設(shè)置一個(gè)讓客戶端緩存的時(shí)間，那這個(gè) 503 錯(cuò)誤碼吐得沒什么意義了。

CDN 緩存一般不會(huì)出問題，因?yàn)樗欠植际健⒍嗑彺婀?jié)點(diǎn)的架構(gòu)，服務(wù)器數(shù)量太龐大，即使有磁盤壞或者機(jī)器故障所產(chǎn)生的震蕩都很小，不必?fù)?dān)心。

不同租戶隔離與高可用設(shè)計(jì)

但還要擔(dān)心的一個(gè)是“惡意”請(qǐng)求，這里說(shuō)的惡意是帶雙引號(hào)的，因?yàn)樗⒉皇钦嬲饬x的攻擊，很可能只是客戶一個(gè)小變動(dòng)導(dǎo)致。比如修改了一個(gè)縮略圖版本號(hào)配置，這個(gè)操作就會(huì)導(dǎo)致舊版本的縮略圖緩存全部失效，而要重新到作圖服務(wù)處理。

如果這是個(gè)小客戶，那沒啥事，但如果是像花瓣網(wǎng)這樣的大客戶，就問題很嚴(yán)重了。平時(shí)花瓣網(wǎng)的圖片處理量就已經(jīng)占集群超過 50%，一下子翻幾十倍的處理量進(jìn)來(lái)，肯定會(huì)對(duì)作圖服務(wù)造成影響。一個(gè)客戶影響整個(gè)平臺(tái)！

為此我們?cè)?nginx 上加了針對(duì)客戶的峰值控制系統(tǒng)，來(lái)避免這種情況而影響整個(gè)平臺(tái)。

針對(duì)具體場(chǎng)景的優(yōu)化與設(shè)計(jì)

縮略圖版本號(hào)的使用確實(shí)給業(yè)務(wù)帶來(lái)非常大的方便，隨時(shí)可針對(duì)業(yè)務(wù)的需求切換使用不同的縮略圖格式，點(diǎn)下鼠標(biāo)馬上生效。

但這也是有代價(jià)的，就是上面所說(shuō)的影響。無(wú)法完美解決這個(gè)問題，要不把作圖集群擴(kuò)到完全無(wú)緩存都能處理的能力，要不就接受繁忙時(shí)會(huì)出現(xiàn)部分圖片 503 錯(cuò)誤。

而我們會(huì)考慮到成本，顯然無(wú)法提供到峰值的處理能力，那勢(shì)必要接受一定的錯(cuò)誤量。但這個(gè)也是可以盡量避免，比如應(yīng)用方要做縮略圖版本切換時(shí)，可以考慮提前預(yù)熱一段時(shí)間，灰度切換，使得這個(gè)峰值能得到一定的均衡。

圖片在線服務(wù)的安全問題

另外一些缺乏經(jīng)驗(yàn)的云廠商，也提供在線作圖服務(wù)，且更方便。比如 http://a.com/b.jpg?w=100 ? 通過參數(shù)自由配置想要的縮略圖大小，試想一下，被人惡意組合url參數(shù)來(lái)刷你的作圖集群，會(huì)是怎么個(gè)效果。

上面提到，如果客戶有類似需求，較好自動(dòng)化控制單客戶占用資源，我們也是去年才提供通過 url 參數(shù)來(lái)作圖的功能。 建議大家在新建這樣的服務(wù)時(shí)，要多考慮周到。

Q & A

1. 前端部署了 8 臺(tái) nginx 做 7 層負(fù)載均衡，這里沒用 LVS 做 4 層負(fù)載均衡。為何如此設(shè)計(jì)？

黃慧攀：這個(gè)不是性能的問題，只是開發(fā)多幾行代碼，或運(yùn)維多一個(gè) LVS 管理的事而已。我們是在業(yè)務(wù)代碼上， {s1….s8} 隨機(jī)選 1 臺(tái)的。LVS 大多起負(fù)載均衡作用，但在這個(gè)場(chǎng)景下 nginx 本身壓力很小并不存在瓶頸，因此我們簡(jiǎn)單使用了 IP 輪詢方式，并在業(yè)務(wù)代碼中來(lái)做容錯(cuò)。

?

2. 后端存儲(chǔ)圖片的數(shù)據(jù)庫(kù)用的是什么 ？

黃慧攀：這個(gè)我們是存在云存儲(chǔ)里面的。建議你用 Key/Value 數(shù)據(jù)庫(kù)也行。

3. 后續(xù)有沒有考慮將圖片的處理用 GPU 做？

黃慧攀：前面說(shuō)到過我們的業(yè)務(wù)需求復(fù)雜度比較高，用 GPU 會(huì)大大增加我們的研發(fā)難度和投入。目前的場(chǎng)景選用 CPU 的方案最適合我們。

4. 能否簡(jiǎn)單對(duì)比下 GraphicsMagick、ImageMagick 優(yōu)缺點(diǎn)？

黃慧攀：你可以這么理解，gm 是 im 的一個(gè)基礎(chǔ)庫(kù)，im 在 gm 上做了更好的功能封裝。套了層殼，性能是 gm 較好的。

5. 又拍云的圖片服務(wù)是否提供 OCR 服務(wù)？

黃慧攀：暫時(shí)沒這樣的計(jì)劃。

6. 老架構(gòu)按業(yè)務(wù)區(qū)分流量和服務(wù)，勝在穩(wěn)定。新架構(gòu)在業(yè)務(wù)上混搭，彼此間是否有權(quán)重和流控，會(huì)不會(huì)有某類流量陡增對(duì)其他類業(yè)務(wù)產(chǎn)生沖擊，或者說(shuō)如何保障每類業(yè)務(wù)穩(wěn)定？

黃慧攀：這個(gè)就看我們?cè)趺醋?Worker 部分的開發(fā)。我們每個(gè) Worker 啟動(dòng)都會(huì)鎖定 1 個(gè) ?CPU 核上的，不會(huì)對(duì)其他 Worker 造成影響；

另外說(shuō)到的任務(wù)權(quán)重，和個(gè)別業(yè)務(wù)需要突發(fā)處理的情況，我們有做考慮。先分成 2 類任務(wù)， 1、同步任務(wù)（如圖片處理）；2、異步任務(wù)。 我們優(yōu)先處理同步任務(wù)，對(duì)每單個(gè)客戶要做好全局的資源限制。

7. 我們的系統(tǒng)通過參數(shù)來(lái)處理圖片，而業(yè)務(wù)方可能直接用鏈接，這樣導(dǎo)致每次都走一遍圖片處理邏輯，有什么優(yōu)化方案？

黃慧攀：自己內(nèi)部的服務(wù)，可以考慮增加權(quán)限及 IP 訪問頻率等限制即可。 如果是云服務(wù)商可以參考我上面方案。

群友：可以對(duì)參數(shù)做加密，時(shí)間戳也打進(jìn)去，一方面鑒權(quán)，一方面驗(yàn)證請(qǐng)求有效期。

黃慧攀：Good idea 。其實(shí)，我還是建議用縮略圖版本號(hào)。

群友：處理過的圖片會(huì)存儲(chǔ)磁盤嗎？

黃慧攀：處理過的圖片，不存磁盤。 但上面有 2 層緩存。

8. 上文所說(shuō) nginx 請(qǐng)求 gm_server 時(shí)，能否用連接池代替上面逐臺(tái)嘗試的做法？

黃慧攀：用連接池會(huì)導(dǎo)致負(fù)載不均衡的。 遍歷池子的損耗很小。另外如果考慮連接池了，用上面新架構(gòu)模式或許更好， 放到消息隊(duì)列，Worker 來(lái)消費(fèi)。

9：超時(shí)判斷是在 nginx？那樣雖然返回錯(cuò)誤碼了，但 gm 的轉(zhuǎn)換還在進(jìn)行，還是會(huì)占用資源？

黃慧攀：超時(shí)判斷是 gmserver 做的，gmserver 是多進(jìn)程的，自己內(nèi)部直接把自己殺了。如果用 nginx 來(lái)做肯定面臨你說(shuō)的問題，所以非常必要自己開發(fā)這個(gè) gmserver。

軟件開發(fā)技術(shù)群

興趣范圍包括：Java，C/C++，Python，PHP，Ruby，shell等各種語(yǔ)言開發(fā)經(jīng)驗(yàn)交流，各種框架使用，外包項(xiàng)目機(jī)會(huì)，學(xué)習(xí)、培訓(xùn)、跳槽等交流

QQ群：26931708

Hadoop源代碼研究群

興趣范圍包括：Hadoop源代碼解讀，改進(jìn)，優(yōu)化，分布式系統(tǒng)場(chǎng)景定制，與Hadoop有關(guān)的各種開源項(xiàng)目，總之就是玩轉(zhuǎn)Hadoop

QQ群：288410967?