小網站架構最佳化-提升抗並發能力：子應用程式分離方案

前言：標題為啥要加個“小”，只因為上一篇文章“小網站架構最佳化：從100並發抗到4000並發”，帶了個“小”字，所以這篇也順流加個“小”了。
大意“小”是特指秋色園流量小，伺服器配置低）的意思，畢竟文章都是從實戰後才寫出來的。

關於現實網站的抗並發實情：

由於每個網站的效能點，最後都離不開抗並發這一話題。

也許，網站本身並沒有那麼多並發訪問，但為何還要抗並發？

因為現實不是每個人都是善良的，商業競爭也很激烈，競爭者間時不時的互相攻擊網站也很普遍。

昨天才一網友向我說起，他朋友的網站，逢周一就會被競爭者攻擊，導致業務無法開展，換伺服器也無濟於事。

所以，提升網站的抗並發能力，除了抵抗使用者的高峰期訪問，也是是自我網站保護的一種手段。

什麼樣的網站能抗的起高並發？

若除卻外部頻寬等因素造成的外部影響，則內部答案只有一個：靜態網站。

靜態網站何以能抗高並發？

因為靜態頁面據說在作業系統核心級就能快取資料並做出響應，所以抗並發能力理論上是最強的。

所以，你看看電商網站，除卻技術背後的實現，你能看到的頁面，多數是靜態頁面。

所以技術的背後是Java還是.net還是php，看似就不是那麼的特別了。

當然了，也不是所有網站都適合靜態化，所以技術架構最佳化顯的特別的重要。

根據某網友提供的資料，僅供參考：

CSDN首頁的文章：2000並發以下掛了，這塊是java提供服務。
而CSDN的部落格：能頂好萬級的並發，這塊是ASP.NET提供服務。

而CSDN的論壇：能頂好幾十級以上的並發，這就是靜態化的結果。

所以那篇很火的“去.NET化的文章”，可能是作者個人意淫，當然了，這些資料可能也是意淫的結果，不一定所屬事實。

所以，要提高抗並發數，高配的伺服器不是全部，還需要合理的代碼架構最佳化：

本次實踐分離方案的背景：在秋色園系統的最佳化文章中，都似多似少的提到了搜尋這塊引發的CPU命案。
某天，我想起了“IIs 網站應用程式程式與虛擬目錄的區別及進階應用程式說明”這篇文章的內容。

有了想把搜尋獨立出去的想法，這樣即使搜尋掛了，也不影響網站訪問，更不用擔心搜尋引發的CPU命案。

構思中：

於是三七二十七，就開始想了：
目前秋色園的URL搜尋這一塊為：www.cyqdata.com/search/類型/搜尋內容。

而文章的關鍵字一般部落格為設定為tag，引到文章，而我是引到搜尋區）。

想了兩種方案：

A：是弄個次層網域，建個網站來運行，這個需要動點代碼：這種方案，要修改URL變為so.cyqdata.com/類型/搜尋內容，看似改動不少，需要調整URL機制和301處理，預計整體在30-60分鐘內應該可以解決完。

這種方案的好處是，後續擴充可以部署到其它伺服器。

B：直接使用子應用程式，可以不改動代碼，直接把搜尋這塊分離獨立子應用程式運行：

這種方案，代碼不用改，因為根據search建立子應用程式即可。

這種方案，一般就局網域服務器只能在區域網路內了。

方案選擇：

綜合秋色園目前的情況，也就一台VPS。
兩個方案的區別就在於動代碼和不動代碼了。後來我選擇了不動代碼，因為實際的效果幾乎是一樣的，所以就不動代碼了。

方案二實施過程：

1：在IIS 6 裡建立一虛擬目錄search，建立右鍵屬性，應用程式名稱那裡對應的按鈕點擊“建立應用程式”然後虛擬目錄就轉化為應用程式了。
2：項目路徑還是原來的項目路徑，然後設定新的應用程式集區，最終如：650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131228/11413642M-0.jpg" border="0" align="absmiddle" />

總結：

一般一個項目大了後，或者邏輯變的複雜後，往往的解決方案就是分解成子項目。
而分解的方案：一般是根據網域名稱，或首頁節點目錄。

後來思緒了一下，比如目前部落格的URL是：xxx.com/cyq1162/admin/...如果一開始考慮把它設計成：xxx.com/admin/cyq1162/...這樣是不是也就可以輕鬆的把部落格的前後台分離開來。

當然了，分成多個進程，是需要思考，是否有涉及直接的通訊。

文本就介紹到這裡了，僅提供一種參考方案。