当我们将目光从单一机器的解决方案转移到多台机器组成的服务网络时，问题一下子变得复杂起来，虽然对于初期的网站您完全可以不用考虑到这些，但是作为一个持续演进的解决方案，那么就来看看应对更大业务规模的处理方案。
随着网站的运营，我们首先面临的是图片存储空间的增长，把所有的图片都放在一台机器，时间长了必定会出现存储空间不足的情况，这时候你有两种方法来解决问题：
1. 为服务器增加硬盘
2. 增加新的服务器
方案1是最简单的，通过升级硬件来解决问题，我们称之为“Scale-up”，但单一硬件的能力毕竟是有限的，我们不可能在一台PC服务器上没有限制地增加硬盘空间，通过提高硬件配置只是暂时的应急之策。方案2是大多互联网解决方案推荐的，我们称之为“Scale-out”，因为业务增长对于硬件的需求是线性增长的，而方案1则是指数级的增长。
我们并无意耗费太多的时间去探讨“Scale-out”和“Scale-up”的优点和缺点，对于互联网公司，我们的设计目标很明确：所有的增长要通过增加服务器而非提高服务器配置来解决。那么如何让图片服务能够支持scale-out呢？
首先，我们来看现实情况里业务是怎样演变的：
n 图片数据随时间增长
每天都会有用户上传新的图片，可能是更新相册，也可能是论坛中的附件，假设每天用户上传5000张相册的照片，1万张文章内的照片，以每张图片100K来计算，每天的图片数据增长是1.5个G，每个月下来接近50G的增长
n 图片数据随业务用途增长
除了用户照片，文章照片，随着业务的拓展，可能会出现TIFF文档、传真等其他业务，随着业务的增加，相对应需要的存储空间也会增加。
其实并不要再说更多，图片服务所需的存储空间随着时间而增长，同时随着活跃用户而增长，也就是说从理想的情况来说，您的图片服务存储是需要考虑到指数级的增长，而不是单纯依赖时间的线性增长。
在这样的业务假设下，我们需要图片服务的存储架构满足下列条件：
n 可以通过增加新的廉价硬件来解决存储空间不足的问题
n 在增加硬件的过程中保持一个比较低的运营维护成本
首先，我们来讨论一些存储的基本概念。存储分类（如下图）根据服务器类型分为：封闭系统的存储和开放系统的存储，封闭系统主要指大型机，AS400等服务器，开放系统指基于包括Windows、UNIX、Linux等操作系统的服务器；开放系统的存储分为：内置存储和外挂存储；开放系统的外挂存储根据连接的方式分为：直连式存储（Direct-Attached Storage，简称DAS）和网络化存储（Fabric-Attached Storage，简称FAS）；开放系统的网络化存储根据传输协议又分为：网络接入存储（Network-Attached Storage，简称NAS）和存储区域网络（Storage Area Network，简称SAN）。
由于目前绝大部分用户采用的是开放系统，其外挂存储占有目前磁盘存储市场的70%以上，因此我们也只讨论关于DAS、NAS和SAN。如下图：
详细的技术介绍请参考：http://www.it.com.cn/f/server/053/21/89080.htm。我在这里不做重复的介绍。
那我们再回过头来考虑我们实际的业务特点，因为任何解决方案没有最好的，只有相对来说合适业务自身需要的：
1. 我们需要大量的存储空间
2. 因为是互联网服务，能够允许部分的数据错误和缺失（当然了，老出问题就没有人用了
3. 大多基础服务不是和收入直接关联的，所以要尽可能的便宜，毕竟我们的预算有限
4. 在机器增加的时候需要控制住管理和维护的复杂性，否则会出现硬件投入可控，人力投入不可控的情景（您总不希望需要有一堆的运维人员来维护这些机器吧？）
5. 在不考虑零故障的情况下我们要尽可能保证服务的可靠性（什么叫可靠？在出现灾难故障的时候我们能够恢复，至少能够大部分恢复，在出现故障的时候我们能够尽快恢复）
那我们来总结一下DAS,NAS和SAN的特点，从而为我们的服务器存储设计提供一个参考：
ü DAS：简单一点地理解，通过给PC服务器（我们这里不讨论小型机或者大型机，对于大多互联网公司来说，所需要的费用将是不可承受的）增加硬盘或者增加一个磁盘阵列，这相当于我们有了一台服务器，但是有着比较大的空间（通常不超过2TB），如果对于业务压力和存储空间在未来的3年之内可以控制在这个限度之内，这是最简单的方案，你还是可以理解为这是单机的解决方案
ü NAS：简单地理解把所有的数据存储在网络共享的服务器上，这就允许前端的图片服务器可以有多台，而数据的集中存储可以明显地降低我们的维护成本
ü SAN: 大多应用到SAN的架构都是需要比较高安全性和可靠性的，当然了，另外一个显著的特点是价格比较昂贵
为此，从可扩展性、可管理性来考量的话，NAS存储架构是最适合我们的图片服务的，更简单地说，我们将要把图片服务的存储设计成基于网络的，基于NAS我们还有两种选择：
如上图所示，所有的图片服务器和文件服务器通过网络连接，每一个文件服务器只存储部分的图片，而File Server 1—N合起来存储着完整的图片服务，Image Server根据业务的实际情况访问相对于的文件服务器，这个时候我们可以将其理解为文件存储是分部的，就如同Memcached一样，只是分布式的策略在客户端（Image Server）上控制，这样做的优势在于我们能够通过修改分布策略方便地增加文件服务器，此时在存储空间上的投入是线性增长的。
我们再来看真正意义上的NAS又应该如何设计：
从逻辑上来说，所有的应用（Image Server）访问通过网络访问通一个NAS服务器，而NAS则管理着磁盘阵列柜，此时对于应用而言，只需要一个网络访问的地址就可以，所有存储管理策略由NAS服务器来完成，对于应用客户端可以忽略背后的技术细节，从管理层面来说也是如此，因为所有的存储是由NAS服务器来统一管理的，应用也不需要去关心。
从成本上来说，方案一是最廉价的，因为我们可以用清一色的PC服务器来搭建，而不需要专业的设备，但是在节点应用访问节点（Image Server）增加的情况下，管理的复杂度是N * N，而方案二因为进行了集中管理，则可以降低管理成本，随之带来的是需要专门的硬件投入。
分析到此，我们可以看到存储设计的一些原则了：
l 通过应用服务器（Image Server）的分散策略降低单一服务器的压力（CPU、IO）
l 通过增加单一存储服务器的处理能力来降低管理成本
针对更大规模的应用，我们也可以从这两个方向来优化整体的存储的硬件结构，从我个人的建议来说，如果您的业务相对比较简单但是流量很大，可以采用方案一，如果业务很复杂，从管理和维护的角度考虑，采用方案二。如果两者兼备，那就采用方案一和方案二的混合设计。
在讨论完存储层的硬件考虑之后，我们继续来探索软件层面的设计，从而保证能够适应这种动态的增长。在本文的第一部分，我们提到了根据业务将图片存储到不同的目录，同时根据一个指定的策略对文件进行散列，这样做的目的只有一个，就是为了让我们的文件存储更加契合业务本身的需要。
我想不管我们的设计考虑是怎样的，最终的目的就是为了能够快速地存储和读取图片文件，而关键的性能瓶颈在于I/O，我们所做的一切调整正是为了让I/O更加合理，分目录也好，分服务器也罢，都是为了将I/O的压力分散。
而哪些是I/O设计考虑的基本原则呢？我列举了下面几条：
1． 在主流的文件系统（如NTFS、Ext2），尽量不要在单一目录下超过10000个文件
2． 文件目录树不宜太深，比如超过10层
3． 完整文件名不宜太长
4． 如果服务器有多个磁盘，尽量将文件分散在多个磁盘，毕竟每一个磁盘的I/O能力是有限的（这很大程度上取决于硬盘的转速）
5． 尽量把访问频率高的数据放在性能高的磁盘系统上
6． 如果通过网络访问（FTP、NFS…），需要考虑socket连接的成本
……
我们提到的把用户和文章的图片分目录存储，深入一步探讨的话就是存储到不同的磁盘上，甚至存储到不同的服务器上，至于是用怎样的协议（本地文件、网络共享、FTP甚至远程的HTTP服务如flickr,google pissica）对于客户端而言应该是通明的。而文件散列的方式（md5哈希还是基于时间策略或者其他的），也应该是灵活的，我们的设计目标应该是灵活的，为了达到这个目的，我们需要改善我们的存储，使之成为一个通用的存储服务（Universal Storage Service），不管我们的硬件存储架构如何改动，我们通过调整配置的方式都能够去适应它。
我们可以通过统一的Storage Manager来管理这些不同的Storage Provider，根据业务的实际需要将转发到不同的StorageProvider，至于具体的设计实现，可以根据不同的需要进行调整。
文章到此，我们已经更加详细地讨论了在存储上的设计，而如何编写自己的Storage Service，我没有给出具体的解决方案，一个是考虑到并不是所有的应用都需要写到这个程度，另外是不同的业务也会有不同的考虑，所以只是给出了深度设计中需要考虑的一些问题和思路。
到目前为止，我们的讨论都是在逻辑设计的层面提出了一些思考和讨论，并没有针对具体的性能问题提出解决方案。既然整体设计已经完毕，后续的文字就是要让我们的服务变得更加“可用”，我不会再用这种渐进式的讨论，而是采用最佳实践的方式去在服务器的配置、部署和管理上优化我们的服务。
继续阅读：
l Web Secret：图片服务（一）——构建一个基本的图片服务
l Web Secret：图片服务（二）——扩展您的图片服务
l Web Secret：图片服务（三）——为您的服务加上缓存
l Web Secret：图片服务（四）——重新设计您的存储架构
l Web Secret:图片服务（六）——优化您的用户体验
联系客服
