架构设计：系统存储（19）——图片服务器：需求和技术选型（1）

作者简介：大家好，我是smart哥，前中兴通讯、美团架构师，现某互联网公司CTO

联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬

学习必须往深处挖，挖的越深，基础越扎实！ 

1、概述

图片服务系统是各种针对C端系统常见的子系统，它的特点是存储规模大请求频度高，且单张图片的读请求远远高于写请求。后续几篇文章我们将从图片服务系统的需求分析开始，一起来讨论如何进行这类系统的技术选型、概要设计和详细设计，以及在这个过程中需要关注的技术难点。

虽然由于写作计划的变化，图片服务系统中所涉及的分布式文件系统原理、非关系型数据库原理都还没有讲到，但这些知识点也并不是组成整个图片服务的所有关键点，并且后续的文章中我们会尽快补上对这些知识点的介绍。图片服务系统的讲述会分为四篇文章，前两篇文章我们主要分析图片服务的需求、架构选型和技术方案，后两篇文章进行性能优化和详细设计部分的讲解。由于不能讲解全部的详细设计，所以文章会在最后将整个示例工程的源代码放置在网络上，供有兴趣的读者进行下载。

2、需求场景

首先我们给出使用这个图片服务的场景，以便后续内容中根据这个需求场景进行初步架构设计、详细架构设计、技术选型，以及服务中各个功能模块的设计等工作。这是一个中等规模的针对C端的电商服务站点，日平均PV量在百万级别 。电子商务类型的站点，其特点是一张页面上会出现多张图片，而且基本上不会使用原图而是大量使用缩略图；另外，多个用户经常同时访问同一个页面，所以不但需要使用缓存，而且缓存一般都有多级，否则会产生大量重复的物理I/O请求；最后，这样的电商平台图片服务都属于顶级业务服务，图片规模基本都是以TB计算，小一些规模的也有几个TB，规模更大的可能达到PB级别。

产品团队针对图片服务的基本功能要求是：需要 支持单张或者多张图片上传 ，这样可以为站点运营人员/商户增强编辑体验，提高工作效率。另外需要在一些特定场景支持水印功能和图片特效功能，但这是优先级较低的功能，而 图片的动态缩放 则是必备功能，这是 因为在站点的各种页面上都基本上不会使用原图 而是使用各种等比缩小或中心截取的缩率图片，另外一个原因是一张图片会在各种客户端设备上显示，最常见的是IOS、Android和浏览器，而这些终端设备对图片的像素要求都是不一样的。产品团队针对图片服务的另一个基本要求是 支持图片访问统计和报表 ，这个功能倒不是给终端用户使用的，而是给站点的运营团队准备的。通过访问统计和用户上传图片的报表统计，运营团队可以针对这些基础数据掌握每月的图片热点，而且这些数据可能还会为后期的数据分析所使用。

接着在与需求团队的沟通过程中，技术团队还推导了一些重要的非功能性需求，例如该图片服务属于整个站点的一个顶层子系统，所以需要保证7 * 24小时不间断运行，换句话说至少需要99.999%的稳定性；另外，图片服务的设计需要满足现有图片数据的割接，最好能够实现原有系统特别是存在在磁盘上的图片的无缝割接；最后，整个系统至少需要30%的冗余存储空间，保证技术团队有足够的时间和空间进行后续的技术改造。。。

3、技术问题和选型

那么图片处理系统要关注的主要问题是什么呢？首先是高并发下的图片处理性能问题。图片处理是一项计算密集型操作，例如目前流行的图片缩放算法就有临近值法、双线性插值法、多项卷积法等，图片锐化算法多为拉普拉斯锐化法，图片增强算法可以采用中值滤波法、直方图均衡法或者幂变换法。这些算法都对CPU计算资源和内存资源有较高的要求，特别是高并发请求背景下。而JAVA语言相对于C/C++语言在各种算法执行效率上又有先天的劣势，所以如果不能在性能上进行弥补就需要找到其它在高并发请求背景下加快图片处理效率的办法。其次是图片存储的问题，和存储稳定性安全性的问题。产生这个问题的原因已经在上文中进行了说明，这里就不再进行追溯了。接