現(xiàn)在幾乎任何一個網(wǎng)站、Web App以及移動APP等應(yīng)用都需要有圖片展示的功能，對于圖片功能從下至上都是很重要的。必須要具有前瞻性的規(guī)劃好圖片服務(wù)器，圖片的上傳和下載速度至關(guān)重要，當(dāng)然這并不是說一上來就搞很NB的架構(gòu)，至少具備一定擴(kuò)展性和穩(wěn)定性。雖然各種架構(gòu)設(shè)計(jì)都有，在這里我只是談?wù)勎业囊恍﹤€人想法。
 
對于圖片服務(wù)器來說IO無疑是消耗資源最為嚴(yán)重的，對于web應(yīng)用來說需要將圖片服務(wù)器做一定的分離，否則很可能因?yàn)閳D片服務(wù)器的IO負(fù)載導(dǎo)致應(yīng)用崩潰。因此尤其對于大型網(wǎng)站和應(yīng)用來說，非常有必要將圖片服務(wù)器和應(yīng)用服務(wù)器分離，構(gòu)建獨(dú)立的圖片服務(wù)器集群，構(gòu)建獨(dú)立的圖片服務(wù)器其主要優(yōu)勢：
1）分擔(dān)Web服務(wù)器的I/O負(fù)載-將耗費(fèi)資源的圖片服務(wù)分離出來，提高服務(wù)器的性能和穩(wěn)定性。
2）能夠?qū)ｉT對圖片服務(wù)器進(jìn)行優(yōu)化-為圖片服務(wù)設(shè)置有針對性的緩存方案，減少帶寬網(wǎng)絡(luò)成本，提高訪問速度。
3）提高網(wǎng)站的可擴(kuò)展性-通過增加圖片服務(wù)器，提高圖片服務(wù)吞吐能力。
 
從傳統(tǒng)互聯(lián)網(wǎng)的web1.0，歷經(jīng)web2.0時(shí)代以及發(fā)展到現(xiàn)在的web3.0，隨著圖片存儲規(guī)模的增加，圖片服務(wù)器的架構(gòu)也在逐漸發(fā)生變化，以下主要論述三個階段的圖片服務(wù)器架構(gòu)演進(jìn)。
 
 初始階段

在介紹初始階段的早期的小型圖片服務(wù)器架構(gòu)之前，首先讓我們了解一下NFS技術(shù)，NFS是Network File System的縮寫，即網(wǎng)絡(luò)文件系統(tǒng)。NFS是由Sun開發(fā)并發(fā)展起來的一項(xiàng)用于在不同機(jī)器，不同操作系統(tǒng)之間通過網(wǎng)絡(luò)互相分享各自的文件。NFS server也可以看作是一個FILE SERVER,用于在UNIX類系統(tǒng)之間共享文件，可以輕松的掛載(mount)到一個目錄上，操作起來就像本地文件一樣的方便。
 
如果不想在每臺圖片服務(wù)器同步所有圖片，那么NFS是最簡單的文件共享方式。NFS是個分布式的客戶機(jī)/服務(wù)器文件系統(tǒng)，NFS的實(shí)質(zhì)在于用戶間計(jì)算機(jī)的共享，用戶可以聯(lián)結(jié)到共享計(jì)算機(jī)并象訪問本地硬盤一樣訪問共享計(jì)算機(jī)上的文件。具體實(shí)現(xiàn)思路是：
 
1)所有前端web服務(wù)器都通過nfs掛載3臺圖片服務(wù)器export出來的目錄，以接收web服務(wù)器寫入的圖片。然后[圖片1]服務(wù)器掛載另外兩臺圖片服務(wù)器的export目錄到本地給apache對外提供訪問。
2） 用戶上傳圖片
用戶通過Internet訪問頁面提交上傳請求post到web服務(wù)器，web服務(wù)器處理完圖片后由web服務(wù)器拷貝到對應(yīng)的mount本地目錄。
3）用戶訪問圖片
用戶訪問圖片時(shí)，通過[圖片1]這臺圖片服務(wù)器來讀取相應(yīng)mount目錄里邊的圖片。
 
