轉 高性能網站性能優化與系統架構

一個小型的網站，好比我的網站，可使用最簡單的

html

靜態頁面就實現了，配合一

些圖片達到美化效果，

全部的頁面均存放在一個目錄下，

這樣的網站對系統架構、

性能的要

求都很簡單，

隨着互聯網業務的不斷豐富，

網站相關的技術通過這些年的發展，

已經細分到

很細的方方面面，

尤爲對於大型網站來講，

所採用的技術更是涉及面很是廣，

從硬件到軟件、

編程語言、數據庫、

WebServer

、防火牆等各個領域都有了很高的要求，已經不是原來簡

單的

html

靜態網站所能比擬的。

 

 

 

大型網站，

好比門戶網站。

在面對大量用戶訪問、高併發請求方面，基本的解決方案集

中在這樣幾個環節：

使用高性能的服務器、高性能的數據庫、

高效率的編程語言、

還有高性

能的

Web

容器。可是除了這幾個方面，還無法根本解決大型網站面臨的高負載和高併發問

題。

 

 

 

上面提供的幾個解決思路在必定程度上也意味着更大的投入，

而且這樣的解決思路具有

瓶頸，

沒有很好的擴展性，

下面我從低成本、

高性能和高擴張性的角度來講說個人一些經驗。

 

 

 

1

、

HTML

靜態化

 

 

 

其實你們都知道，效率最高、消耗最小的就是純靜態化的

html

頁面，因此咱們儘量

使咱們的網站上的頁面採用靜態頁面來實現，

這個最簡單的方法其實也是最有效的方法。

但

是對於大量內容而且頻繁更新的網站，

咱們沒法所有手動去挨個實現，

因而出現了咱們常見

的信息發佈系統

CMS

，像咱們常訪問的各個門戶站點的新聞頻道，甚至他們的其餘頻道，

都是經過信息發佈系統來管理和實現的，

信息發佈系統能夠實現最簡單的信息錄入自動生成

靜態頁面，還能具有頻道管理、權限管理、自動抓取等功能，對於一個大型網站來講，擁有

一套高效、可管理的

CMS

是必不可少的。

 

 

 

除了門戶和信息發佈類型的網站，

對於交互性要求很高的社區類型網站來講，

儘量的

靜態化也是提升性能的必要手段，

將社區內的帖子、

文章進行實時的靜態化，

有更新的時候

再從新靜態化也是大量使用的策略，像

Mop

的大雜燴就是使用了這樣的策略，網易社區等

也是如此。同時，

html

靜態化也是某些緩存策略使用的手段，對於系統中頻繁使用數據庫

查詢可是內容更新很小的應用，

能夠考慮使用

html

靜態化來實現，

好比論壇中論壇的公用

設置信息，

這些信息目前的主流論壇均可以進行後臺管理而且存儲在數據庫中，

這些信息其

實大量被前臺程序調用，

可是更新頻率很小，

能夠考慮將這部份內容進行後臺更新的時候進

行靜態化，這樣避免了大量的數據庫訪問請求。

 

 

 

在進行

html

靜態化的時候可使用一種折中的方法，就是前端使用動態實現，在必定

的策略下進行定時靜態化和定時判斷調用，這個能實現不少靈活性的操做。

 

 

 

2

、圖片服務器分離

 

 

 

你們知道，對於

Web

服務器來講，不論是

Apache

、

IIS

仍是其餘容器，圖片是最消

耗資源的，因而咱們有必要將圖片與頁面進行分離，這是基本上大型網站都會採用的策略，

他們都有獨立的圖片服務器，

甚至不少臺圖片服務器。

這樣的架構能夠下降提供頁面訪問請

求的服務器系統壓力，而且能夠保證系統不會由於圖片問題而崩潰。

 

 

 

在應用服務器和圖片服務器上，能夠進行不一樣的配置優化，好比

Apache

在配置

ContentType

的時候能夠儘可能少支持，

儘量少的

LoadModule

，

保證更高的系統消耗和

執行效率。

 

 

 

另外，

在處理靜態頁面或者圖片、

js

等訪問方面，

能夠考慮使用

lighttpd

代替

Apache

，

它提供了更輕量級和更高效的處理能力。

 

 

 

3

、數據庫集羣和庫表散列

 

 

 

大型網站都有複雜的應用，

這些應用必須使用數據庫，

那麼在面對大量訪問的時候，

數

據庫的瓶頸很快就能顯現出來，

這時一臺數據庫將很快沒法知足應用，

因而咱們須要使用數

據庫集羣或者庫表散列

在數據庫集羣方面，不少數據庫都有本身的解決方案，

Oracle

、

Sybase

等都有很好

的方案，經常使用的

MySQL

提供的

Master/Slave

也是相似的方案，您使用了什麼樣的

DB

，

就參考相應的解決方案來實施便可。

 

 

 

上面提到的數據庫集羣因爲在架構、

成本、

擴張性方面都會受到所採用

DB

類型的限制，

因而咱們須要從應用程序的角度來考慮改善系統架構，

庫表散列是經常使用而且最有效的解決方

案。

咱們在應用程序中安裝業務和應用或者功能模塊將數據庫進行分離，

不一樣的模塊對應不

同的數據庫或者表，

再按照必定的策略對某個頁面或者功能進行更小的數據庫散列，

好比用

戶表，

按照用戶

ID

進行表散列，

