在当前这个互联网的时代，不管何种网站，对图片的需求量越来越大，尤其在电商网站中，几乎都会面临到海量图片资源的存储、访问等相关技术问题。在对图片服务器的架构，扩展，升级的过程中，肯定也会碰到各种各样的问题，各种各样的需求。当然这并不代表，就必须得弄一个特别NB的图片服务架构，简单，高效，稳定就行。所以今天就来总结一个特别简单，高效的图片服务架构：通过共享存储的方式来实现图片服务架构。

 

　　然而，也有一些人问我，现在大型网站的图片服务器的架构已经完全不是这样的了，别人家的图片系统，比你这个牛逼多了，为啥不直接写那个呢？ 事实是：第一，大型牛逼的系统我也不会，第二， 再牛逼的系统也是从小的架构演化过去的，没有一步到位的。这里介绍图片服务器架构虽然比较简单，但也是经过了单机时代的演化了，基本上可以满足中小型分布式网站的需求。这种架构的搭建和学习成本，都极低，符合目前“短平快”的开发模式。

 

　　通过共享目录的方式实现共享存储 ，在共享目录文件服务器上配置独立域名，这样将图片服务器和应用服务器进行分离，来实现独立图片服务器。

 　  优点：1  将图片服务和应用服务分离，缓解应用服务器的I/O负载。

　　　　　2. 通过共享目录的方式来进行读写操作，可以避免多服务器之间同步相关的问题。

　　　　　3. 相对来讲很灵活，也支持扩容/扩展。支持配置成独立图片服务器和域名访问，方便日后的扩展和优化。 

　　　　　4. 相对于更加复杂的分布式的NFS 系统，这种方式是性价比高，符合目前互联网的“短平快”的开发模式。

　　缺点 ：1. 共享目录配置有些繁琐，

　　　　　 2. 会造成一定的（读写和安全）性能损失。

　　　　    3. 如果图片服务器出现问题，那所有的应用都会受到影响。同时也对存储服务器的性能要求特别高。

　　　　    4. 图片上传操作，还是得经过Web服务器，这对Web服务器还是有巨大的压力。

 

　　其实架构也非常简单，基本架构如下图所示：

 　　

 

　　1. 在存储服务器上建立一个共享目录（具体方式，我就不去重复了，自己百度吧，注意共享目录的文件安全）。

　　2. 各个应用直接通过共享目录（\\192.168.1.200）,将图片上传到存储服务器上。

　　3. 建立一个web站点（i1.abc.com）将该共享目录通过web站点发布出去。这样其他的应用就能访问到相关图片。

 

　　所以，各应用，将文件上传到共享目录

//保存原图 　　　　//完整的地址：\\192.168.1.200\lib\2016\03\04\10\IMG\4ugvvt6m9gdu.jpg 　　　　relativePath = relativeDir + fileName + imageExtension;       var absolutePath = ConfigHelper.SharePath + relativePath;       fileData.SaveAs(absolutePath);

 

　　上传成功后，可直接通过web 的方式访问：

　　http://i1.abc.com/lib/2016/03/04/10/IMG/4ugvvt6m9gdu.jpg