Windows平台網站圖片伺服器架構的演化

標籤：style   blog   http   tar   ext   com   

摘要

在主流的Web網站中，圖片往往是不可或缺的頁面元素，尤其在大型網站中，幾乎都將面臨“海量圖片資源”的儲存、訪問等相關技術問題。在針對圖片伺服器的架構擴充中，也會曆經很多曲折甚至是血淚教訓（尤其是早期規劃不足，造成後期架構上很難相容和擴充）。

本文將以一個真實垂直門戶網站的發展曆程，向大家娓娓道來。

 

本文

構建在Windows平台之上的網站，往往會被業內眾多架構師認為很“保守”。很大部分原因，是由於微軟技術體系的封閉和部分技術人員的短視造成的。由於長期缺乏開源支援，所以只能“閉門造車”，這樣很容易形成思維局限性和短板。就拿圖片伺服器為例子，如果前期沒有容量規劃和可擴充的設計，那麼隨著圖片檔案的不斷增多和訪問量的上升，由於在效能、容錯/容災、擴充性等方面的設計不足，後續將會給開發、營運工作帶來很多問題，嚴重時甚至會影響到網站業務正常運作和互連網公司的發展（這絕不是在危言聳聽）。

之所以選擇Windows平台來構建網站和圖片伺服器，很大部分由創始團隊的技術背景決定的，早期的技術人員可能更熟悉.NET，或者負責人認為Windows/.NET的易用性、“短平快”的開發模式、人才成本等方面都比較符合創業初期的團隊，自然就選擇了Windows。後期業務發展到一定規模，也很難輕易將整體架構遷移到其它平台上了。當然，對於構建大規模互連網，更建議首選開源架構，因為有很多成熟的案例和開源生態的支援，避免重複造輪子和支出授權費用。對於遷移難度較大的應用，比較推薦Linux、Mono、Mysql、Memcahed……混搭的架構，同樣能支撐高並發訪問和大資料量。

單機時代的圖片伺服器架構（集中式）

初創時期由於時間緊迫，開發人員水平也很有限等原因。所以通常就直接在website檔案所在的目錄下，建立1個upload子目錄，用於儲存使用者上傳的圖片檔案。如果按業務再細分，可以在upload目錄下再建立不同的子目錄來區分。例如：upload\QA,upload\Face等。

在資料庫表中儲存的也是”upload/qa/test.jpg”這類相對路徑。

使用者的訪問方式如下：

http://www.yourdomain.com/upload/qa/test.jpg

程式上傳和寫入方式：

程式員A通過在web.config中配置物理目錄D:\Web\yourdomain\upload  然後通過stream的方式寫入檔案；

程式員B通過Server.MapPath等方式，根據相對路徑擷取物理目錄  然後也通過stream的方式寫入檔案。

優點：實現起來最簡單，無需任何複雜技術，就能成功將使用者上傳的檔案寫入指定目錄。儲存資料庫記錄和訪問起來倒是也很方便。

缺點：上傳方式混亂，嚴重不利於網站的擴充。

針對上述最原始的架構，主要面臨著如下問題：

1.   隨著upload目錄中檔案越來越多，所在分區（例如D盤）如果出現容量不足，則很難擴容。只能停機後更換更大容量的存放裝置，再將舊資料匯入。

2.   在部署新版本（部署新版本前通過需要備份）和日常備份website檔案的時候，需要同時操作upload目錄中的檔案，如果考慮到訪問量上升，後邊部署由多台Web伺服器組成的負載平衡叢集，叢集節點之間如果做好檔案即時同步將是個難題。

 

叢集時代的圖片伺服器架構（即時同步）

在website網站下面，建立一個名為upload的虛擬目錄，由於虛擬目錄的靈活性，能在一定程度上取代物理目錄，併兼容原有的圖片上傳和訪問方式。使用者的訪問方式依然是：

http://www.yourdomain.com/upload/qa/test.jpg

優點：配置更加靈活，也能相容老版本的上傳和訪問方式。

因為虛擬目錄，可以指向本地任意盤符下的任意目錄。這樣一來，還可以通過接入外置儲存，來進行單機的容量擴充。

缺點：部署成由多台Web伺服器組成的叢集，各個Web伺服器（叢集節點）之間（虛擬目錄下的）需要即時的去同步檔案，由於同步效率和即時性的限制，很難保證某一時刻各節點上檔案是完全一致的。

基本架構如所示：

從可看出，整個Web伺服器架構已經具備“可擴充、高可用”了，主要問題和瓶頸都集中在多台伺服器之間的檔案同步上。

 

