原文出處：丁碼農(nóng)在主流的Web站點(diǎn)中，圖片往往是不可或缺的頁(yè)面元素，尤其在大型網(wǎng)站中，幾乎都將面臨“海量圖片資源”的存儲(chǔ)、訪問(wèn)等相關(guān)技術(shù)問(wèn)題。在針對(duì)圖片服務(wù)器的架構(gòu)擴(kuò)展中，也會(huì)歷經(jīng)很多曲折甚至是教訓(xùn)（尤其是早期規(guī)劃不足，造成后期架構(gòu)上很難兼容和擴(kuò)展）。 本文將以一個(gè)真實(shí)垂直門戶網(wǎng)站的發(fā)展歷程，向大家娓娓道來(lái)。 構(gòu)建在Windows平臺(tái)之上的網(wǎng)站，往往會(huì)被業(yè)內(nèi)眾多技術(shù)認(rèn)為很“保守”，甚至?xí)悬c(diǎn)。很大部分原因，是由于微軟技術(shù)體系的封閉和部分技術(shù)人員的短視造成的（當(dāng)然，主要還是人的問(wèn)題）。由于長(zhǎng)期缺乏開源支持，所以很多人只能“閉門造車”，這樣很容易形成思維局限性和短板。以圖片服務(wù)器為例子，如果前期沒有容量規(guī)劃和可擴(kuò)展的設(shè)計(jì)，那么隨著圖片文件的不斷增多和訪問(wèn)量的上升，由于在性能、容錯(cuò)/容災(zāi)、擴(kuò)展性等方面的設(shè)計(jì)不足，后續(xù)將會(huì)給開發(fā)、運(yùn)維工作帶來(lái)很多問(wèn)題，嚴(yán)重時(shí)甚至?xí)绊懙骄W(wǎng)站業(yè)務(wù)正常運(yùn)作和互聯(lián)網(wǎng)公司的發(fā)展（這絕不是在）。 很多公司之所以選擇Windows（）平臺(tái)來(lái)構(gòu)建網(wǎng)站和圖片服務(wù)器，很大部分由創(chuàng)始團(tuán)隊(duì)的技術(shù)背景決定的，早期的技術(shù)人員可能更熟悉.NET，或者團(tuán)隊(duì)的負(fù)責(zé)人認(rèn)為Windows/.NET的易用性、“短平快”的開發(fā)模式、人才成本等方面都比較符合創(chuàng)業(yè)初期的團(tuán)隊(duì)，自然就選擇了Windows。后期業(yè)務(wù)發(fā)展到一定規(guī)模，也很難輕易將整體架構(gòu)遷移到其它開源平臺(tái)上了。當(dāng)然，對(duì)于構(gòu)建大規(guī)�；ヂ�(lián)網(wǎng)，更首選開源架構(gòu)，因?yàn)橛泻芏喑墒斓陌咐烷_源生態(tài)的支持（也會(huì)有很多坑，就看是你自己最先去踩坑，還是在別人踩了修復(fù)之后你再用），避免重復(fù)造輪子和支出高額授權(quán)費(fèi)用。對(duì)于遷移難度較大的應(yīng)用，個(gè)人比較推薦Linux、Mono、Jexus、Mysql、Memcahed、Redis混搭的架構(gòu)，同樣能支撐具有高并發(fā)訪問(wèn)和大數(shù)據(jù)量等特點(diǎn)的互聯(lián)網(wǎng)應(yīng)用。 初創(chuàng)時(shí)期由于時(shí)間緊迫，開發(fā)人員水平也很有限等原因。所以通常就直接在website文件所在的目錄下，建立1個(gè)upload子目錄，用于保存用戶上傳的圖片文件。如果按業(yè)務(wù)再細(xì)分，可以在upload目錄下再建立不同的子目錄來(lái)區(qū)分。例如：upload\QA,upload\Face等。 在數(shù)據(jù)庫(kù)表中保存的也是”upload/qa/test.jpg”這類相對(duì)徑。 用戶的訪問(wèn)方式如下： 程序上傳和寫入方式： 程序員A通過(guò)在web.config中配置物理目錄D:\Web\yourdomain\upload 然后通過(guò)stream的方式寫入文件； 程序員B通過(guò)Server.MapPath等方式，根據(jù)相對(duì)徑獲取物理目錄 然后也通過(guò)stream的方式寫入文件。 優(yōu)點(diǎn)：實(shí)現(xiàn)起來(lái)最簡(jiǎn)單，無(wú)需任何復(fù)雜技術(shù)，就能成功將用戶上傳的文件寫入指定目錄。保存數(shù)據(jù)庫(kù)記錄和訪問(wèn)起來(lái)倒是也很方便。 缺點(diǎn)：上傳方式混亂，嚴(yán)重不利于網(wǎng)站的擴(kuò)展。 針對(duì)上述最原始的架構(gòu)，主要面臨著如下問(wèn)題： 在部署新版本（部署新版本前通過(guò)需要備份）和日常備份website文件的時(shí)候，需要同時(shí)操作upload目錄中的文件，如果考慮到訪問(wèn)量上升，后邊部署由多臺(tái)Web服務(wù)器組成的負(fù)載均衡集群，集群節(jié)點(diǎn)之間如果做好文件實(shí)時(shí)同步將是個(gè)難題。 在website站點(diǎn)下面，新建一個(gè)名為upload的虛擬目錄，由于虛擬目錄的靈活性，能在一定程度上取代物理目錄，并兼容原有的圖片上傳和訪問(wèn)方式。用戶的訪問(wèn)方式依然是： 優(yōu)點(diǎn)：配置更加靈活，也能兼容老版本的上傳和訪問(wèn)方式。 因?yàn)樘摂M目錄，可以指向本地任意盤符下的任意目錄。這樣一來(lái)，還可以通過(guò)接入外置存儲(chǔ)，來(lái)進(jìn)行單機(jī)的容量擴(kuò)展。 缺點(diǎn)：部署成由多臺(tái)Web服務(wù)器組成的集群，各個(gè)Web服務(wù)器（集群節(jié)點(diǎn)）之間（虛擬目錄下的）需要實(shí)時(shí)的去同步文件，由于同步效率和實(shí)時(shí)性的，很難某一時(shí)刻各節(jié)點(diǎn)上文件是完全一致的。 基本架構(gòu)如下圖所示：
從上圖可看出，整個(gè)Web服務(wù)器架構(gòu)已經(jīng)具備“可擴(kuò)展、高可用”了，主要問(wèn)題和瓶頸都集中在多臺(tái)服務(wù)器之間的文件同步上。 上述架構(gòu)中只能在這幾臺(tái)Web服務(wù)器上互相“增量同步”，這樣一來(lái)，就不支持文件的“刪除、更新”操作的同步了。 早期的想法是，在應(yīng)用程序?qū)用孀隹刂疲?dāng)用戶請(qǐng)求在web1服務(wù)器進(jìn)行上傳寫入的同時(shí)，也同步去調(diào)用其它web服務(wù)器上的上傳接口，這顯然是得不償失的。所以我們選擇使用Rsync類的軟件來(lái)做定時(shí)文件同步的，從而省去了“重復(fù)造輪子”的成本，也降低了風(fēng)險(xiǎn)性。 同步操作里面，一般有比較經(jīng)典的兩種模型，即推拉模型：所謂“拉”，就是指輪詢地去獲取更新，所謂推，就是發(fā)生更改后主動(dòng)的“推”給其它機(jī)器。當(dāng)然，也可以采用加高級(jí)的事件通知機(jī)制來(lái)完成此類動(dòng)作。 在高并發(fā)寫入的場(chǎng)景中，同步都會(huì)出現(xiàn)效率和實(shí)時(shí)性問(wèn)題，而且大量文件同步也是很消耗系統(tǒng)和帶寬資源的（跨網(wǎng)段則更明顯）。 沿用虛擬目錄的方式，通過(guò)UNC（網(wǎng)絡(luò)徑）的方式實(shí)現(xiàn)共享存儲(chǔ)（將upload虛擬目錄指向UNC） 用戶的訪問(wèn)方式1： 用戶的訪問(wèn)方式2（可以配置域名）： 支持UNC所在server上配置域名指向，并配置輕量級(jí)的web服務(wù)器，來(lái)實(shí)現(xiàn)圖片服務(wù)器。 優(yōu)點(diǎn)： 通過(guò)UNC（網(wǎng)絡(luò)徑）的方式來(lái)進(jìn)行讀寫操作，可以避免多服務(wù)器之間同步相關(guān)的問(wèn)題。相對(duì)來(lái)講很靈活，也支持?jǐn)U容/擴(kuò)展。支持配置成圖片服務(wù)器和域名訪問(wèn)，也完整兼容舊版本的訪問(wèn)規(guī)則。 缺點(diǎn) ：但是UNC配置有些繁瑣，而且會(huì)造成一定的（讀寫和安全）性能損失�？赡軙�(huì)出現(xiàn)“單點(diǎn)故障”。如果存儲(chǔ)級(jí)別沒有raid或者更高級(jí)的災(zāi)備措施，還會(huì)造成數(shù)據(jù)丟失。 基本架構(gòu)如下圖所示：
在早期的很多基于Linux開源架構(gòu)的網(wǎng)站中，如果不想同步圖片，可能會(huì)利用NFS來(lái)實(shí)現(xiàn)。事明，NFS在高并發(fā)讀寫和海量存儲(chǔ)方面，效率上存在一定問(wèn)題，并非最佳的選擇，所以大部分互聯(lián)網(wǎng)公司都不會(huì)使用NFS來(lái)實(shí)現(xiàn)此類應(yīng)用。當(dāng)然，也可以通過(guò)Windows自帶的DFS來(lái)實(shí)現(xiàn)，缺點(diǎn)是“配置復(fù)雜，效率未知，而且缺乏資料大量的實(shí)際案例”。另外，也有一些公司采用FTP或Samba來(lái)實(shí)現(xiàn)。 提到的幾種架構(gòu)，在上傳/下載操作時(shí)，都經(jīng)過(guò)了Web服務(wù)器（雖然共享存儲(chǔ)的這種架構(gòu)，也可以配置域名和站點(diǎn)來(lái)提供圖片訪問(wèn)，但上傳寫入仍然得經(jīng)過(guò)Web服務(wù)器上的應(yīng)用程序來(lái)處理），這對(duì)Web服務(wù)器來(lái)講無(wú)疑是造成巨大的壓力。所以，更使用的圖片服務(wù)器和的域名，來(lái)提供用戶圖片的上傳和訪問(wèn)。 直到應(yīng)用級(jí)別的（非系統(tǒng)級(jí)） DFS（例如FastDFS HDFS MogileFs MooseFS、TFS）的流行，簡(jiǎn)化了這個(gè)問(wèn)題：執(zhí)行冗余備份、支持自動(dòng)同步、支持線性擴(kuò)展、支持主流語(yǔ)言的客戶端api上傳/下載/刪除等操作，部分支持文件索引，部分支持提供Web的方式來(lái)訪問(wèn)。 考慮到各DFS的特點(diǎn)，客戶端API語(yǔ)言支持情況(需要支持C#)，文檔和案例，以及社區(qū)的支持度，我們最終選擇了FastDFS來(lái)部署。 唯一的問(wèn)題是：可能會(huì)不兼容舊版本的訪問(wèn)規(guī)則。如果將舊圖片一次性導(dǎo)入FastDFS，但由于舊圖片訪問(wèn)徑分布存儲(chǔ)在不同業(yè)務(wù)數(shù)據(jù)庫(kù)的各個(gè)表中，整體更新起來(lái)也十分困難，所以必須得兼容舊版本的訪問(wèn)規(guī)則。架構(gòu)升級(jí)往往比做全新架構(gòu)更有難度，就是因?yàn)檫�要兼容之前版本的問(wèn)題。（給飛機(jī)在空中換引擎可比造架飛機(jī)難得多） 首先，關(guān)閉舊版本上傳入口（避免繼續(xù)使用導(dǎo)致數(shù)據(jù)不一致）。將舊圖片數(shù)據(jù)通過(guò)rsync工具一次性遷移到的圖片服務(wù)器上（即下圖中描述的Old Image Server）。在最前端(七層代理，如Haproxy、Nginx)用ACL（訪問(wèn)規(guī)則控制），將舊圖片對(duì)應(yīng)URL規(guī)則的請(qǐng)求（正則）匹配到，然后將請(qǐng)求直接轉(zhuǎn)發(fā)指定的web 服務(wù)器列表，在該列表中的服務(wù)器上配置好提供圖片（以Web方式）訪問(wèn)的站點(diǎn)，并加入緩存策略。這樣實(shí)現(xiàn)舊圖片服務(wù)器的分離和緩存,兼容了舊圖片的訪問(wèn)規(guī)則并提升舊圖片訪問(wèn)效率，也避免了實(shí)時(shí)同步所帶來(lái)的問(wèn)題。 整體架構(gòu)如圖：
基于FastDFS的圖片服務(wù)器集群架構(gòu)，雖然已經(jīng)非常的成熟，但是由于國(guó)內(nèi)“南北互聯(lián)”和IDC帶寬成本等問(wèn)題（圖片常消耗流量的），我們最終還是選擇了商用的CDN技術(shù)，實(shí)現(xiàn)起來(lái)也非常容易，原理其實(shí)也很簡(jiǎn)單，我這里只做個(gè)簡(jiǎn)單的介紹： 將img域名cname到CDN廠商指定的域名上，用戶請(qǐng)求訪問(wèn)圖片時(shí)，則由CDN廠商提供智能DNS解析，將最近的（當(dāng)然也可能有其它更復(fù)雜的策略，例如負(fù)載情況、健康狀態(tài)等）服務(wù)節(jié)點(diǎn)地址返回給用戶，用戶請(qǐng)求到達(dá)指定的服務(wù)器節(jié)點(diǎn)上，該節(jié)點(diǎn)上提供了類似Squid/Vanish的代理緩存服務(wù)，如果是第一次請(qǐng)求該徑，則會(huì)從源站獲取圖片資源返回客戶端瀏覽器，如果緩存中存在，則直接從緩存中獲取并返回給客戶端瀏覽器，完成請(qǐng)求/響應(yīng)過(guò)程。 由于采用了商用CDN服務(wù)，所以我們并沒有考慮用Squid/Vanish來(lái)自行構(gòu)建前置代理緩存。 的整個(gè)集群架構(gòu)，可以很方便的做橫向擴(kuò)展，能滿足一般垂直領(lǐng)域中大型網(wǎng)站的圖片服務(wù)需求（當(dāng)然，像taobao這樣超大規(guī)模的可能另當(dāng)別論）。經(jīng)測(cè)試，提供圖片訪問(wèn)的單臺(tái)Nginx服務(wù)器（至強(qiáng)E5四核CPU、16G內(nèi)存、SSD），對(duì)小靜態(tài)頁(yè)面（壓縮后大概只有10kb左右的）可以扛住幾千個(gè)并發(fā)且毫無(wú)壓力。當(dāng)然，由于圖片本身體積比純文本的靜態(tài)頁(yè)面大很多，提供圖片訪問(wèn)的服務(wù)器的抗并發(fā)能力，往往會(huì)受限于磁盤的I/O處理能力和IDC提供的帶寬。Nginx的抗并發(fā)能力還常強(qiáng)的，而且對(duì)資源占用很低，尤其是處理靜態(tài)資源，似乎都不需要有過(guò)多擔(dān)心了�？梢愿鶕�(jù)實(shí)際訪問(wèn)量的需求，通過(guò)調(diào)整Nginx的參數(shù)，對(duì)Linux內(nèi)核做調(diào)優(yōu)，加入分級(jí)緩存策略等手段能夠做更大程度的優(yōu)化，也可以通過(guò)增加服務(wù)器或者升級(jí)服務(wù)器配置來(lái)做擴(kuò)展，最直接的是通過(guò)購(gòu)買更高級(jí)的存儲(chǔ)設(shè)備和更大的帶寬，以滿足更大訪問(wèn)量的需求。 值得一提的是，在“云計(jì)算”流行的當(dāng)下，也推薦高速發(fā)展期間的網(wǎng)站，使用“云存儲(chǔ)”這樣的方案，既能幫你解決各類存儲(chǔ)、擴(kuò)展、備災(zāi)的問(wèn)題，又能做好CDN加速。最重要的是，價(jià)格也不貴。 總結(jié)，有關(guān)圖片服務(wù)器架構(gòu)擴(kuò)展，大致圍繞這些問(wèn)題展開： |
