如图，这是一个最简洁的架构。

在这个架构里，负载均衡器都可以省了，用最为廉价的dns来替代，dns的优点就是廉价，不用维护，也不愁性能和稳定，还可以跨机房多用几条带宽作分流。 另外，在图片服务中，可以选择用另一个域名做dns。优点是主站中的任何cookie等header不会带到图片服务中，省了不少上传流量和服务器可能有 的处理时间；缺点是多花了点域名的钱。目前门户都喜欢用这办法，小站用的话，用另一个域名还附带有一个特别的优点：因为部分域名服务商允许添加的二级域名 有限，所以用别的域名可以节约有限的域名资源。dns这一块也可以用泛域名，不过貌似国内的泛域名支持不是特别的稳定，有些网站的泛域名，在linux下 不能解析windows就正常，比较奇怪，我也没法解释。

在这个架构里我总共开了36个域名，但是一时没有那么多机器，所以有一些域名指向同一台机器。一般来说，一个刚上线的项目，放一台机也未尝不可，但是链接（包括域名）一定要固定下来，不然以后调整会非常痛苦。

域名的事情还是比较简单的，只要照着填写web表单就完成了，配置四台nginx服务器当然也是非常简单的，因为不需要什么特殊的功能，所以四台机用同一 个配置，写一个root根目录和expires就完成了。expires可以大胆地配置一年expires 1y，或10y甚至expires max都没什么问题，因为假如客户端认为图片有误，他会按F5刷新，F5会跳过expires向服务器发送if-modified-since头，和服务 器的源文件修改时间对比，假如一样，服务器返回一个304表示没有更新，否则会重新下载该图。

在这个架构里难处在于分发和管理图片，所以hash结构比较适合于在论坛、博客等用web浏览器上传的场合使用。用浏览器上传图片后，只需要用动态语言创 造一个hash的文件地址，保存在上传机器上，然后使用rsync分发到四台图片服务器就可以了。在我这个架构里分了36个字母和数字，是给md5编码用 的，md5图片存档地址可类似/7/5/2/23AE809DDACAF96AF0FD78ED04B6A265E05AA257.jpg，这样这张图片 就会分配到这个架构的第4台机器。有些系统的图片是用当前时间或自动ID算出来的，hash结构可为图片ID%100叫求余数，相应的dns配置为纯数字 就可以了，hash办法可以很多样，最紧要就是图片量要分得均匀，点击量不均匀倒是其次。删除的时候也不难办，给定一个图片地址，就很容易知道它在哪台机 器，然后在这个地址写一个空文件，用rsync同步到图片服务器。

假如不是web浏览器上传的图片，而是用ftp上传的，就不适合使用这个架构，强行使用这个架构的话头还是自己的疼啊，可以使用这个架构试试，不久的将来我会再写一个最简单的架构。hash架构也有一个要命的缺点，就是这几台机器的硬盘虽然都不容易满，但是都快满的时候（它们一般是同时满的），就得为每台机都增加硬盘空间或增加一倍的服务器。

在这个最简单的hash架构上，没有设计任何保护措施，所以有一台服务器硬盘损毁，会造成1/4的图片无法访问；同时也先不讨论数据备份的问题。简单有简单之美，复杂的事情留待高人解决。