前言
在當今這樣高速和大數據的互聯網時代，每個企業都希望以最節約成本、最簡單的方式來建設企業網站，而合理的規劃網站架構是保證網站正常運營的基礎，因此我們需要一個高性能、高可用以及高穩定性的網站架構。
通常情況下，公司網站需要提供如下服務，包括：圖片上傳下載、檔案上傳下載、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 訪問量，但是也存在着不足的地方，前端過於單薄，需要把靜態檔案放到單獨的檔案服務器上去，同時一旦最前端掛掉，會導致整個系統的奔潰。但是基於中小型企業的用戶量來說卻是足夠的，不用擔心該問題。