以上架構(gòu)存在的問題：
1）性能：現(xiàn)有結(jié)構(gòu)過度依賴nfs,當(dāng)圖片服務(wù)器的nfs服務(wù)器有問題時(shí)，可能影響到前端web服務(wù)器。NFS的問題主要是鎖的問題. 很容易造成死鎖, 只有硬件重啟才能解決。尤其當(dāng)圖片達(dá)到一定的量級后，nfs會有嚴(yán)重的性能問題。
2）高可用：對外提供下載的圖片服務(wù)器只有一臺，容易出現(xiàn)單點(diǎn)故障。
3） 擴(kuò)展性：圖片服務(wù)器之間的依賴過多，而且橫向擴(kuò)展余地不夠。
4） 存儲：web服務(wù)器上傳熱點(diǎn)不可控，造成現(xiàn)有圖片服務(wù)器空間占用不均衡。
5） 安全性：nfs方式對于擁有web服務(wù)器的密碼的人來說，可以隨意修改nfs里邊的內(nèi)容，安全級別不高。
 
當(dāng)然圖片服務(wù)器的圖片同步可以不采用NFS,也可以采用ftp或rsync，采用ftp這樣的話每個圖片服務(wù)器就都保存一份圖片的副本，也起到了備份的作用。但是缺點(diǎn)是將圖片ftp到服務(wù)器比較耗時(shí)，如果使用異步方式去同步圖片的話又會有延時(shí)，不過一般的小圖片文件也還好了。使用rsync同步，當(dāng)數(shù)據(jù)文件達(dá)到一定的量級后，每次rsync掃描會耗時(shí)很久也會帶來一定的延時(shí)性。
 
 
發(fā)展階段

當(dāng)網(wǎng)站達(dá)到一定的規(guī)模后，對圖片服務(wù)器的性能和穩(wěn)定性有一定的要求后，上述NFS圖片服務(wù)架構(gòu)面臨著挑戰(zhàn)，嚴(yán)重的依賴NFS,而且系統(tǒng)存在單點(diǎn)機(jī)器容易出現(xiàn)故障，需要對整體架構(gòu)進(jìn)行升級。于是出現(xiàn)了上圖圖片服務(wù)器架構(gòu)，出現(xiàn)了分布式的圖片存儲。
 
其實(shí)現(xiàn)的具體思路如下：
1）用戶上傳圖片到web服務(wù)器后，web服務(wù)器處理完圖片，然后再由前端web服務(wù)器把圖片post到到[圖片1]、[圖片2]…[圖片N]其中的一個，圖片服務(wù)器接收到post過來的圖片，然后把圖片寫入到本地磁盤并返回對應(yīng)成功狀態(tài)碼。前端web服務(wù)器根據(jù)返回狀態(tài)碼決定對應(yīng)操作，如果成功的話，處理生成各尺寸的縮略圖、打水印，把圖片服務(wù)器對應(yīng)的ID和對應(yīng)圖片路徑寫入DB數(shù)據(jù)庫。
2) 上傳控制
我們需要調(diào)節(jié)上傳時(shí)，只需要修改web服務(wù)器post到的目的圖片服務(wù)器的ID，就可以控制上傳到哪臺圖片存儲服務(wù)器,對應(yīng)的圖片存儲服務(wù)器只需要安裝nginx同時(shí)提供一個python或者php服務(wù)接收并保存圖片，如果不想不想開啟python或者php服務(wù)，也可以編寫一個nginx擴(kuò)展模塊。
3) 用戶訪問流程
用戶訪問頁面的時(shí)候，根據(jù)請求圖片的URL到對應(yīng)圖片服務(wù)器去訪問圖片。
如： http://imgN.xxx.com/image1.jpg
 
