機房的選擇
在選擇機房的時候，根據網站用戶的地域分布，可以選擇網通或電信機房，但更多時候，可能雙線機房才是合適的。越大的城市，機房價格越貴，從成本的角 度看可以在壹些中小城市托管服務器，比如說北京的公司可以考慮把服務器托管在天津，廊坊等地，不是特別遠，但是價格會便宜很多。
軟架構
框架的選擇
現在的PHP框架有很多選擇，比如：CakePHP，Symfony，Zend Framework等等，至於應該使用哪壹個並沒有唯壹的答案，要根據Team裏團隊成員對各個框架的了解程度而定。很多時候，即使沒有使用框架，壹樣能 寫出好的程序來，比如Flickr據說就是用Pear+Smarty這樣的類庫寫出來的，所以，是否用框架，用什麽框架，壹般不是最重要的，重要的是我們 的編程思想裏要有框架的意識。
邏輯的分層
網站規模到了壹定的程度之後，代碼裏各種邏輯糾纏在壹起，會給維護和擴展帶來巨大的障礙，這時我們的解決方式其實很簡單，那就是重構，將邏輯進行分層。通常，自上而下可以分為表現層，應用層，領域層，持久層。
表現層
所謂表現層，並不僅僅就指模板，它的範圍要更廣壹些，所有和表現相關的邏輯都應該被納入表現層的範疇。比如說某處的字體要顯示為紅色，某處的開頭要 空兩格，這些都屬於表現層。很多時候，我們容易犯的錯誤就是把本屬於表現層的邏輯放到了其他層面去完成，這裏說壹個很常見的例子：我們在列表頁顯示文章標 題的時候，都會設定壹個最大字數，壹旦標題長度超過了這個限制，就截斷，並在後面顯示“..”，這就是最典型的表現層邏輯，但是實際情況，有很多程序員都 是在非表現層代碼裏完成數據的獲取和截斷，然後賦值給表現層模板，這樣的代碼最直接的缺點就是同樣壹段數據，在這個頁面我可能想顯示前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）的方式。
編輯本段網站架構之負載均衡必須要考慮的八個方案
HTML靜態化
其實大家都知道，效率最高、消耗最小的就是純靜態化的html頁面，所以我們盡可能使我們的網站架構上的頁面采用靜態頁面來實現，這個最簡單的方法其實也是最有效的方法。但是對於大量內容並且頻繁更新的網站，我們無法全部手動去挨個實現，於是出現了我們常見的信息發布系統CMS，像我們常訪問的各個門戶站點的新聞頻道，甚至他們的其他頻道，都是通過信息發布系統來管理和實現的，信息發布系統可以實現最簡單的信息錄入自動生成靜態頁面，還能具備頻道管理、權限管理、自動抓取等功能，對於壹個大型網站來說，擁有壹套高效、可管理的CMS是必不可少的。 除了門戶和信息發布類型的網站，對於交互性要求很高的社區類型網站來說，盡可能的靜態化也是提高性能的必要手段，將社區內的帖子、文章進行實時的靜態化，有更新的時候再重新靜態化也是大量使用的策略，像Mop的大雜燴就是使用了這樣的策略，網易社區等也是如此。 同時，html靜態化也是某些緩存策略使用的手段，對於系統中頻繁使用數據庫查詢但是內容更新很小的應用，可以考慮使用html靜態化來實現，比如論壇中論壇的公用設置信息，這些信息目前的主流論壇都可以進行後臺管理並且存儲再數據庫中，這些信息其實大量被前臺程序調用，但是更新頻率很小，可以考慮將這部分內容進行後臺更新的時候進行靜態化，這樣避免了大量的數據庫訪問請求。
圖片服務器分離
大家知道，對於Web服務器來說，不管是Apache、IIS還是其他容器，圖片是最消耗資源的，於是我們有必要將圖片與頁面進行分離，這是基本上大型網站都會采用的策略，他們都有獨立的圖片服務器，甚至很多臺圖片服務器。這樣的架構可以降低提供頁面訪問請求的服務器系統壓力，並且可以保證系統不會因為圖片問題而崩潰，在應用服務器和圖片服務器上，可以進行不同的配置優化，比如apache在配置ContentType的時候可以盡量少支持，盡可能少的LoadModule，保證更高的系統消耗和執行效率。
數據庫集群和庫表散列
大型網站都有復雜的應用，這些應用必須使用數據庫，那麽在面對大量訪問的時候，數據庫的瓶頸很快就能顯現出來，這時壹臺數據庫將很快無法滿足應用，於是我們需要使用數據庫集群或者庫表散列。 在數據庫集群方面，很多數據庫都有自己的解決方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是類似的方案，您使用了什麽樣的DB，就參考相應的解決方案來實施即可。 上面提到的數據庫集群由於在架構、成本、擴張性方面都會受到所采用DB類型的限制，於是我們需要從應用程序的角度來考慮改善系統架構，庫表散列是常用並且最有效的解決方案。我們在應用程序中安裝業務和應用或者功能模塊將數據庫進行分離，不同的模塊對應不同的數據庫或者表，再按照壹定的策略對某個頁面或者功能進行更小的數據庫散列，比如用戶表，按照用戶ID進行表散列，這樣就能夠低成本的提升系統的性能並且有很好的擴展性。sohu的論壇就是采用了這樣的架構，將論壇的用戶、設置、帖子等信息進行數據庫分離，然後對帖子、用戶按照板塊和ID進行散列數據庫和表，最終可以在配置文件中進行簡單的配置便能讓系統隨時增加壹臺低成本的數據庫進來補充系統性能。
緩存
緩存壹詞搞技術的都接觸過，很多地方用到緩存。網站架構和網站開發中的緩存也是非常重要。這裏先講述最基本的兩種緩存。高級和分布式的緩存在後面講述。 架構方面的緩存，對Apache比較熟悉的人都能知道Apache提供了自己的緩存模塊，也可以使用外加的Squid模塊進行緩存，這兩種方式均可以有效的提高Apache的訪問響應能力。 網站程序開發方面的緩存，Linux上提供的MemoryCache是常用的緩存接口，可以在web開發中使用，比如用Java開發的時候就可以調用MemoryCache對壹些數據進行緩存和通訊***享，壹些大型社區使用了這樣的架構。另外，在使用web語言開發的時候，各種語言基本都有自己的緩存模塊和方法，PHP有Pear的Cache模塊，Java就更多了，.net不是很熟悉，相信也肯定有。
鏡像
鏡像是大型網站常采用的提高性能和數據安全性的方式，鏡像的技術可以解決不同網絡接入商和地域帶來的用戶訪問速度差異，比如ChinaNet和EduNet之間的差異就促使了很多網站在教育網內搭建鏡像站點，數據進行定時更新或者實時更新。在鏡像的細節技術方面，這裏不闡述太深，有很多專業的現成的解決架構和產品可選。也有廉價的通過軟件實現的思路，比如Linux上的rsync等工具。
負載均衡
負載均衡將是大型網站解決高負荷訪問和大量並發請求采用的終極解決辦法。 負載均衡技術發展了多年，有很多專業的服務提供商和產品可以選擇，我個人接觸過壹些解決方法，其中有兩個架構可以給大家做參考。
硬件四層交換
第四層交換使用第三層和第四層信息包的報頭信息，根據應用區間識別業務流，將整個區間段的業務流分配到合適的應用服務器進行處理。 第四層交換功能就象是虛IP，指向物理服務器。它傳輸的業務服從的協議多種多樣，有HTTP、FTP、NFS、Telnet或其他協議。這些業務在物理服務器基礎上，需要復雜的載量平衡算法。在IP世界，業務類型由終端TCP或UDP端口地址來決定，在第四層交換中的應用區間則由源端和終端IP地址、TCP和UDP端口***同決定。 在硬件四層交換產品領域，有壹些知名的產品可以選擇，比如Alteon、F5等，這些產品很昂貴，但是物有所值，能夠提供非常優秀的性能和很靈活的管理能力。Yahoo中國當初接近2000臺服務器使用了三四臺Alteon就搞定了。
軟件四層交換
大家知道了硬件四層交換機的原理後，基於OSI模型來實現的軟件四層交換也就應運而生，這樣的解決方案實現的原理壹致，不過性能稍差。但是滿足壹定量的壓力還是遊刃有余的，有人說軟件實現方式其實更靈活，處理能力完全看妳配置的熟悉能力。 軟件四層交換我們可以使用Linux上常用的LVS來解決，LVS就是Linux VirtualServer，他提供了基於心跳線heartbeat的實時災難應對解決方案，提高系統的魯棒性，同時可供了靈活的虛擬VIP配置和管理功能，可以同時滿足多種應用需求，這對於分布式的系統來說必不可少。 壹個典型的使用負載均衡的策略就是，在軟件或者硬件四層交換的基礎上搭建squid集群，這種思路在很多大型網站包括搜索引擎上被采用，這樣的架構低成本、高性能還有很強的擴張性，隨時往架構裏面增減節點都非常容易。這樣的架構我準備空了專門詳細整理壹下和大家探討。 對於大型網站來說，前面提到的每個方法可能都會被同時使用到，我這裏介紹得比較淺顯，具體實現過程中很多細節還需要大家慢慢熟悉和體會，有時壹個很小的squid參數或者apache參數設置，對於系統性能的影響就會很大，希望大家壹起討論，達到拋磚引玉之效。