建設中小型企業的高性能linux架構

王 康

（沈陽師范大學科信軟件學院，遼寧沈陽110034）

0 前言

在當今這樣高速和大數據的互聯網時代，每個企業都希望以最節約成本、最簡單的方式來建設企業網站，而合理的規劃網站架構是保證網站正常運營的基礎，因此我們需要一個高性能、高可用以及高穩定性的網站架構。

通常情況下，公司網站需要提供如下服務，包括：圖片上傳下載、文件上傳下載、Web頁面訪問、數據庫訪問、應用服務和日志等，這些服務往往由一臺或者多臺服務器提供，另外為了保證服務器的穩定運行，還要考慮加入必要的容錯機制，如數據庫的備份、等，服務器越少，硬件成本越低，但服務器壓力增大，性能降低，維護成本會升高。服務器劃分的過細，雖能提升網站性能，但服務器間協同工作開發成本提高，硬件成本也會增加。因此，各公司都試圖從軟架構和硬架構上進行了最大限度的改造，設計能夠很好的與自身的業務吻合，最大限度的提供高性能的服務架構。

綜合考慮以上問題，本文結合中小型企業網站自身特點，提出一套能滿足中小型企業網站業務需求、并且能最大限度的提供高性能、低成本的服務器架構。

1 構建高性能的服務器

中小型企業網站具有以下特點：

（1）應用簡單，中小型企業網站通常以Web應用為主，配合獨立的數據存儲。

（2）訪問內容重復性高，每個用戶訪問的幾乎都是一樣的數據，而且短時間內變化不大。

（3）訪問時間集中，用戶訪問都集中在某一個時間段，所以需要一定的容錯機制和高負載性。

（4）日均訪問量都在百萬PV以下。

針對中小企業網站所具有的特點，提出以下幾點解決方案：

（1）Web服務器與數據庫服務器分離，這樣做一方面降低磁盤IO，可以減緩Web服務器也可以提高數據庫服務器性能，另外，數據庫服務器對內網使用，提高安全性能。

（2）提供緩存機制，對網站中包含的靜態的公共數據進行緩存，而對需要實時更新的網站內容不進行緩存，減少磁盤IO的次數，同時提高網站性能。

（3）對于一個網站來說，查詢靜態資源的量顯然多與動態頁面的量，網站最影響性能的地方就在于靜態文件的處理，從提升網站性能的角度考慮，靜態資源不應和應用服務器放在一起，可以使用反向代理分離靜態資源與動態頁面。

（4）為保證Web服務穩定性，采用雙應用服務器，并且把session管理放到內存數據庫進行管理，分擔一部分應用服務器壓力，從而提升服務器的處理性能。

（5）后端數據庫采用主從雙機熱備數據庫配置，保障兩臺數據庫的數據一致，以保護企業數據結構不受故障、災難、錯誤和崩潰的影響，當出現主庫數據異常情況時，備庫隨時可用.

服務器框架設計如圖1。

該框架分為三層：負載均衡層、應用服務層、數據存儲層。

（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是通過對數據的復制來保證數據的統一性，如圖2所示。

整體來說，MySQL的復制分為三個步驟：

（1）Master將改變記錄到二進制日志(binary log)中。

（2）Slave將master的binary log events拷貝到它的中繼日志(relay log)。

（3）Slave重做中繼日志中的事件，將改變反映它自己的數據。

圖2

2 總結

針對與中小型企業來說，該套系統能夠輕松的應對日均百萬的PV訪問量，但是也存在著不足的地方，前端過于單薄，需要把靜態文件放到單獨的文件服務器上去，同時一旦最前端掛掉，會導致整個系統的奔潰。但是基于中小型企業的用戶量來說卻是足夠的，不用擔心該問題。

［1］http://bbs.nanjimao.com/thread-855-1-1.html 2011-9-8 15:11:57[OL].

［2］http://www.open-open.com/doc/view/1439 c1052 f4 c4851 bf48 fdd1 f7e7bb1d.[OL].

［3］http://blog.csdn.net/maikforever/article/details/11085615）2013-09-04,17:54.

［4］http://blog.csdn.net/lk519186921/article/details/7057492）2011-12-09 16:09

［5］威萊尼奧斯.Linux集群體系結構[M].馬朝暉,譯.機械工業出版社,2003:50-58.