深入分析阿里云中圖片服務(wù)的架構(gòu)經(jīng)驗(yàn)

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

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

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

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

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

執(zhí)行以上代碼即可將圖片流上傳至OSS服務(wù)器上。
圖片的訪問(wèn)方式也非常簡(jiǎn)單其url為：http://bucketname.oss.aliyuncs.com/bucketKey
 
 
分布式文件系統(tǒng)
用分布式存儲(chǔ)有幾個(gè)好處，分布式能自動(dòng)提供冗余，不需要我們?nèi)浞?，?dān)心數(shù)據(jù)安全，在文件數(shù)量特別大的情況下，備份是一件很痛苦的事情，rsync掃一次可能是就是好幾個(gè)小時(shí)，還有一點(diǎn)就是分布式存儲(chǔ)動(dòng)態(tài)擴(kuò)容方便。當(dāng)然在國(guó)內(nèi)的其他一些文件系統(tǒng)里，TFS（http://code.taobao.org/p/tfs/src/）和FASTDFS也有一些用戶，但是TFS的優(yōu)勢(shì)更是針對(duì)一些小文件存儲(chǔ)，主要是淘寶在用。另外FASTDFS在并發(fā)高于300寫(xiě)入的情況下出現(xiàn)性能問(wèn)題，穩(wěn)定性不夠友好。OSS存儲(chǔ)使用的是阿里云基于飛天5k平臺(tái)自主研發(fā)的高可用，高可靠的分布式文件系統(tǒng)盤(pán)古。分布式文件系統(tǒng)盤(pán)古和Google的GFS類(lèi)似，盤(pán)古的架構(gòu)是Master-Slave主從架構(gòu)，Master負(fù)責(zé)元數(shù)據(jù)管理，Sliave叫做Chunk Server，負(fù)責(zé)讀寫(xiě)請(qǐng)求。其中Master是基于Paxos的多Master架構(gòu)，一個(gè)Master死了之后，另外一個(gè)Master可以很快接過(guò)去，基本能夠做到故障恢復(fù)在一分鐘以內(nèi) 。文件是按照分片存放，每個(gè)會(huì)分三個(gè)副本，放在不同的機(jī)架上，最后提供端到端的數(shù)據(jù)校驗(yàn)。
 
 
HAPROXY負(fù)載均衡
基于haproxy的自動(dòng)hash架構(gòu) ,這是一種新的緩存架構(gòu)，由nginx作為最前端，代理到緩存機(jī)器。 nginx后面是緩存組，由nginx經(jīng)過(guò)url hash后將請(qǐng)求分到緩存機(jī)器。
這個(gè)架構(gòu)方便純squid緩存升級(jí)，可以在squid的機(jī)器上加裝nginx。 nginx有緩存的功能，可以將一些訪問(wèn)量特大的鏈接直接緩存在nginx上，就不用經(jīng)過(guò)多一次代理的請(qǐng)求，能夠保證圖片服務(wù)器的高可用、高性能。比如favicon.ico和網(wǎng)站的logo。 負(fù)載均衡負(fù)責(zé)OSS所有的請(qǐng)求的負(fù)載均衡，后臺(tái)的http服務(wù)器故障會(huì)自動(dòng)切換，從而保證了OSS的服務(wù)不間斷。
 
 
CDN
阿里云CDN服務(wù)是一個(gè)遍布全國(guó)的分布式緩存系統(tǒng)，能夠?qū)⒕W(wǎng)站文件（如圖片或JavaScript代碼文件）緩存到全國(guó)多個(gè)城市機(jī)房中的服務(wù)器上，當(dāng)一個(gè)用戶訪問(wèn)你的網(wǎng)站時(shí)，會(huì)就近到靠近TA的城市的服務(wù)器上獲取數(shù)據(jù)，這樣最終用戶訪問(wèn)你的服務(wù)速度會(huì)非常快。
阿里云CDN服務(wù)在全國(guó)部署超過(guò)100個(gè)節(jié)點(diǎn)，能提供給用戶優(yōu)良的網(wǎng)絡(luò)加速效果。當(dāng)網(wǎng)站業(yè)務(wù)突然爆發(fā)增長(zhǎng)時(shí)，無(wú)需手忙腳亂地?cái)U(kuò)容網(wǎng)絡(luò)帶寬，使用CDN服務(wù)即可輕松應(yīng)對(duì)。和OSS服務(wù)一樣，使用CDN，需要先在aliyun.com網(wǎng)站上開(kāi)通CDN服務(wù)。開(kāi)通后，需要在網(wǎng)站上的管理中心創(chuàng)建你的distribution（即分發(fā)頻道），每個(gè)distribution由兩個(gè)必須的部分組成：distribution ID和源站地址。
使用阿里云OSS和CDN可以非常方便的針對(duì)每個(gè)bucket進(jìn)行內(nèi)容加速，因?yàn)槊總€(gè)bucket對(duì)應(yīng)一個(gè)獨(dú)立的二級(jí)域名，針對(duì)每個(gè)文件進(jìn)行CDN刪除，簡(jiǎn)單、經(jīng)濟(jì)地解決服務(wù)的存儲(chǔ)和網(wǎng)絡(luò)問(wèn)題，畢竟大多數(shù)網(wǎng)站或應(yīng)用的存儲(chǔ)和網(wǎng)絡(luò)帶寬多半是被圖片或視頻消耗掉的。
從整個(gè)業(yè)界來(lái)看，最近這樣的面向個(gè)人用戶的云存儲(chǔ)如國(guó)外的DropBox和Box.net非常受歡迎，國(guó)內(nèi)的云存儲(chǔ)目前比較不錯(cuò)的主要有七牛云存儲(chǔ)和又拍云存儲(chǔ)。
 
 
上傳下載分而治之
圖片服務(wù)器的圖片下載比例遠(yuǎn)遠(yuǎn)高于上傳比例，業(yè)務(wù)邏輯的處理也區(qū)別明顯，上傳服器對(duì)圖片重命名，記錄入庫(kù)信息，下載服務(wù)器對(duì)圖片添加水印、修改尺寸之類(lèi)的動(dòng)態(tài)處理。從高可用的角度，我們能容忍部分圖片下載失敗，但絕不能有圖片上傳失敗，因?yàn)樯蟼魇?，意味著?shù)據(jù)的丟失。上傳與下載分開(kāi)，能保證不會(huì)因下載的壓力影響圖片的上傳，而且還有一點(diǎn)，下載入口和上傳入口的負(fù)載均衡策略也有所不同。上傳需要經(jīng)過(guò)Quota Server記錄用戶和圖片的關(guān)系等邏輯處理，下載的邏輯處理如果繞過(guò)了前端緩存處理，穿透后端業(yè)務(wù)邏輯處理，需要從OSS獲取圖片路徑信息。近期阿里云會(huì)推出基于CDN就近上傳的功能，自動(dòng)選擇離用戶最近的CDN節(jié)點(diǎn)，使得數(shù)據(jù)的上傳下載速度均得到最優(yōu)化。相較傳統(tǒng)IDC，訪問(wèn)速度提升數(shù)倍。
 
 
圖片防盜鏈處理
如果服務(wù)不允許防盜鏈，那么訪問(wèn)量會(huì)引起帶寬、服務(wù)器壓力等問(wèn)題。比較通用的解決方案是在nginx或者squid反向代理軟件上添加refer ACL判斷，OSS也提供了基于refer的防盜鏈技術(shù)。當(dāng)然OSS也提供了更為高級(jí)的URL簽名防盜鏈，其其實(shí)現(xiàn)思路如下：
 
首先，確認(rèn)自己的bucket權(quán)限是private，即這個(gè)bucket的所有請(qǐng)求必須在簽名認(rèn)證通過(guò)后才被認(rèn)為是合法的。然后根據(jù)操作類(lèi)型、要訪問(wèn)的bucket、要訪問(wèn)的object以及超時(shí)時(shí)間，動(dòng)態(tài)地生成一個(gè)經(jīng)過(guò)簽名的URL。通過(guò)這個(gè)簽名URL，你授權(quán)的用戶就可以在該簽名URL過(guò)期時(shí)間前執(zhí)行相應(yīng)的操作。
 
簽名的Python代碼如下：