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

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

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

選擇適合業務場景的系統架構

我們今天不談具體產品，只討論系統架構，很多人關注在圖片處理領域選用 GraphicsMagick、ImageMagick 或者軟編碼或硬編碼的性能高低。這些方案都各有利弊，需要按業務場景來選擇。

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

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

又拍云圖片處理集群規模及架構

圖片處理集群規模

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

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

現行架構

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

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

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

自研的 GmServer

GmServer 最重要的策略特性是：

Server 只并發處理 CPU 核數以內的任務，如果超出了就返回 502，讓 nginx 做容錯處理，選擇下一臺處理服務器。

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

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

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

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

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

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

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

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

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

任務調度邏輯詳解

處理圖片任務 a（普通圖片）

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

處理圖片任務 b（大圖片或者大 GIF）

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

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

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

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

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

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

處理圖片任務 c（普通圖片）

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

現行架構的優缺點分析

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

當前架構優點

服務穩定，過載時業務不會全面受到影響。

架構簡單、通用。

當前架構不足

動態擴容不友好，因為架構太簡單，動態擴容的實現復雜度高一些，因為需要跟 nginx 做聯動。為此要配置自動發現和 nginx 動態配置 upstream 等（當然這塊用 nginx + Lua 很好做）。

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

未來的新架構方向

Nginx 改為使用自己研發的 ServiceServer，基于消息隊列實現任務排隊。此前的 GmServer 轉為 GmWorker，主動對接消息隊列來處理任務。

這個架構的優點是：Worker 輕量級，且很容易做動態擴容，因為 Server 端不需要配置 Worker 信息，Worker 在啟動時主動向 Server 申報身份和認領任務。接下去配合 Docker 的動態擴容就非常方便。

這里有個重點是

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

Worker可混合部署。

Worker 不需要做服務監聽，可以很方便的用 docker 橫行擴展。

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

運營中遇到過的坑

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

先參考下我們的服務架構

緩存失效時候的高可用設計

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

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

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

不同租戶隔離與高可用設計

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

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

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

針對具體場景的優化與設計

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

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

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

圖片在線服務的安全問題

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

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

Q & A

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

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

?

2. 后端存儲圖片的數據庫用的是什么 ？

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

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

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

4. 能否簡單對比下 GraphicsMagick、ImageMagick 優缺點？

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

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

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

6. 老架構按業務區分流量和服務，勝在穩定。新架構在業務上混搭，彼此間是否有權重和流控，會不會有某類流量陡增對其他類業務產生沖擊，或者說如何保障每類業務穩定？

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

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

7. 我們的系統通過參數來處理圖片，而業務方可能直接用鏈接，這樣導致每次都走一遍圖片處理邏輯，有什么優化方案？

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

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

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

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

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

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

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

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

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

軟件開發技術群

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

QQ群：26931708

Hadoop源代碼研究群

興趣范圍包括：Hadoop源代碼解讀，改進，優化，分布式系統場景定制，與Hadoop有關的各種開源項目，總之就是玩轉Hadoop

QQ群：288410967?