上述架構中只能在這幾台Web伺服器上互相“增量同步處理”，這樣一來，就不支援檔案的“刪除、更新”操作的同步了。

早期的想法是，在應用程式層面做控制，當使用者請求在web1伺服器進行上傳寫入的同時，也同步去調用其它web伺服器上的上傳介面，這顯然是得不償失的。所以我們選擇使用Rsync類的軟體來做定時檔案同步的，從而省去了“重複造輪子”的成本，也降低了風險性。

同步操作裡面，一般有比較經典的兩種模型，即推拉模型：所謂“拉”，就是指輪詢地去擷取更新，所謂推，就是發生更改後主動的“推”給其它機器。當然，也可以採用加進階的事件通知機制來完成此類動作。

在高並發寫入的情境中，同步都會出現效率和即時性問題，而且大量檔案同步也是很消耗系統和頻寬資源的（跨網段則更明顯）。  

叢集時代的圖片伺服器架構改進(共用儲存)

 沿用虛擬目錄的方式，通過UNC（網路路徑）的方式實現共用儲存（將upload虛擬目錄指向UNC）

使用者的訪問方式1：

http://www.yourdomain.com/upload/qa/test.jpg

使用者的訪問方式2（可以配置獨立網域名稱）：

http://img.yourdomain.com/upload/qa/test.jpg

支援UNC所在server上配置獨立網域名稱指向，並配置輕量級的web伺服器，來實現獨立圖片伺服器。

   優點： 通過UNC（網路路徑）的方式來進行讀寫操作，可以避免多伺服器之間同步相關的問題。相對來講很靈活，也支援擴容/擴充。支援配置成獨立圖片伺服器和網域名稱訪問，也完整相容舊版本的訪問規則。   

   缺點 ：但是UNC配置有些繁瑣，而且會造成一定的（讀寫和安全）效能損失。可能會出現“單點故障”。如果儲存層級沒有raid或者更進階的災備措施，還會造成資料丟失。

基本架構如所示：

在早期的很多基於Linux開源架構的網站中，如果不想同步圖片，可能會利用NFS來實現。事實證明，NFS在高並發讀寫和海量儲存方面，效率上存在一定問題，並非最佳的選擇，所以大部分互連網公司都不會使用NFS來實現此類應用。當然，也可以通過Windows內建的DFS來實現，缺點是“配置複雜，效率未知，而且缺乏資料大量的實際案例”。另外，也有一些公司採用FTP或Samba來實現。

 

上面提到的幾種架構，在上傳/下載操作時，都經過了Web伺服器（雖然共用儲存的這種架構，也可以配置獨立網域名稱和網站來提供圖片訪問，但上傳寫入仍然得經過Web伺服器上的應用程式來處理），這對Web伺服器來講無疑是造成巨大的壓力。所以，更建議使用獨立的圖片伺服器和獨立的網域名稱，來提供使用者圖片的上傳和訪問。

獨立圖片伺服器/獨立網域名稱的好處

1.  圖片訪問是很消耗伺服器資源的（因為會涉及到作業系統的環境切換和磁碟I/O操作）。分離出來後，Web/App伺服器可以更專註發揮動態處理的能力。

2.  隔離儲存區 (Isolated Storage)，更方便做擴容、容災和資料移轉。

3.  瀏覽器（相同網域名稱下的）並發策略限制，效能損失。

4.  訪問圖片時，請求資訊中總帶cookie資訊，也會造成效能損失。

5.  方便做圖片訪問請求的負載平衡，方便應用各種緩衝策略（HTTP Header、Proxy Cache等），也更加方便遷移到CDN。

......

 

我們可以使用Lighttpd或者Nginx等輕量級的web伺服器來架構獨立圖片伺服器。

當前的圖片伺服器架構（Distributed File System+CDN）

在構建當前的圖片伺服器架構之前，可以先徹底撇開web伺服器，直接配置單獨的圖片伺服器/網域名稱。但面臨如下的問題：

1.  舊圖片資料怎麼辦？能否繼續相容舊圖片路徑訪問規則？

2.  獨立的圖片伺服器上需要提供單獨的上傳寫入的介面（服務API對外發布），安全問題如何保證？

3.  同理，假如有多台獨立圖片伺服器，是使用可擴充的共用儲存方案，還是採用即時同步機制？

 

直到應用層級的（非系統級） DFS（例如FastDFS HDFS MogileFs MooseFS、TFS）的流行，簡化了這個問題：執行冗餘備份、支援自動同步、支援線性擴充、支援主流語言的用戶端api上傳/下載/刪除等操作，部分支援檔案索引，部分支援提供Web的方式來訪問。

