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

前言：

大意“小”是特指秋色園（流量小，伺服器配置低）的意思，畢竟文章都是從實戰後才寫出來的。

關于現實網站的抗并發實情：

由于每個網站的性能點，最後都離不開抗并發這一話題。

也許，網站本身并沒有那麼多并發通路，但為何還要抗并發？

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

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

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

什麼樣的站點能抗的起高并發？

若除卻外部帶寬等因素造成的外部影響，則内部答案隻有一個：靜态網站。

靜态網站何以能抗高并發？

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

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

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

當然了，也不是所有站點都适合靜态化，是以技術架構優化顯的特别的重要。

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

CSDN首頁的文章：2000并發以下挂了，這塊是java提供服務。

而CSDN的部落格：能頂好萬級的并發，這塊是ASP.NET提供服務。

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

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

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

本次實踐分離方案的背景：

在秋色園系統的優化文章中，都似多似少的提到了搜尋這塊引發的CPU命案。

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

構思中：

于是三七二十七，就開始想了：

目前秋色園的URL搜尋這一塊為：www.cyqdata.com/search/類型/搜尋内容。

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

想了兩種方案：

A：是弄個二級域名，建個網站來運作，這個需要動點代碼：

這種方案，要修改URL變為so.cyqdata.com/類型/搜尋内容，看似改動不少，需要調整URL機制和301處理，預計整體在30-60分鐘内應該可以解決完。

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

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

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

這種方案，一般就局域伺服器隻能在區域網路内了。

方案選擇：

綜合秋色園目前的情況，也就一台VPS。

兩個方案的差別就在于動代碼和不動代碼了。

後來我選擇了不動代碼，因為實際的效果幾乎是一樣的，是以就不動代碼了。

方案二實施過程：

1：在IIS 6 裡建立一虛拟目錄search，建立右鍵屬性，應用程式名那裡對應的按鈕點選“建立應用程式”然後虛拟目錄就轉化為應用程式了。

2：項目路徑還是原來的項目路徑，然後設定新的應用程式池，最終如下圖：

總結：

一般一個項目大了後，或者邏輯變的複雜後，往往的解決方案就是分解成子項目。

而分解的方案：一般是根據域名，或首頁節點目錄。

後來思緒了一下，比如目前部落格的URL是：xxx.com/cyq1162/admin/...

如果一開始考慮把它設計成：xxx.com/admin/cyq1162/...

這樣是不是也就可以輕松的把部落格的前背景分離開來。

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

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

     本文轉自cyq1162 51CTO部落格，原文連結：http://blog.51cto.com/cyq1162/1211354，如需轉載請自行聯系原作者