前言
在當今這樣高速和大資料的網際網路時代，每個企業都希望以最節約成本、最簡單的方式來建設企業網站，而合理的規劃網站架構是保證網站正常運營的基礎，因此我們需要一個高效能、高可用以及高穩定性的網站架構。
通常情況下，公司網站需要提供如下服務，包括：圖片上傳下載、檔案上傳下載、Web 頁面訪問、資料庫訪問、應用服務和日誌等，這些服務往往由一臺或者多臺伺服器提供，另外為了保證伺服器的穩定執行，還要考慮加入必要的容錯機制，如資料庫的備份、等，伺服器越少，硬體成本越低，但伺服器壓力增大，效能降低，維護成本會升高。伺服器劃分的過細，雖能提升網站效能，但伺服器間協同工作開發成本提高，硬體成本也會增加。因此，各公司都試圖從軟架構和硬架構上進行了最大限度的改造，設計能夠很好的與自身的業務吻合，最大限度的提供高效能的服務架構。
綜合考慮以上問題，本文結合中小型企業網站自身特點，提出一套能滿足中小型企業網站業務需求、並且能最大限度的提供高效能、低成本的伺服器架構。
1 構建高效能的伺服器
中小型企業網站具有以下特點：
(1)應用簡單，中小型企業網站通常以Web 應用為主，配合獨立的資料儲存。
(2)訪問內容重複性高，每個使用者訪問的幾乎都是一樣的資料，而且短時間內變化不大。
(3)訪問時間集中，使用者訪問都集中在某一個時間段，所以需要一定的容錯機制和高負載性。
(4)日均訪問量都在百萬PV 以下。針對中小企業網站所具有的特點，提出以下幾點解決方案：
(1)Web 伺服器與資料庫伺服器分離， 這樣做一方面降低磁碟IO，可以減緩Web 伺服器也可以提高資料庫伺服器效能，另外，資料庫伺服器對內網使用，提高安全效能。
(2)提供快取機制，對網站中包含的靜態的公共資料進行快取，而對需要實時更新的網站內容不進行快取，減少磁碟IO 的次數，同時提高網站效能。
(3)對於一個網站來說，查詢靜態資源的量顯然多與動態頁面的量，網站最影響效能的地方就在於靜態檔案的處理，從提升網站效能的角度考慮，靜態資源不應和應用伺服器放在一起，可以使用反向代理分離靜態資源與動態頁面。
(4)為保證Web 服務穩定性，採用雙應用伺服器，並且把session管理放到記憶體資料庫進行管理，分擔一部分應用伺服器壓力，從而提升伺服器的處理效能。
(5)後端資料庫採用主從雙機熱備資料庫配置，保障兩臺資料庫的資料一致，以保護企業資料結構不受故障、災難、錯誤和崩潰的'影響，當出現主庫資料異常情況時，備庫隨時可用.伺服器框架設計。
該框架分為三層：負載均衡層、應用服務層、資料儲存層。
(1) 負載均衡層由兩部分組成，Squid 作為負載均衡的第一層，Web 程式本身訪問量最大的是一些靜態檔案(JS、CSS、圖片檔案等)，幾乎佔了半數以上的訪問請求，因此最前端使用Squid 完成靜態資源快取，Squid 自身支援多重快取策略：最少近來使用(LRU)，貪婪對偶大小次數(GDSF)和動態衰老最少經常使用(LFUDA)，使用Squid 可以有效降低磁碟I/O 次數，縮短響應時間，提升Web 服務效能。Nginx 作為負載均衡的第二層，用來處理一些靜態檔案，能夠大量減少應用伺服器的壓力，讓應用伺服器僅僅只作為一個處理業務的容器，職責單一化。通過負載均衡這兩層的過濾，大量請求都被Squid 和Nginx 攔截下，使得後面的業務層可以專注完成實際業務處理，從而有效提高伺服器效能。另外，Squid 和Nginx 誰作為負載均衡第一層都可以，使用者可根據實際情況作為調整。
(2)應用服務層，用來處理一些動態的業務邏輯，這裡以Tomcat伺服器為例，一個Tomcat 已經足夠應對中小型企業的使用者訪問量，經過一些嘗試，在每分鐘訪問量在4000 左右PV 的情況下，到達Tomcat的請求量最多也就上百左右。
從實踐經驗來說， 應用伺服器常常因為一些升級和不穩定功能，導致Tomcat 在執行一段時間後服務掛掉的情況， 應用伺服器在進行大量計算的時候需要佔有更多的CPU， 導致響應慢和記憶體不足的多種情況，同時多個使用者的登入也會給應用伺服器記憶體產生一部分的記憶體壓力。針對這一情況，可以採用多個應用伺服器去處理業務，並且把Session 的管理從應用伺服器中分離出來，讓多個應用伺服器去處理業務，並且採用單獨的Redis 記憶體資料庫去進行管理和連線多個應用伺服器。
(3)資料儲存層，為保證資料的完整性、防止資料丟失，採用主、從資料庫伺服器的設計方式， 雙機熱備的這種方式主要是通過主機，把資料複製到相應的其他從伺服器上去(Slaves)。主伺服器將更新寫進二進位制日誌檔案中， 並且維護檔案的一個索引，Slaves 連線上主伺服器(Master)從伺服器在日誌中讀取最後一次更新的位置，當主伺服器掛掉的時候能夠進行切換。
MySQL 是通過對資料的複製來保證資料的統一性。整體來說，MySQL 的複製分為三個步驟：
(1)Master 將改變記錄到二進位制日誌(binary log)中。
(2)Slave 將master 的binary log events 拷貝到它的中繼日誌(relaylog)。
(3)Slave 重做中繼日誌中的事件，將改變反映它自己的資料。
2 總結
針對與中小型企業來說， 該套系統能夠輕鬆的應對日均百萬的PV 訪問量，但是也存在著不足的地方，前端過於單薄，需要把靜態檔案放到單獨的檔案伺服器上去，同時一旦最前端掛掉，會導致整個系統的奔潰。但是基於中小型企業的使用者量來說卻是足夠的，不用擔心該問題。