深入分析阿里云中圖片服務的架構經驗

現在幾乎任何一個網站、Web App以及移動APP等應用都需要有圖片展示的功能，對于圖片功能從下至上都是很重要的。必須要具有前瞻性的規劃好圖片服務器，圖片的上傳和下載速度至關重要，當然這并不是說一上來就搞很NB的架構，至少具備一定擴展性和穩定性。雖然各種架構設計都有，在這里我只是談談我的一些個人想法。

對于圖片服務器來說IO無疑是消耗資源最為嚴重的，對于web應用來說需要將圖片服務器做一定的分離，否則很可能因為圖片服務器的IO負載導致應用崩潰。因此尤其對于大型網站和應用來說，非常有必要將圖片服務器和應用服務器分離，構建獨立的圖片服務器集群，構建獨立的圖片服務器其主要優勢：
1）分擔Web服務器的I/O負載-將耗費資源的圖片服務分離出來，提高服務器的性能和穩定性。
2）能夠專門對圖片服務器進行優化-為圖片服務設置有針對性的緩存方案，減少帶寬網絡成本，提高訪問速度。
3）提高網站的可擴展性-通過增加圖片服務器，提高圖片服務吞吐能力。

從傳統互聯網的web1.0，歷經web2.0時代以及發展到現在的web3.0，隨著圖片存儲規模的增加，圖片服務器的架構也在逐漸發生變化，以下主要論述三個階段的圖片服務器架構演進。

初始階段

在介紹初始階段的早期的小型圖片服務器架構之前，首先讓我們了解一下NFS技術，NFS是Network File System的縮寫，即網絡文件系統。NFS是由Sun開發并發展起來的一項用于在不同機器，不同操作系統之間通過網絡互相分享各自的文件。NFS server也可以看作是一個FILE SERVER,用于在UNIX類系統之間共享文件，可以輕松的掛載(mount)到一個目錄上，操作起來就像本地文件一樣的方便。

如果不想在每臺圖片服務器同步所有圖片，那么NFS是最簡單的文件共享方式。NFS是個分布式的客戶機/服務器文件系統，NFS的實質在于用戶間計算機的共享，用戶可以聯結到共享計算機并象訪問本地硬盤一樣訪問共享計算機上的文件。具體實現思路是：

1)所有前端web服務器都通過nfs掛載3臺圖片服務器export出來的目錄，以接收web服務器寫入的圖片。然后[圖片1]服務器掛載另外兩臺圖片服務器的export目錄到本地給apache對外提供訪問。
2）用戶上傳圖片
用戶通過Internet訪問頁面提交上傳請求post到web服務器，web服務器處理完圖片后由web服務器拷貝到對應的mount本地目錄。
3）用戶訪問圖片
用戶訪問圖片時，通過[圖片1]這臺圖片服務器來讀取相應mount目錄里邊的圖片。

以上架構存在的問題：
1）性能：現有結構過度依賴nfs,當圖片服務器的nfs服務器有問題時，可能影響到前端web服務器。NFS的問題主要是鎖的問題. 很容易造成死鎖, 只有硬件重啟才能解決。尤其當圖片達到一定的量級后，nfs會有嚴重的性能問題。
2）高可用：對外提供下載的圖片服務器只有一臺，容易出現單點故障。
3）擴展性：圖片服務器之間的依賴過多，而且橫向擴展余地不夠。
4）存儲：web服務器上傳熱點不可控，造成現有圖片服務器空間占用不均衡。
5）安全性：nfs方式對于擁有web服務器的密碼的人來說，可以隨意修改nfs里邊的內容，安全級別不高。

當然圖片服務器的圖片同步可以不采用NFS,也可以采用ftp或rsync，采用ftp這樣的話每個圖片服務器就都保存一份圖片的副本，也起到了備份的作用。但是缺點是將圖片ftp到服務器比較耗時，如果使用異步方式去同步圖片的話又會有延時，不過一般的小圖片文件也還好了。使用rsync同步，當數據文件達到一定的量級后，每次rsync掃描會耗時很久也會帶來一定的延時性。

