Imgix技術棧解密：每秒可對外提供10萬張圖片

什么是 Imgix？

Imgix 是一項進行圖像實時處理和傳輸的服務，授權給企業和開發者用以優化圖像。借助簡單的 URL API 接口，Imgix 可以實時抓取、傳輸圖像，并通過 CDN 將圖像提供到世界各地。個人用戶在使用時可以無限量地動態生成圖像，從而不必在本地儲存大量的圖像。圖像剪裁、大小調整等動態調整過程防止了網頁過于臃腫，保證了網站精煉簡潔。

技術挑戰 
Imgix 擁有超過 80 個 URL 參數，這些參數用于調整復雜的圖像處理效果。Imgix 可以調節壓縮比和色度抽樣率，進行色彩量化等操作。另外， Imgix 能夠同時響應多個輸入，輸入圖像的來源（瀏覽器、手機、平板電腦、顯示器）也可不同。目前，影響圖像輸出結果的參數和輸入的絕對數目仍在快速增長。

設計 Imgix 架構時的前提假設是，收到的圖像請求不能被緩存，而且必須動態創建。這一點徹底改變了 Imgix 服務的提供方式和評判標準。多年來，Imgix 架構被反復修改，現在已經能夠做到每秒處理超過 10 萬個的圖像，其中 90% 的輸入文件大小大于 4.5MB。Imgix 用最快的速度、最少的成本提供了質量最好的圖像。未來，Imgix 還希望把每秒處理的圖像數量提高到 100 萬個以上。

技術棧揭秘 
Imgix 的核心架構由多個服務層組成，包括原圖抓取層、原圖緩存層、圖像處理層、負載平衡及分配層、以及內容傳輸層。每個服務層都有遍布全局的配置、日志記錄、監視及管理服務。

原圖抓取層和緩存層使用了定制的 MogileFS、nginx、HAProxy 作為底層技術。負載平衡及分配層則基于自定義C代碼和自主開發的 LuaJIT 框架（名稱為 Levee）。Levee 能夠在一臺機器上每秒處理 4 萬個請求。將以前的一些由 Python 處理的服務轉為用 LuaJIT 框架處理后，性能提高了 20 倍。當技術成熟之后，Levee 還將開源。網絡邊界管理則同時使用了 HAProxy、nginx 和 OpenResty。圖像處理層的高性能圖像處理服務器使用C、Objective-C 以及 Core Graphics 搭建。在 GPU 中的圖像處理操作時間小于 1ms，提升性能的工作主要是對網絡接口/本地內存的緩存到 GPU 紋理緩沖器這一步進行路徑優化。由于圖像完全契合 GPU 紋理緩沖器，點對點處理時間的范圍小于 50ms。圖像處理層的所有更改都將進行一系列回歸分析測試，以保證每次更改不會對圖像處理結果引入視覺可辨的差異。最后的內容傳輸層使用了 Fastly，通過 Vanish 工具進一步優化了流量控制。全球 20 多個 Fastly POP 使得 Imgix 的用戶可以快速獲取圖像。各個服務層之間的有序協作將 90% 首次抓取、未經緩存的圖像在高峰時期的點對點響應時間縮短到了 700ms 以下。

Imgix 每個服務層的日志記錄十分重要，因此需要建立全面的日志生成流水線。Heka 用于處理大部分數據行集合，并將處理后的實時數據、統計數據、分析數據分別發送給 Riemann、Hosted Graphite 和 Google BigQuery。

Imgix 管理和監控堆棧使用了幾項開源項目：Ansible 用于配置管理，Consul 用于服務發現，Prometheus 用于網絡監控，StatusPage.io 用于給用戶報告架構當前的狀態。

Imgix 網頁的前端服務完全與核心架構隔離。頁面搭建主要根據需求使用 Angular、Ember 或 Tornado，這些工具提供了配置及管理 Imgix 賬戶的網頁接口。Imgix 還分別為每一個前端項目的開發、測試、制作提供了 Docker 容器。另外還有 CircleCI 用于內部服務，Travis CI 用于管理開源項目和庫。

Imgix 不斷地整合集成，一天內常進行多次部署。Imgix 的開發使用 GitHub 管理每項服務的代碼倉庫，使用 Trello 作為團隊規劃管理工具。項目討論在 Slack 群組聊天軟件上進行，不過更多的時候，討論直接就茶水間中完成了。

2013 年，蘋果公司發布了更符合 Imgix 需求的硬件設備——Mac Pro。現在，Imgix 的數據中心用 46U 機柜搭建了 Mac Pro 圖像處理節點群。這種機柜整合方式比起大多數基于 Linux 的解決方案，大大節約了占地面積，減少了耗電量。Imgix 宣稱其從內而外都優于運行在 EC2 上的 ImageMagick。