转载

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。

正文到此结束