考慮到各DFS的特點，用戶端API語言支援情況(需要支援C#)，文檔和案例，以及社區的支援度，我們最終選擇了FastDFS來部署。

唯一的問題是：可能會不相容舊版本的訪問規則。如果將舊圖片一次性匯入FastDFS，但由於舊圖片訪問路徑分布儲存在不同業務資料庫的各個表中，整體更新起來也十分困難，所以必須得相容舊版本的訪問規則。架構升級往往比做全新架構更有難度，就是因為還要相容之前版本的問題。（給飛機在空中換引擎可比造架飛機難得多）

解決方案如下：

首先，關閉舊版本上傳入口（避免繼續使用導致資料不一致）。將舊圖片資料通過rsync工具一次性遷移到獨立的圖片伺服器上（即中描述的Old ImageServer）。在最前端(七層代理，如Haproxy、Nginx)用ACL（訪問規則控制），將舊圖片對應URL規則的請求（正則）匹配到，然後將請求直接轉寄指定的網頁伺服器列表，在該列表中的伺服器上配置好提供圖片（以Web方式）訪問的網站，並加入緩衝策略。這樣實現舊圖片伺服器的分離和緩衝,相容了舊圖片的訪問規則並提升舊圖片訪問效率，也避免了即時同步所帶來的問題。

 

整體架構

基於FastDFS的獨立圖片伺服器叢集架構，雖然已經非常的成熟，但是由於國內“南北互聯”和IDC頻寬成本等問題（圖片是非常消耗流量的），我們最終還是選擇了商用的CDN技術，實現起來也非常容易，原理其實也很簡單，我這裡只做個簡單的介紹：

將img網域名稱cname到CDN廠商指定的網域名稱上，使用者請求訪問圖片時，則由CDN廠商提供智能DNS解析，將最近的（當然也可能有其它更複雜的策略，例如負載情況、健康狀態等）服務節點地址返回給使用者，使用者請求到達指定的伺服器節點上，該節點上提供了類似Squid/Vanish的代理快取服務，如果是第一次請求該路徑，則會從來源站點擷取圖片資源返回用戶端瀏覽器，如果緩衝中存在，則直接從緩衝中擷取並返回給用戶端瀏覽器，完成請求/響應過程。

由於採用了商用CDN服務，所以我們並沒有考慮用Squid/Vanish來重複構建前置代理緩衝。

上面的整個叢集架構，可以很方便的做橫向擴充，能滿足一般垂直領域大型網站的圖片服務需求（當然，像taobao這樣超大規模的可能另當別論）。經測試，提供圖片訪問的單台Nginx伺服器（至強E5四核CPU、16G記憶體、SSD），對小靜態頁面（壓縮後的）可以扛住上萬的並發且毫無壓力。當然，由於圖片本身體積比純文字的靜態頁面大很多，提供圖片訪問的伺服器的抗並發能力，往往會受限於磁碟的I/O處理能力和IDC提供的頻寬。Nginx的抗並發能力還是非常強的，而且對資源佔用很低，尤其是處理靜態資源，似乎都不需要有過多擔心了。可以根據實際訪問量的需求，通過調整Nginx參數，Linux核心調優、緩衝策略等手段做更大程度的最佳化，也可以通過增加伺服器或者升級伺服器配置來做擴充，最直接的是通過購買更進階的存放裝置和更大的頻寬，以滿足更大訪問量的需求。

值得一提的是，在“雲端運算”流行的當下，也推薦高速發展期間的網站，使用“雲端儲存”這樣的方案，既能幫你解決各類儲存、擴充、備災的問題，又能做好CDN加速。最重要的是，價格也不貴。

總結，有關圖片伺服器架構擴充，大致圍繞這些問題展開：

1.   容量規劃和擴充問題。

2.   資料的同步、冗餘和容災。

3.   硬體裝置的成本和可靠性（是普通機械硬碟，還是SSD，或者更高端的存放裝置和方案）。

4.   檔案系統的選擇。根據檔案特性（例如檔案大小、讀寫比例等）選擇是用ext3/4或者NFS/GFS/TFS這些開源的（分布式）檔案系統。

5.   圖片的加速訪問。採用商用CDN或者自建的代理緩衝、web靜態緩衝架構。

6.   舊圖片路徑和訪問規則的相容性，應用程式層面的可擴充，上傳和訪問的效能和安全性等。

 

 

本文首發於InfoQ社區，著作權，轉載請註明出處。