淺論建設中小型企業的高性能linux 架構論文
前言
在當今這樣高速和大數據的互聯網時代，每個企業都希望以最節約成本、最簡單的方式來建設企業網站，而合理的規劃網站架構是保證網站正常運營的基礎，因此我們需要一個高性能、高可用以及高穩定性的網站架構。
通常情況下，公司網站需要提供如下服務，包括：圖片上傳下載、文件上傳下載、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 訪問量，但是也存在著不足的地方，前端過于單薄，需要把靜態文件放到單獨的文件服務器上去，同時一旦最前端掛掉，會導致整個系統的奔潰。但是基于中小型企業的用戶量來說卻是足夠的，不用擔心該問題。
【淺論建設中小型企業的高性能linux 架構論文】相關文章：
淺論小學班級文化建設中的評價策略教學論文03-16
民營中小型企業薪酬激勵淺論11-21
淺論加強文明校園建設中的圖書館建設01-17
談高性能混凝土配制問題與對策論文12-16
淺論酒文化研究的論文提綱12-08
淺論唐代送別詩的特點論文01-14
淺論翻譯的歸化和異化論文06-09
淺論企業儀式在煙草企業文化建設中的作用11-16
教育的語言藝術淺論論文11-13
淺論探索問題轉化方法的途徑的論文12-23