這樣就可以低成本的提高系統的性能而且有很好的擴展性。

sohu

的論壇就是採用了這樣的架構，將論壇的用戶、設置、帖子等信息進行數據庫分離，

而後對帖子、用戶按照板塊和

ID

進行散列數據庫和表，最終能夠在配置文件中進行簡單的

配置便能讓系統隨時增長一臺低成本的數據庫進來補充系統性能。

 

 

 

4

、緩存

 

 

 

緩存一詞搞技術的都接觸過，

不少地方用到緩存。

網站架構和網站開發中的緩存也是非

常重要。這裏先講述最基本的兩種緩存。高級和分佈式的緩存在後面講述。

 

 

 

架構方面的緩存，對

Apache

比較熟悉的人都能知道

Apache

提供了本身的

mod_proxy

緩存模塊，也可使用外加的

Squid

進行緩存，這兩種方式都可以有效的提

高

Apache

的訪問響應能力。

 

 

 

網站程序開發方面的緩存，

Linux

上提供的

Memcached

是經常使用的緩存方案，

很多

web

編程語言都提供

memcache

訪問接口，

php

、

perl

、

c

和

java

都有，能夠在

web

開發中

使用，能夠實時或者

Cron

的把數據、對象等內容進行緩存，策略很是靈活。一些大型社區

使用了這樣的架構。

 

 

 

另外，在使用

web

語言開發的時候，各類語言基本都有本身的緩存模塊和方法，

PHP

有

Pear

的

Cache

模塊和

eAccelerator

加速和

Cache

模塊，還要知名的

Apc

、

XCache

（國人開發的，

支持！

）

php

緩存模塊，

Java

就更多了，

.net

不是很熟悉，

相信也確定有。

 

 

 

5

、鏡像

 

 

 

鏡像是大型網站常採用的提升性能和數據安全性的方式，

鏡像的技術能夠解決不一樣網絡

接入商和地域帶來的用戶訪問速度差別，好比

ChinaNet

和

EduNet

之間的差別就促使了

不少網站在教育網內搭建鏡像站點，

數據進行定時更新或者實時更新。

在鏡像的細節技術方

面，

這裏不闡述太深，

有不少專業的現成的解決架構和產品可選。

也有廉價的經過軟件實現

的思路，好比

Linux

上的

rsync

等工具。

 

 

 

6

、負載均衡

 

 

 

負載均衡將是大型網站解決高負荷訪問和大量併發請求採用的終極解決辦法。

 

 

 

負載均衡技術發展了多年，

有不少專業的服務提供商和產品能夠選擇，

我我的接觸過一

些解決方法，其中有兩個架構能夠給你們作參考。另外有關初級的負載均衡

DNS

輪循和較

專業的

CDN

架構就很少說了。

 

 

 

6.1

硬件四層交換

 

 

 

第四層交換使用第三層和第四層信息包的報頭信息，

根據應用區間識別業務流，

將整個

區間段的業務流分配到合適的應用服務器進行處理。第四層交換功能就象是虛

IP

，指向物

理服務器。

它傳輸的業務服從的協議多種多樣，

有

HTTP

、

FTP

、

NFS

、

Telnet

或其餘協議。

這些業務在物理服務器基礎上，

須要複雜的載量平衡算法。

在

IP

世界，

業務類型由終端

TCP

或

UDP

端口地址來決定，

在第四層交換中的應用區間則由源端和終端

IP

地址、

TCP

和

UDP

端口共同決定。

 

 

 

在硬件四層交換產品領域，有一些知名的產品能夠選擇，好比

Alteon

、

F5

等，這些產

品很昂貴，可是物有所值，可以提供很是優秀的性能和很靈活的管理能力。

Yahoo

中國當

初接近

2000

臺服務器使用了三四臺

Alteon

就搞定了。

 

 

 

6.2

軟件四層交換

 

 

 

你們知道了硬件四層交換機的原理後，基於

OSI

模型來實現的軟件四層交換也就應運

而生，

這樣的解決方案實現的原理一致，

不過性能稍差。

可是知足必定量的壓力仍是遊刃有

餘的，有人說軟件實現方式其實更靈活，處理能力徹底看你配置的熟悉能力。

 

 

 

軟件四層交換咱們可使用

Linux

上經常使用的

LVS

來解決，

LVS

就是

LinuxVirtualServer

，他提供了基於心跳線

heartbeat

的實時災難應對解決方案，提升系

統的魯棒性，同時可供了靈活的虛擬

VIP

配置和管理功能，能夠同時知足多種應用需求，

這對於分佈式的系統來講必不可少。

 

 

 

一個典型的使用負載均衡的策略就是，在軟件或者硬件四層交換的基礎上搭建

squid

集羣，

這種思路在不少大型網站包括搜索引擎上被採用，

這樣的架構低成本、

高性能還有很

強的擴張性，

隨時往架構裏面增減節點都很是容易。

這樣的架構我準備空了專門詳細整理一

下和你們探討。

 

 

 

總結：

 

 

 

對於大型網站來講，

前面提到的每一個方法可能都會被同時使用到，

這裏介紹得比較淺顯，

具體實現過程當中不少細節還須要你們慢慢熟悉和體會，有時一個很小的

squid

參數或者

apache

參數設置，

對於系統性能的影響就會很大，

但願你們一塊兒討論，

達到拋磚引玉之效。