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

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

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

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

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

又拍云因為是公有云處理服務(wù)，使用場景和作圖功能要求很泛，什么打水印、模糊、加特效等，因此用軟編碼的方式是選擇。

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

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

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

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

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

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

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

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

因為我們提供的是公有云服務(wù)，客戶傳什么圖進來，我們是不知道的，各種各樣，甚至有幾十兆的 GIF 圖。但這種圖所占整體的比例非常小，遠低于 1%。所以我們只部署了 2 臺 BigGmServer 來做這部分的處理任務(wù)。

自研的 GmServer

GmServer 最重要的策略特性是：

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

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

因為在并發(fā)數(shù)超出 CPU 處理能力的時候，整體的處理性能下降比較嚴重，大家都在搶占 CPU，結(jié)果是大家都做不好。

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

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

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

另外一個大頭是修復 GraphicsMagick 的 BUG 和新功能的添加。因為是公有云，所以接收的圖片各種各樣，甚至有些是缺損的或者是經(jīng)過“{{BANNED}}”壓縮的 gif，GraphicsMagick 不一定能夠識別和處理。

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

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

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

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

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

8 臺 nginx 中隨機選 1 臺，再 nginx 把任務(wù)隨機分配給 1 個 GmServer，處理完成。

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

8 臺 nginx 中隨機選 1 臺，再 nginx 把任務(wù)隨機分配給 1 個 GmServer，處理 5 秒超時返回 413。再由 nginx 把任務(wù)分配給 BigGmServer。

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

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

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

因為 nginx 的 7 層負載均衡還帶容錯能力，1 個{{BANNED}}圖片進來處理不了，會嘗試其他機器，不一會兒整個集群都被這個{{BANNED}}圖片給占了，所以我們有必要把任務(wù)分類處理的。

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

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

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

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

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

當前架構(gòu)優(yōu)點

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

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

當前架構(gòu)不足

動態(tài)擴容不友好，因為架構(gòu)太簡單，動態(tài)擴容的實現(xiàn)復雜度高一些，因為需要跟 nginx 做聯(lián)動。為此要配置自動發(fā)現(xiàn)和 nginx 動態(tài)配置 upstream 等（當然這塊用 nginx + Lua 很好做）。

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

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

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

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

這里有個重點是

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

Worker可混合部署。

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

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

運營中遇到過的坑

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

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

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

數(shù)據(jù)中心緩存有磁盤損壞或者服務(wù)器故障時，會導致大部分的緩存失效，從而導致落到作圖服務(wù)的請求數(shù)增大好幾倍。而作圖服務(wù)是無法承受如此大壓力的，所以我們允許向用戶吐 503 錯誤碼。

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

CDN 緩存一般不會出問題，因為它是分布式、多緩存節(jié)點的架構(gòu)，服務(wù)器數(shù)量太龐大，即使有磁盤壞或者機器故障所產(chǎn)生的震蕩都很小，不必擔心。

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

但還要擔心的一個是“惡意”請求，這里說的惡意是帶雙引號的，因為它并不是真正意義的攻擊，很可能只是客戶一個小變動導致。比如修改了一個縮略圖版本號配置，這個操作就會導致舊版本的縮略圖緩存全部失效，而要重新到作圖服務(wù)處理。

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

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

針對具體場景的優(yōu)化與設(shè)計

縮略圖版本號的使用確實給業(yè)務(wù)帶來非常大的方便，隨時可針對業(yè)務(wù)的需求切換使用不同的縮略圖格式，點下鼠標馬上生效。

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

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

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

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

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

Q & A

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

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

?

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

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

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

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

4. 能否簡單對比下 GraphicsMagick、ImageMagick 優(yōu)缺點？

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

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

黃慧攀：暫時沒這樣的計劃。

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

黃慧攀：這個就看我們怎么做 Worker 部分的開發(fā)。我們每個 Worker 啟動都會鎖定 1 個 ?CPU 核上的，不會對其他 Worker 造成影響；

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

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

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

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

黃慧攀：Good idea 。其實，我還是建議用縮略圖版本號。

群友：處理過的圖片會存儲磁盤嗎？

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

8. 上文所說 nginx 請求 gm_server 時，能否用連接池代替上面逐臺嘗試的做法？

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

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

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

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

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

QQ群：26931708

Hadoop源代碼研究群

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

QQ群：288410967?