電商總結（四）基於共享存儲的圖片服務器架構

　　在當前這個互聯網的時代，無論何種網站，對圖片的需求量愈來愈大，尤爲在電商網站中，幾乎都會面臨到海量圖片資源的存儲、訪問等相關技術問題。在對圖片服務器的架構，擴展，升級的過程當中，確定也會碰到各類各樣的問題，各類各樣的需求。固然這並不表明，就必須得弄一個特別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