此階段的圖片服務(wù)器架構(gòu)，增加了負(fù)載均衡和分布式圖片存儲，能夠在一定程度上解決并發(fā)訪問量高和存儲量大的問題。負(fù)載均衡在有一定財(cái)力的情況下可以考慮F5硬負(fù)載，當(dāng)然也可以考慮使用開源的LVS軟負(fù)載(同時(shí)還可開啟緩存功能)。此時(shí)將極大提升訪問的并發(fā)量，可以根據(jù)情況隨時(shí)調(diào)配服務(wù)器。當(dāng)然此時(shí)也存在一定的瑕疵，那就是可能在多臺Squid上存在同一張圖片，因?yàn)樵L問圖片時(shí)可能第一次分到squid1，在LVS過期后第二次訪問到squid2或者別的，當(dāng)然相對并發(fā)問題的解決，此種少量的冗余完全在我們的允許范圍之內(nèi)。在該系統(tǒng)架構(gòu)中二級緩存可以使用squid也可以考慮使用varnish或者traffic server，對于cache的開源軟件選型要考率以下幾點(diǎn)
 
1）性能：varnish本身的技術(shù)上優(yōu)勢要高于squid，它采用了“Visual Page Cache”技術(shù)，在內(nèi)存的利用上，Varnish比Squid具有優(yōu)勢，它避免了Squid頻繁在內(nèi)存、磁盤中交換文件，性能要比Squid高。varnish是不能cache到本地硬盤上的。還有強(qiáng)大的通過Varnish管理端口，可以使用正則表達(dá)式快速、批量地清除部分緩存。nginx是用第三方模塊ncache做的緩沖，其性能基本達(dá)到varnish，但在架構(gòu)中nginx一般作為反向（靜態(tài)文件現(xiàn)在用nginx的很多，并發(fā)能支持到2萬+）。在靜態(tài)架構(gòu)中，如果前端直接面對的是cdn活著前端了4層負(fù)載的話，完全用nginx的cache就夠了。
 
2）避免文件系統(tǒng)式的緩存，在文件數(shù)據(jù)量非常大的情況下，文件系統(tǒng)的性能很差，像squid,nginx的proxy_store,proxy_cache之類的方式緩存，當(dāng)緩存的量級上來后，性能將不能滿足要求。開源的traffic server直接用裸盤緩存，是一個不錯的選擇，國內(nèi)大規(guī)模應(yīng)用并公布出來的主要是淘寶，并不是因?yàn)樗龅牟睿情_源時(shí)間晚。Traffic Server 在 Yahoo 內(nèi)部使用了超過 4 年，主要用于 CDN 服務(wù)，CDN 用于分發(fā)特定的HTTP 內(nèi)容，通常是靜態(tài)的內(nèi)容如圖片、JavaScript、CSS。當(dāng)然使用leveldb之類的做緩存，我估計(jì)也能達(dá)到很好的效果。
 
3）穩(wěn)定性：squid作為老牌勁旅緩存，其穩(wěn)定性更可靠一些，從我身邊一些使用者反饋來看varnish偶爾會出現(xiàn)crash的情況。Traffic Server在雅虎目前使用期間也沒有出現(xiàn)已知的數(shù)據(jù)損壞情況，其穩(wěn)定性相對也比較可靠，對于未來我其實(shí)更期待Traffic Server在國內(nèi)能夠擁有更多的用戶。
        以上圖片服務(wù)架構(gòu)設(shè)計(jì)消除了早期的NFS依賴以及單點(diǎn)問題，時(shí)能夠均衡圖片服務(wù)器的空間，提高了圖片服務(wù)器的安全性等問題，但是又帶來一個問題是圖片服務(wù)器的橫向擴(kuò)展冗余問題。只想在普通的硬盤上存儲，首先還是要考慮一下物理硬盤的實(shí)際處理能力。是 7200 轉(zhuǎn)的還是 15000 轉(zhuǎn)的，實(shí)際表現(xiàn)差別就很大。至于文件系統(tǒng)選擇xfs、ext3、ext4還是reiserFs，需要做一些性能方面的測試，從官方的一些測試數(shù)據(jù)來看，reiserFs更適合存儲一些小圖片文件。創(chuàng)建文件系統(tǒng)的時(shí)候 Inode 問題也要加以考慮，選擇合適大小的 inode size ，因?yàn)長inux 為每個文件分配一個稱為索引節(jié)點(diǎn)的號碼inode，可以將inode簡單理解成一個指針，它永遠(yuǎn)指向本文件的具體存儲位置。一個文件系統(tǒng)允許的inode節(jié)點(diǎn)數(shù)是有限的，如果文件數(shù)量太多，即使每個文件都是0字節(jié)的空文件，系統(tǒng)最終也會因?yàn)楣?jié)點(diǎn)空間耗盡而不能再創(chuàng)建文件，因此需要在空間和速度上做取舍，構(gòu)造合理的文件目錄索引。
 
 
