現(xiàn)在幾乎任何一個網(wǎng)站、Web App以及移動APP等應用都需要有圖片展示的功能，對于圖片功能從下至上都是很重要的。必須要具有前瞻性的規(guī)劃好圖片服務器，圖片的上傳和下載速度至關重要，當然這并不是說一上來

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

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

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

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

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

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

h=hmac.new(OtxrzxIsfpFjA7SwPzILwy8Bw21TLhquhboDYROV”, GETnnn1141889120n/oss-example/oss-api.jpg”,sha);urllib.quote_plus (base64.encodestring(h.digest()).strip());其中method可以是PUT、GET、HEAD、DELETE中的任意一種；最后一個參數(shù)timeout”是超時的時間，單位是秒。一個通過上面Python方法，計算得到的簽名URL為：http://oss-example.oss-cn-hangzhou.aliyuncs.com/oss-api.jpg?OSSAccessKeyId=44CF9590006BF252F707&Expires=1141889120&Signature=vjbyPxybdZaNmGa%2ByT272YEAiv4%3D通過這種動態(tài)計算簽名URL的方法，可以有效地保護放在OSS上的數(shù)據(jù)，防止被其他人盜鏈。圖片編輯處理API對于在線圖片的編輯處理，GraphicsMagick（GraphicsMagick(http://www.graphicsmagick.org/)）對于從事互聯(lián)網(wǎng)的技術(shù)人員應該不會陌生。GraphicsMagick是從 ImageMagick 5.5.2 分支出來的，但是現(xiàn)在他變得更穩(wěn)定和優(yōu)秀，GM更小更容易安裝、GM更有效率、GM的手冊非常豐富GraphicsMagick的命令與ImageMagick基本是一樣的。GraphicsMagick 提供了包括裁、縮放、合成、打水印、圖像轉(zhuǎn)換、填充等非常豐富的接口API,其中的開發(fā)包SDK也非常豐富，包括了JAVA(im4java)、C、C++、Perl、PHP、Tcl、Ruby等的調(diào)用，支持超過88中圖像格式，包括重要的DPX、GIF、JPEG、JPEG-2000、PNG、PDF、PNM和TIFF，GraphicsMagick可以再絕大多數(shù)的平臺上使用，Linux、Mac、Windows都沒有問題。但是獨立開發(fā)這些圖片處理服務，對服務器的IO要求相對要高一些，而且目前這些開源的圖片處理編輯庫，相對來說還不是很穩(wěn)定，筆者在使用GraphicsMagick 的時候就遇到了tomcat 進程crash情況，需要手動重啟tomcat服務。阿里云目前已經(jīng)對外開放圖片處理API,包括了大多數(shù)常用處理解決方案：縮略圖、打水印、文字水印、樣式、管道等。開發(fā)者可以非常方便的使用如上圖片處理方案，希望越來越多的開發(fā)者能夠基于OSS開放出更多優(yōu)秀的產(chǎn)品。