發展階段

當網站達到一定的規模后，對圖片服務器的性能和穩定性有一定的要求后，上述NFS圖片服務架構面臨著挑戰，嚴重的依賴NFS,而且系統存在單點機器容易出現故障，需要對整體架構進行升級。于是出現了上圖圖片服務器架構，出現了分布式的圖片存儲。

其實現的具體思路如下：
1）用戶上傳圖片到web服務器后，web服務器處理完圖片，然后再由前端web服務器把圖片post到到[圖片1]、[圖片2]…[圖片N]其中的一個，圖片服務器接收到post過來的圖片，然后把圖片寫入到本地磁盤并返回對應成功狀態碼。前端web服務器根據返回狀態碼決定對應操作，如果成功的話，處理生成各尺寸的縮略圖、打水印，把圖片服務器對應的ID和對應圖片路徑寫入DB數據庫。
2) 上傳控制
我們需要調節上傳時，只需要修改web服務器post到的目的圖片服務器的ID，就可以控制上傳到哪臺圖片存儲服務器,對應的圖片存儲服務器只需要安裝nginx同時提供一個python或者php服務接收并保存圖片，如果不想不想開啟python或者php服務，也可以編寫一個nginx擴展模塊。
3) 用戶訪問流程
用戶訪問頁面的時候，根據請求圖片的URL到對應圖片服務器去訪問圖片。
如： http://imgN.xxx.com/image1.jpg

此階段的圖片服務器架構，增加了負載均衡和分布式圖片存儲，能夠在一定程度上解決并發訪問量高和存儲量大的問題。負載均衡在有一定財力的情況下可以考慮F5硬負載，當然也可以考慮使用開源的LVS軟負載(同時還可開啟緩存功能)。此時將極大提升訪問的并發量，可以根據情況隨時調配服務器。當然此時也存在一定的瑕疵，那就是可能在多臺Squid上存在同一張圖片，因為訪問圖片時可能第一次分到squid1，在LVS過期后第二次訪問到squid2或者別的，當然相對并發問題的解決，此種少量的冗余完全在我們的允許范圍之內。在該系統架構中二級緩存可以使用squid也可以考慮使用varnish或者traffic server，對于cache的開源軟件選型要考率以下幾點

1）性能：varnish本身的技術上優勢要高于squid，它采用了“Visual Page Cache”技術，在內存的利用上，Varnish比Squid具有優勢，它避免了Squid頻繁在內存、磁盤中交換文件，性能要比Squid高。varnish是不能cache到本地硬盤上的。還有強大的通過Varnish管理端口，可以使用正則表達式快速、批量地清除部分緩存。nginx是用第三方模塊ncache做的緩沖，其性能基本達到varnish，但在架構中nginx一般作為反向（靜態文件現在用nginx的很多，并發能支持到2萬+）。在靜態架構中，如果前端直接面對的是cdn活著前端了4層負載的話，完全用nginx的cache就夠了。

2）避免文件系統式的緩存，在文件數據量非常大的情況下，文件系統的性能很差，像squid,nginx的proxy_store,proxy_cache之類的方式緩存，當緩存的量級上來后，性能將不能滿足要求。開源的traffic server直接用裸盤緩存，是一個不錯的選擇，國內大規模應用并公布出來的主要是淘寶，并不是因為它做的差，而是開源時間晚。Traffic Server 在 Yahoo 內部使用了超過 4 年，主要用于 CDN 服務，CDN 用于分發特定的HTTP 內容，通常是靜態的內容如圖片、JavaScript、CSS。當然使用leveldb之類的做緩存，我估計也能達到很好的效果。

