網站架構

一：硬架構
　　1：機房的選擇：
　　在選擇機房的時候，根據網站用戶的地域分佈，能夠選擇網通或電信機房，但更多時候，可能雙線機 房纔是合適的。越大的城市，機房價格越貴，從成本的角 度看能夠在一些中小城市託管服務器，好比說北京的公司能夠考慮把服務器託管在天津，廊坊等地，不是特別遠，可是價格會便宜不少。
　　2：帶寬的大小：
　　一般老闆花錢請咱們架構網站的時候，會給咱們提出一些目標，諸如網站天天要能承受100萬PV的訪問量等等。這時咱們要預算一下大概須要多大的帶寬，計算帶寬大小主要涉及兩個指標（峯值流量和頁面大小），咱們不妨在計算前先作出必要的假設：
　　第一：假設峯值流量是平均流量的5倍。
　　第二：假設每次訪問平均的頁面大小是100K字節左右。
　　若是100萬PV的訪問量在一天內平均分佈的話，摺合到每秒大約12次訪問，若是按平均每次訪 問頁面的大小是100K字節左右計算的話，這12次訪 問總計大約就是1200K字節，字節的單位是Byte，而帶寬的單位是bit，它們之間的關係是1Byte = 8bit，因此1200K Byte大體就至關於9600K bit，也就是9Mbps的樣子，實際狀況中，咱們的網站必須能在峯值流量時保持正常訪問，因此按照假設的峯值流量算，真實帶寬的需求應該在45Mbps 左右。
　　固然，這個結論是創建在前面提到的兩點假設的基礎上，若是你的實際狀況和這兩點假設有出入，那麼結果也會有差異。
　　3：服務器的劃分：
　　先看咱們都須要哪些服務器：圖片服務器，頁面服務器，數據庫服務器，應用服務器，日誌服務器等等。
　　對於訪問量大點的網站而言，分離單獨的圖片服務器和頁面服務器至關必要，咱們能夠用 lighttpd來跑圖片服務器，用apache來跑頁面服務 器，固然也能夠選擇別的，甚至，咱們能夠擴展成不少臺圖片服務器和不少臺頁面服務器，並設置相關域名，如img.domain.com和 www.domain.com，頁面裏的圖片路徑都使用絕對路徑，如<img src="http://img.domain.com/abc.gif" />，而後設置DNS輪循，達到最初級的負載均衡。固然，服務器多了就不可避免的涉及一個同步的問題，這個可使用rsync軟件來搞定。
　　數據庫服務器是重中之重，由於網站的瓶頸問題十有八九是出在數據庫身上。如今通常的中小網站多 使用MySQL數據庫，不過它的集羣功能彷佛尚未達 到stable的階段，因此這裏不作評價。通常而言，使用MySQL數據庫的時候，咱們應該搞一個主從（一主多從）結構，主數據庫服務器使用innodb 表結構，從數據服務器使用myisam表結構 ，充分發揮它們各自的優點，並且這樣的主從結構分離了讀寫操做，下降了讀操做的壓力，甚至咱們還能夠設定一個 專門的從服務器作備份服務器，方便備份。否則若是你只有一臺主服務器，在大數據量的狀況下，mysqldump基本就沒戲了，直接拷貝數據文件的話，還得 先中止數據庫服務再拷貝，不然備份文件會出錯。但對於不少網站而言，即便數據庫服務僅中止了一秒也是不可接受的。若是你有了一臺從數據庫服務器，在備份數 據的時候，能夠先中止服務（slave stop）再備份，再啓動服務（slave start）後從服務器會自動從主服務器同步數據，一切都沒有影響。可是主從結構也是有致命缺點的，那就是主從結構只是下降了讀操做的壓力，卻不能下降寫 操做的壓力。爲了適應更大的規模，可能只剩下最後這招了：橫向/縱向分割數據庫。所謂橫向分割數據庫，就是把不一樣的表保存到不一樣的數據庫服務器上，好比說 用戶表保存在A數據庫服務器上，文章表保存在B數據庫服務器上，固然這樣的分割是有代價的，最基本的就是你無法進行LEFT JOIN之類的操做了 。所謂縱向分割數據庫，通常是指按照用戶標識（user_id）等來劃分數據存儲的服務器，好比說：咱們有5臺數據庫服務器，那麼 「user_id % 5 + 1」等於1的就保存到1號服務器，等於2的就保存到2好服務器，以此類推，縱向分隔的原則有不少種，能夠視狀況選擇。不過和橫向分割數據庫同樣，縱向分割 數據庫也是有代價的，最基本的就是咱們在進行如COUNT, SUM等彙總操做的時候會麻煩不少 。綜上所述，數據庫服務器的解決方案通常視狀況每每是一個混合的方案，以其發揮各類方案的優點，有時候還須要藉助 memcached之類的第三方軟件，以便適應更大訪問量的要求。
　　若是有專門的應用服務器來跑PHP腳本是最合適不過的了，那樣咱們的頁面服務器只保存靜態頁面 就能夠了，能夠給應用服務器設置一些諸如 app.domain.com之類的域名來和頁面服務器加以區別。對於應用服務器，我仍是更傾向於使用prefork模式的apache，配上必要的 xcache之類的PHP緩存軟件，加載模塊要越少越好，除了mod_rewrite等必要的模塊，沒必要要的東西通通捨棄，儘可能減小httpd進程的內存 消耗，而那些圖片服務器，頁面服務器等靜態內容就可使用lighttpd或者tux來搞，充分發揮各類服務器的特色。 
　　若是條件容許，獨立的日誌服務器也是必要的，通常小網站的作法都是把頁面服務器和日誌服務器合 二爲一了，在凌晨訪問量不大的時候cron運行前一天 的日誌計算，不過若是你使用awstats之類的日誌分析軟件，對於百萬級訪問量而言，即便按天歸檔，也會消耗不少時間和服務器資源去計算，因此分離單獨 的日誌服務器仍是有好處的，這樣不會影響正式服務器的工做狀態。 
　　二：軟架構
　　1：框架的選擇：
　　如今的PHP框架有不少選擇，好比：CakePHP，Symfony，Zend Framework等等，至於應該使用哪個並無惟一的答案，要根據Team裏團隊成員對各個框架的瞭解程度而定。不少時候，即便沒有使用框架，同樣能 寫出好的程序來，好比Flickr聽說就是用Pear+Smarty這樣的類庫寫出來的，因此，是否用框架，用什麼框架，通常不是最重要的，重要的是咱們 的編程思想裏要有框架的意識。
　　2：邏輯的分層：
　　網站規模到了必定的程度以後，代碼裏各類邏輯糾纏在一塊兒，會給維護和擴展帶來巨大的障礙，這時咱們的解決方式其實很簡單，那就是重構，將邏輯進行分層。一般，自上而下能夠分爲表現層，應用層，領域層，持久層。
　　所謂表現層，並不只僅就指模板，它的範圍要更廣一些，全部和表現相關的邏輯都應該被歸入表現層 的範疇。好比說某處的字體要顯示爲紅色，某處的開頭要 空兩格，這些都屬於表現層。不少時候，咱們容易犯的錯誤就是把本屬於表現層的邏輯放到了其餘層面去完成，這裏說一個很常見的例子：咱們在列表頁顯示文章標 題的時候，都會設定一個最大字數，一旦標題長度超過了這個限制，就截斷，並在後面顯示「..」，這就是最典型的表現層邏輯，可是實際狀況，有不少程序員都 是在非表現層代碼裏完成數據的獲取和截斷，而後賦值給表現層模板，這樣的代碼最直接的缺點就是一樣一段數據，在這個頁面我可能想顯示前10個字，再另外一個 頁面我可能想顯示前15個字，而一旦咱們在程序裏固化了這個字數，也就喪失了可移植性。正確的作法是應該作一個視圖助手之類的程序來專門處理此類邏輯，比 如說：Smarty裏的truncate就屬於這樣的視圖助手（不過它那個實現不適合中文）。
　　所謂應用層，它的主要做用是定義用戶能夠作什麼，並把操做結果反饋給表現層。至於如何作，一般 不是它的職責範圍（而是領域層的職責範圍），它會經過 委派把如何作的工做交給領域層去處理。在使用MVC架構的網站中，咱們能夠看到相似下面這樣的URL： domain.com/articles/view/123，其內部編碼實現，通常就是一個Articles控制器類，裏面有一個view方法，這就是一 個典型的應用層操做，由於它定義了用戶能夠作一個查看的動做。在MVC架構中，有一個準則是這麼說的：Rich Model Is Good。言外之意，就是Controller要保持「瘦」一些比較好，進而說明應用層要儘可能簡單，不要包括涉及領域內容的邏輯。
　　所謂領域層，最直接的解釋就是包含領域邏輯的層。它是一個軟件的靈魂所在。先來看看什麼叫領域 邏輯，簡單的說，具備明確的領域概念的邏輯就是領域邏 輯，好比咱們在ATM機上取錢，過程大體是這樣的：插入銀聯卡，輸入密碼，輸入取款金額，肯定，拿錢，而後ATM吐出一個交易憑條。在這個過程當中，銀聯卡 在ATM機器裏完成錢從賬戶上劃撥的過程就是一個領域邏輯，由於取錢在銀行中是一個明確的領域概念，而ATM機吐出一個交易憑條則不是領域邏輯，而僅是一 個應用邏輯，由於吐出交易憑條並非銀行中一個明確的領域概念，只是一種技術手段，對應的，咱們取錢後不吐交易憑條，而發送一條提醒短信也是可能的，但並 不是必定如此，若是在實際狀況中，咱們要求取款後必須吐出交易憑條，也就是說吐出交易憑條已經和取款緊密結合，那麼你也能夠把吐出交易憑條看做是領域邏輯 的一部分，一切都以問題的具體狀況而定。在Eric那本經典的領域驅動設計中，把領域層分爲了五種基本元素：實體，值對象，服務，工廠，倉儲。具體能夠參 閱書中的介紹。領域層最常犯的錯誤就是把本應屬於領域層的邏輯泄露到了其餘層次，好比說在一個CMS系統，對熱門文章的定義是這樣的：天天被瀏覽的次數多 於1000次，被評論的次數多於100次，這樣的文章就是熱門文章。對於一個CMS來講，熱門文章這個詞無疑是一個重要的領域概念，那麼咱們如何實現這個 邏輯的設計的？你可能會給出相似下面的代碼：「SELECT ... FROM ... WHERE 瀏覽 > 1000 AND 評論 > 100」，沒錯，這是最簡單的實現方式，可是這裏須要注意的是「天天被瀏覽的次數多於1000次，被評論的次數多於100次」這個重要的領域邏輯被隱藏到 了SQL語句中，SQL語句顯然不屬於領域層的範疇，也就是說，咱們的領域邏輯泄露了。
　　所謂持久層，就是指把咱們的領域模型保存到數據庫中。由於咱們的程序代碼是面向對象風格的，而 數據庫通常是關係型的數據庫，因此咱們須要把領域模型 碾平，才能保存到數據庫中，可是在PHP裏，直到目前尚未很是好的ORM出現，因此這方面的解決方案不是特別多，參考Martin的企業應用架構模式一 書，大體可使用的方法有行數據入口（Row Data Gateway）或者表數據入口（Table Data Gateway），或者把領域層和持久層合二爲一變成活動記錄（Active Record）的方式。

轉自：http://zhengdl126.iteye.com/blog/450262