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

構建在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的方式寫入檔案。

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

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

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

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

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

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

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

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

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

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

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

基本架構如下圖所示：

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