3）穩定性：squid作為老牌勁旅緩存，其穩定性更可靠一些，從我身邊一些使用者反饋來看varnish偶爾會出現crash的情況。Traffic Server在雅虎目前使用期間也沒有出現已知的數據損壞情況，其穩定性相對也比較可靠，對于未來我其實更期待Traffic Server在國內能夠擁有更多的用戶。
以上圖片服務架構設計消除了早期的NFS依賴以及單點問題，時能夠均衡圖片服務器的空間，提高了圖片服務器的安全性等問題，但是又帶來一個問題是圖片服務器的橫向擴展冗余問題。只想在普通的硬盤上存儲，首先還是要考慮一下物理硬盤的實際處理能力。是 7200 轉的還是 15000 轉的，實際表現差別就很大。至于文件系統選擇xfs、ext3、ext4還是reiserFs，需要做一些性能方面的測試，從官方的一些測試數據來看，reiserFs更適合存儲一些小圖片文件。創建文件系統的時候 Inode 問題也要加以考慮，選擇合適大小的 inode size ，因為Linux 為每個文件分配一個稱為索引節點的號碼inode，可以將inode簡單理解成一個指針，它永遠指向本文件的具體存儲位置。一個文件系統允許的inode節點數是有限的，如果文件數量太多，即使每個文件都是0字節的空文件，系統最終也會因為節點空間耗盡而不能再創建文件，因此需要在空間和速度上做取舍，構造合理的文件目錄索引。

云存儲階段

阿里云存儲服務(OpenStorageService，簡稱OSS)，是阿里云對外提供的海量，安全，低成本，高可靠的云存儲服務。用戶可以通過簡單的 REST接口，在任何時間、任何地點上傳和下載數據，也可以使用WEB頁面對數據進行管理。同時，OSS提供Java、Python、PHP SDK，簡化用戶的編程?；贠SS，用戶可以搭建出各種多媒體分享網站、網盤、個人企業數據備份等基于大規模數據的服務。在以下圖片云存儲主要以阿里云的云存儲OSS為切入點介紹，上圖為OSS云存儲的簡單架構示意圖。

真正意義上的“云存儲”，不是存儲而是提供云服務，使用云存儲服務的主要優勢有以下幾點：
1)用戶無需了解存儲設備的類型、接口、存儲介質等。
2)無需關心數據的存儲路徑。
3)無需對存儲設備進行管理、維護。
4)無需考慮數據備份和容災
5)簡單接入云存儲，盡情享受存儲服務。

架構模塊組成

1）KV Engine
OSS中的Object源信息和數據文件都是存放在KV Engine上。在6.15的版本，V Engine將使用0.8.6版本，并使用為OSS提供的OSSFileClient。

2）Quota
此模塊記錄了Bucket和用戶的對應關系，和以分鐘為單位的Bucket資源使用情況。Quota還將提供HTTP接口供Boss系統查詢。

3）安全模塊
安全模塊主要記錄User對應的ID和Key，并提供OSS訪問的用戶驗證功能。

OSS術語名詞匯

1 ）Access Key ID & Access Key Secret （API密鑰）
用戶注冊OSS時，系統會給用戶分配一對Access Key ID & Access Key Secret，稱為ID對，用于標識用戶，為訪問OSS做簽名驗證。

2） Service
OSS提供給用戶的虛擬存儲空間，在這個虛擬空間中，每個用戶可擁有一個到多個Bucket。

3） Bucket
Bucket是OSS上的命名空間；Bucket名在整個OSS中具有全局唯一性，且不能修改；存儲在OSS上的每個Object必須都包含在某個Bucket中。一個應用，例如圖片分享網站，可以對應一個或多個Bucket。一個用戶最多可創建10個Bucket，但每個Bucket中存放的Object的數量和大小總和沒有限制，用戶不需要考慮數據的可擴展性。
4） Object
在OSS中，用戶的每個文件都是一個Object，每個文件需小于5TB。Object包含key、data和user meta。其中，key是Object的名字；data是Object的數據；user meta是用戶對該object的描述。
其使用方式非常簡單,如下為java sdk：