# 每天可處理數百萬個請求的圖像優化技術 > 原文： [http://highscalability.com/blog/2016/6/15/the-image-optimization-technology-that-serves-millions-of-re.html](http://highscalability.com/blog/2016/6/15/the-image-optimization-technology-that-serves-millions-of-re.html)  本文將介紹 [Kraken.io](https://kraken.io/) 如何構建和擴展每天可處理數百萬個請求的圖像優化平臺，以保持 始終保持高性能，同時保持盡可能低的成本。 在撰寫本文時，我們將介紹當前的基礎結構，并介紹一些我們學到的有趣的知識，以便將其運用于此處。 ### 讓我們制作一個圖像優化器 您想開始在 CDN 帳單上省錢，并且通常通過將較少的字節通過網絡推送到用戶的瀏覽器來加快網站速度。 很有可能超過 [的流量有 60％](http://httparchive.org/interesting.php) 僅是圖像。 使用 ImageMagick（您確實讀過 [ImageTragick](https://imagetragick.com/) ，對嗎？），您可以使用以下簡單命令降低 JPEG 文件的質量： $ convert -quality 70 original.jpg Optimized.jpg $ ls -la -rw-r--r-- 1 matylla 職員 5897 5 月 16 日 14:24 original.jpg -rw-r--r-- 1 matylla 職員 2995 May 16 14:25 Optimized.jpg 恭喜。 通過屠宰 JPEG 的質量，您剛剛將其壓縮了約 50％。 圖像現在看起來像 Minecraft。 它看起來不是這樣-它可以銷售您的產品和服務。 理想情況下，Web 上的圖像應具有出色的質量，并且不會以過高的質量或 EXIF 元數據的形式出現不必要的膨脹。 現在，您打開自己喜歡的圖像編輯軟件并開始以 Q 級播放，同時將 JPEG 保存為 Web。 事實證明，您測試的這張特定圖片在 Q76 看上去很棒。 您開始以質量設置為 76 保存所有 JPEG。但是請稍等片刻...有些圖像即使在 Q80 情況下也看起來很糟糕，而有些圖像甚至在 Q60 時也很好。 好的。 您決定以某種方式使其自動化-誰想要手動測試您擁有維護“特權”的數百萬張圖像的質量。 因此，您創建了一個腳本，該腳本可以生成不同 Q 級別的輸入圖像的數十個副本。 現在，您需要一個度量標準，該度量標準將告訴您哪個 Q 級適合特定圖像。 MSE？ SSIM？ MS-SSIM？ PSNR？ 您如此絕望，甚至開始計算和比較輸入圖像不同版本的 [感知哈希](https://en.wikipedia.org/wiki/Perceptual_hashing) 。 有些指標的效果要好于其他指標。 對于某些類型的圖像，有些效果很好。 有些非常快，而另一些則需要很長時間才能完成。 您可以通過減少處理每個圖像的循環次數來逃脫現實，但是很可能您錯過了理想的 Q 級別，并且圖像要么重于原來的水平，要么質量下降過高。 那么在白色背景下的商品圖片呢？ 您真的想減少對象周圍的振鈴/暈影。 基于每個圖像的自定義色度二次采樣設置如何？ 如今，白色背景下的那件紅色連衣裙看上去已經被洗掉了。 您已經了解到，剝離 EXIF 元數據將使文件大小變小一點，但是您還移除了 Orientation 標簽，現在圖像旋轉不正確。 那只是 JPEG 格式。 對于您的 PNG，您可能想重新壓縮 7-Zip 或 Deflate 壓縮后的圖像，例如 Google 的 [Zopfli](https://github.com/google/zopfli) 。 您啟動腳本并觀看 CPU 上的風扇開始熔化。 您可能需要一個可靠的工具，該工具可以優化所有圖像，無論格式如何。 [Kraken.io](https://kraken.io/) 是一種這樣的工具。 ### 關于 Kraken.io Kraken.io 是圖像優化和壓縮 SaaS 平臺，具有其他操作功能，例如圖像大小調整。 我們的目標是盡可能自動縮小圖像的字節大小，同時保持視覺信息的完整性和始終如一的高質量，從而無需手動檢查結果的保真度。 ### 軟件 除了基于 PHP 的 Kraken.io 前端外，幾乎我們所有的軟件都是在 [節點](https://nodejs.org/en/) 中編寫的。 我們大量使用節點流，因為我們的優化管道可以使用二進制數據流。 當圖片首次出現在我們的平臺上時，首先會通過“ kraken-identify”過程進行抽簽，以可靠地檢測出最重要的功能-圖像格式（JPEG，PNG，GIF，SVG 等），圖像類型（逐行/ 基線 JPEG，動畫/靜態 GIF 等），以及嵌入的顏色配置文件和 EXIF 元數據的存在。 我們只需要讀取幾個字節，就不需要解壓縮整個圖像，也不需要將解壓縮的數據加載到內存中。 確定我們剛收到的文件確實是圖像后，我們將對其進行進一步處理。 對于某些特定的圖像，我們還計算了獨特顏色的數量。 唯一色計數是一種直方圖類型的操作，它固有的速度很慢，無法對壓縮數據進行處理，因此我們僅在非常特定的圖像子集上使用它。 然后，圖片會通過 HTTP 通過我們的優化管道傳遞。 這使我們可以將二進制數據（圖像本身）與優化設置（作為字段或標頭）一起抽取。 與我們的優化集群的 HTTP 連接保持打開狀態，直到該過程完成，并且來自集群的 HTTP 響應被流回磁盤（直接流回 GlusterFS 目標位置），因此我們不會經常接觸磁盤。 當我們從群集中流回整個響應時，任何優化后的數據都會通過 HTTP 標頭傳輸。 （可選），如果 API 用戶請求，我們可以將優化的資產存儲在他或她選擇的外部存儲中- [S3](https://kraken.io/docs/storage-s3) ， [Azure](https://kraken.io/docs/storage-azure) ， [云文件](https://kraken.io/docs/storage-cloudfiles) 或 [SoftLayer [](https://kraken.io/docs/storage-softlayer) 。 最后一個任務（用于 API）是終止與 API 客戶端的 HTTP 連接，并以優化結果作為響應，例如： { “ file_name”：“ sku126933.jpg”， “ original_size”：35761， “ kraked_size”：10799， “ saved_bytes”：22462， “ kraked_url”：“ https://dl.kraken.io/api/3e/db/24/08e20232a13c35fc1a72356537/sku126933.jpg”， “ original_width”：600， “ original_height”：600， “成功”：是 } 對立即解析響應正文不感興趣的用戶可以使用我們的 [Webhook 傳遞系統](https://kraken.io/docs/wait-callback) 。 通過在請求中指定 callback_url，用戶將指示 API 應用程序將優化結果 POST 到其自己的端點。 在這種情況下，我們排隊一個 Webhook 任務（使用 Redis 作為代理）。 僅用于 Webhook 交付的其他計算機從隊列中使用，POST 優化結果并將一些數據保存在 MongoDB 中。  在 Kraken.io 帳戶中交付了 Webhooks 視圖 ### 硬件 圖像優化和重新壓縮具有巨大的處理要求。 由于我們一直在努力降低總擁有成本，因此對我們而言，云決不是一個選擇。 通過與我們的數據中心簽訂相當長的合同，我們可以將托管費用減少 30％。 一小會兒，在投資購買自己的硬件之前，我們一直在租用專用機器。 那沒有按預期工作。 當時，我們的提供商阻止了 OS 的重新部署，我們不得不采用痛苦而費時的電子郵件通信路徑來重新部署系統。 另外，您不知道之前有誰在使用機器，機器的整體運行狀況如何，以及內部“確實”安裝了哪些組件。 有一天，我們發現，即使所有 API 機器都安裝了相同的 CPU，但每臺機器都有不同的 CPU 固件，并且 sysbench 的結果因機器而異。 幸運的是，這段時間已經過去很久了，我們在自己的硬件上運行，我們可以根據需要微調所有設置（嘗試對租用設備進行 CPU 頻率縮放）。 所有單插槽計算機（API，Web，負載均衡器，Webhook Delivery）當前正在運行 Xeon E3-1280 v5（Skylake）。 對于完成所有艱苦工作的 Optimization Cluster，我們每臺計算機使用 2 個 Xeon E5-2697 v3，具有 128 GB RAM 和 RAID-1 設置中的四個 SSD 硬盤進行鏡像。 在啟用 HT 的情況下，上述設置使我們可以在每個群集計算機上訪問 28 個物理核心和 56 個線程。  我們的優化人員之一（Xeon E5-2697） 英特爾最近為 [E5-2600 產品線](http://ark.intel.com/products/family/91287/Intel-Xeon-Processor-E5-v4-Family#@All) 推出了 v4（Haswell），我們正在對此進行研究，但并不急于將群集升級到 v4 。 Kraken.io 的平臺占用大量 CPU 和 I / O，對大量文件進行繁重的處理。 為了在 I / O 級別獲得更高的性能，我們將在接下來的幾個月中為 API，集群和存儲計算機推出 PCIe-SSD 驅動器。  API，存儲和優化集群 自己的硬件需要一定的價格。 而且這個價格是，即使在高峰時期，您也需要比實際需要的容量多很多。 訂購，壓力測試和部署新機器最多需要 7 天的時間。 我們提供了一個定制的 AWS 集成，它將為我們提供計算優化的實例并擴展優化集群。 幸運的是，即使我們發現集群計算機上的負載高達 60（每個線程 1.07），我們也從未使用過它。 該解決方案的缺點是，我們不僅必須為 AWS 實例支付額外費用，而且還必須為數據中心與 AWS 之間的額外流量支付額外費用。 ### 供應，發現和軟件部署 我們安裝的每臺新計算機都由 [工頭](http://theforeman.org/) 管理和配置。 我們將所有配置都保留在 [Puppet](https://puppet.com/) 中，因此只需單擊幾下即可使新機器進入生產就緒狀態。 在 Puppet 中維護健康的代碼庫是另一個需要討論的主題，尤其是在談論定制軟件包時。 通過 [Capistrano](http://capistranorb.com/) 進行軟件部署。 因為所有應用程序都是用 Node 編寫的，所以幾乎所有應用程序都使用類似的配方。 當我們需要查明過去發生的特定部署并將其與 [中的可用數據關聯時，與](https://www.serverdensity.com/) [Slack](https://slack.com/) 集成非常有用 ] ServerDensity 或 [ElasticSearch](https://www.elastic.co/) 。  Capistrano 的松弛集成 ### 數據存儲 我們在三臺獨立的機器上使用 [副本](https://docs.mongodb.com/manual/replication/) 設置中的 [MongoDB](https://www.mongodb.com/) 作為我們的主要數據存儲。 由于我們的數據集相對較小，并且我們對所有時間序列數據都使用了封頂集合，因此我們從未真正考慮過 DB 分片。 當然，看著三分之二的 DB 機器幾乎什么也不做，只是等待 Master 失敗，這不是我喜歡的事情，但是當時間到來時（而且會這樣），我們會睡得很好。 第二個數據存儲是 [前哨](http://redis.io/topics/sentinel) 設置中的 [Redis](http://redis.io/) 出于與上述相同的原因）。 主要用作 Kraken.io 前端上的任務隊列和會話管理的消息代理。 ### 文件存儲 在上一代 Kraken.io 中，我們曾經將優化的資產直接存儲在執行優化工作的同一臺計算機上。 在將角色（API，Web，處理群集和存儲）分離之后，我們發現自己迫切需要可擴展的網絡文件系統。 [GlusterFS](http://www.gluster.org/) 易于設置且易于維護。 從應用程序服務器到 GlusterFS 計算機，我們有數百萬個圖像通過網絡傳輸。 對于我們而言，非常重要的一點是不要經常移動這些文件。 一旦保存在 Gluster 中，圖像將停留在該位置，直到其自動刪除為止。 說到-清理作業。 通過 API 優化的圖像會在 1 小時后自動刪除，而通過 Web Interface 處理的圖像會在我們的系統中保留 12 個小時。 在存儲計算機上運行的清除腳本需要首先統計所有目錄，并選擇 mtime > 1hr（或 mtime > 12hr 的 Web Interface）。 當您擁有數百萬個目錄時，對其進行簡單的統計可能會花費大量時間，并且我們希望清理腳本能夠快速運行。 可行的簡單補救措施是將具有優化映像的目錄放入另外三個級別的兩字符目錄中。 用作目標目錄的原始文件 ID，例如 dd7322caa1a2aeb24109a3c61ba970d4 變為 dd / 73/22 / caa1a2aeb24109a3c61ba970d4 這樣，我們最多可以在第一，第二和第三層上遍歷 255 個目錄。 ### 負載均衡器 外部和內部負載平衡器都是 [Nginx](http://nginx.org/) -基于 [Keepalived](http://www.keepalived.org/) 。 即使我們的兩個外部環境都出現問題，內部的環境也會自動提升自己，也為公共交通服務。 這也有助于我們晚上入睡，并給我們時間用新機器從柏林到法蘭克福旅行（飛行 1 小時）。 我們在內部計算機上未使用任何 HTTP 服務器。 所有內部流量都從負載均衡器直接反向代理到 Node 應用程序。 要記住的一件事-Nginx 默認使用 HTTP 協議 1.0 作為 HTTP 代理。 將 proxy_http_version 標志設置為 1.1 可以節省很多麻煩，并且通常可以提高性能，尤其是對于長時間運行的保持活動連接。 ### 聯網 由于我們在上行鏈路級別（兩個獨立的 10 Gbps 上行鏈路）上也很冗余，因此每個機架至少需要兩個交換機，每臺機器至少需要兩個以太網控制器。 隨著機架的增長，每臺計算機占用交換機上的五個端口（BMC，到控制器 1 的上行鏈路 A 和 B 和到控制器 2 的上行鏈路 A 和 B），當前我們在每個機架上運行四個 HP ProCurve 交換機。  Kraken.io Architecture，2016 年 5 月 ### 監視和警報 在上一代 Kraken.io 中，我們使用了 Sensu，Graphite 和 InfluxDB。 由于我們想將全部注意力轉移到產品本身，而不是維護和監視監視工具（誰在監視正在監視它們的監視工具？），因此我們需要一種 SaaS 來減輕這種痛苦。 在測試了幾項服務之后，我們最終選擇了 [ServerDensity](https://www.serverdensity.com/) 作為我們所有機器的主要監視和警報工具，并且到目前為止，它仍然可以正常工作。  ServerDensity 指標始終顯示在我們的辦公室中 作為一項附加措施，我們使用 [Pingdom](https://www.pingdom.com/) 進行正常運行時間和實時用戶監視。 我們已經從 Pingdom 看到了一些誤報，而解決之道只是增加警報失敗所需的檢查數量。 ### 數據挖掘 當我們嘗試將支持的技術數量保持在最低限度時，我們使用了外部 ElasticSearch 提供程序。 平均每天，我們會發送 2GB 的日志以進行進一步處理和數據挖掘。 可以這樣查詢 ES 非常方便： “為我提供 800 Kb 以下的 JPEG 文件的優化結果，該文件具有嵌入式 ICC 配置文件，唯一顏色計數大于 10.000，用戶 X 在 3 天前進行了無損優化”。 在我們不斷努力改進優化堆棧時，我們需要能夠立即跟蹤我們的部署結果。 在峰值負載下，只需在“優化群集”中進行一些細微調整即可，然后在幾分鐘內獲得有意義的數據。 ### 摘要 如果您到目前為止做的不錯，那將涵蓋 Kraken.io 基礎結構工程的有趣部分。 我們確信，隨著我們的發展和訂戶數量的增長，我們將繼續學習更多，希望您喜歡本文。 [關于 HackerNews](https://news.ycombinator.com/item?id=11910151) 我總是喜歡閱讀有關圖像優化的文章。 但是在本文之后，我檢查了 kraken.io 網站，以及所有可用的信息... :( 總體來說不錯。 盡管看到整條文章中散布著大量的“流行語”，這似乎是一種絕技。 不過，請欣賞本文的坦率。 對于正在為其 Web 應用程序尋求圖像優化服務的人的旁注-現代 CDN 已經將此作為其產品的核心部分。 Instart Logic 特別提供了出色的圖像優化服務，您可以利用專有算法利用它來轉換圖像，調整圖像大小并降低圖像質量。 您可以在構建時壓縮和縮小映像，然后可以由您選擇的任何 CDN 進行選擇。 這個過程已經使用了數十年。 這是我們今天在 [CircleHD](https://circlehd.com "CircleHD") 使用的一些工具 gifsicle-壓縮 GIF 圖像 jpegtran-壓縮 JPEG 圖像 optipng-壓縮 PNG 圖像 svgo-壓縮 SVG 圖像 @AgnivaDeSarker：我很好奇您在上一篇文章中有什么資格成為“流行語”？