09年初的时候, 百度阿拉丁计划展现更多的图片. 这些图片一般较小, 适合在搜索页面中展现.  这些图片一般来自百度的合作方, 合作方提供的图片是多种多样的, 格式大小各不相同. 为了能让这些图片在百度页面中合适的展现,必须对图片做一定的裁剪.

考虑到以上种种问题, 直接使用合作方的图片是不行的, 必须做一个专用的图片服务, 来满足以上种种需求.

当我们着手设计这个产品时, 首要的一条就是简单,尽可能的复用已有的东西. 浏览器支持的是http协议. 因为产品使用的接口都是http协议, 包括后台的一些管理操作.  

因为产品与浏览器的交互非常简单, 我们没有必要开发一个单独的http服务器, 只需要选择一个开源的服务器, 如apache, light 等, 稍微修改一下就可以使用了.  我们最后选择的百度自己的网页服务器. 因为它足够简单, 而且我们的开发人员对它也更熟悉.

接下来是图像处理模块.  在百度内部有相当多的产品线用到了图像处理模块. 我们根据使用经验, 选择了一个较稳定的Magic.

最后是cache. 几乎在所有的互联网产品中, cache都是需要重点考虑的. 在本文中尤其如此.  图片很小, 意味着不大的内存就可以存储很多图片; 可以想见, 图片访问的集中度会很高,这也是互联网产品的一大特色.  因此使用cache绝对划算.  在本文中,甚至所以的数据都是放在cache中的. 这里我们使用了百度内部的一个组件zcache.  zcache是一个分布式的cache服务. 它同时使用了内存和磁盘, 用来存储图片数据是够用的.

还有抓取, 这里我们使用了非常流行的curl库来完成抓取图片的工作.

整体来看, 我们就是在zcache服务上加了一个http协议的壳. 使得zcache能够通过http协议提供图片服务. 结构虽然简单, 但是效率却很高. 包括开发效率和性能.

以上的设计确有一个缺陷, 这个缺陷在性能要求不高时还不太明显, 随着流量越来越的. 这个缺陷的问题就逐渐暴露出来.  在以上设计中, zcache是一个性能好,延时短的服务. 这样只要请求中cache, 就能立刻返回; 但是当不中cache时, 需要去服务器上抓取图片, 再返回给浏览器. 这种情况下, 响应就很慢.  为了保证较慢的请求也能得到处理. 我们设计了一个较长的队列和多个抓取线程来处理抓取任务.

把时延短的请求 和 时间长的请求在一个程序中处理, 当多个时延长的请求到达时, 会使得所有的抓取线程都处在工作状态, 而挤占了中cache的线程的处理时间. 导致所有的请求都被拖慢.

这种问题出现的另一个原因是多个抓取线程是同时工作的, 而实际上抓取线程因为没有获取到数据, 大部分时间在空转.

解决这个问题有两种办法. 一是修改抓取的工作方式, 改为dispatcher模式, 统一管理所有的抓取socket, 只有当数据到来时, 才唤醒对应的工作线程处理数据;  另一种是将抓取与cache 彻底分离, 使用单独的服务专门处理抓取任务.

考虑curl抓取在处理抓取逻辑上的不足, 我们选择将抓取独立出来, 使用独立的模块单独负责抓取.

为了保证服务的稳定性, 我们部署了多套相同的cache服务, 避免cache单点问题. 这种冗余服务在高稳定性要求的服务部署方案中是大量存在的. 多套相同的cache服务, 在查询时只要在一个cache中查询到数据, 即返回数据; 在更新时, 需要将数据同时更新到多套cache中.  在线上部署时, 共部署了两套cache.

以上总结了一个小的产品在设计过程中的一些技术选型和修改的思路. 希望能给大家一些帮助