構建在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服務器來講無疑是造成巨大的壓力。所以，更建議使用獨立的圖片服務器和獨立的域名，來提供用戶圖片的上傳和訪問。

　　獨立圖片服務器/獨立域名的好處

• 圖片訪問是很消耗服務器資源的（因為會涉及到操作系統的上下文切換和磁盤I/O操作）。分離出來后，Web/App服務器可以更專注發揮動態處理的能力。
• 獨立存儲，更方便做擴容、容災和數據遷移。
• 瀏覽器（相同域名下的）并發策略限制，性能損失。
• 訪問圖片時，請求信息中總帶cookie信息，也會造成性能損失。
• 方便做圖片訪問請求的負載均衡，方便應用各種緩存策略（HTTP Header、Proxy Cache等），也更加方便遷移到CDN。

　　......

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

　　當前的圖片服務器架構（分布式文件系統+CDN）

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

1. 舊圖片數據怎么辦？能否繼續兼容舊圖片路徑訪問規則？
2. 獨立的圖片服務器上需要提供單獨的上傳寫入的接口（服務API對外發布），安全問題如何保證？
3. 同理，假如有多臺獨立圖片服務器，是使用可擴展的共享存儲方案，還是采用實時同步機制？

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

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

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

　　解決方案如下：

　　首先，關閉舊版本上傳入口（避免繼續使用導致數據不一致）。將舊圖片數據通過rsync工具一次性遷移到獨立的圖片服務器上（即下圖中描述的Old Image Server）。在最前端(七層代理，如Haproxy、Nginx)用ACL（訪問規則控制），將舊圖片對應URL規則的請求（正則）匹配到，然后將請求直接轉發指定的web 服務器列表，在該列表中的服務器上配置好提供圖片（以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. 舊圖片路徑和訪問規則的兼容性，應用程序層面的可擴展，上傳和訪問的性能和安全性等。

　　作者介紹

　　丁浪，技術架構師。擅長大規模（高并發、高可用、海量數據）互聯網架構，專注于打造“高性能，可擴展/伸縮，穩定，安全”的技術架構。 熱衷于技術研究和分享，曾分享和獨立撰寫過大量技術文章。