云存儲階段

阿里云存儲服務(wù)(OpenStorageService，簡稱OSS)，是阿里云對外提供的海量，安全，低成本，高可靠的云存儲服務(wù)。用戶可以通過簡單的 REST接口，在任何時(shí)間、任何地點(diǎn)上傳和下載數(shù)據(jù)，也可以使用WEB頁面對數(shù)據(jù)進(jìn)行管理。同時(shí)，OSS提供Java、Python、PHP SDK，簡化用戶的編程。基于OSS，用戶可以搭建出各種多媒體分享網(wǎng)站、網(wǎng)盤、個人企業(yè)數(shù)據(jù)備份等基于大規(guī)模數(shù)據(jù)的服務(wù)。在以下圖片云存儲主要以阿里云的云存儲OSS為切入點(diǎn)介紹，上圖為OSS云存儲的簡單架構(gòu)示意圖。
 
真正意義上的“云存儲”，不是存儲而是提供云服務(wù)，使用云存儲服務(wù)的主要優(yōu)勢有以下幾點(diǎn)：
1)用戶無需了解存儲設(shè)備的類型、接口、存儲介質(zhì)等。
2)無需關(guān)心數(shù)據(jù)的存儲路徑。
3)無需對存儲設(shè)備進(jìn)行管理、維護(hù)。
4)無需考慮數(shù)據(jù)備份和容災(zāi)
5)簡單接入云存儲，盡情享受存儲服務(wù)。
 
 
架構(gòu)模塊組成

1）KV Engine
OSS中的Object源信息和數(shù)據(jù)文件都是存放在KV Engine上。在6.15的版本，V Engine將使用0.8.6版本，并使用為OSS提供的OSSFileClient。
 
2）Quota
此模塊記錄了Bucket和用戶的對應(yīng)關(guān)系，和以分鐘為單位的Bucket資源使用情況。Quota還將提供HTTP接口供Boss系統(tǒng)查詢。
 
3）安全模塊
安全模塊主要記錄User對應(yīng)的ID和Key，并提供OSS訪問的用戶驗(yàn)證功能。
 
OSS術(shù)語名詞匯
 
1 ）Access Key ID & Access Key Secret （API密鑰）
用戶注冊O(shè)SS時(shí)，系統(tǒng)會給用戶分配一對Access Key ID & Access Key Secret，稱為ID對，用于標(biāo)識用戶，為訪問OSS做簽名驗(yàn)證。
 
2） Service
OSS提供給用戶的虛擬存儲空間，在這個虛擬空間中，每個用戶可擁有一個到多個Bucket。
 
3） Bucket
Bucket是OSS上的命名空間；Bucket名在整個OSS中具有全局唯一性，且不能修改；存儲在OSS上的每個Object必須都包含在某個Bucket中。一個應(yīng)用，例如圖片分享網(wǎng)站，可以對應(yīng)一個或多個Bucket。一個用戶最多可創(chuàng)建10個Bucket，但每個Bucket中存放的Object的數(shù)量和大小總和沒有限制，用戶不需要考慮數(shù)據(jù)的可擴(kuò)展性。
4） Object
在OSS中，用戶的每個文件都是一個Object，每個文件需小于5TB。Object包含key、data和user meta。其中，key是Object的名字；data是Object的數(shù)據(jù)；user meta是用戶對該object的描述。
其使用方式非常簡單,如下為java sdk：

發(fā)表評論 共有條評論 用戶名: 密碼: 驗(yàn)證碼: 匿名發(fā)表