企業大型網站建設的系統架構及注意事項
企業大型網站建設的系統架構；
1、HTML靜態化
除了門戶和信息發布類型的網站，對于交互性要求很高的社區類型網站來說，盡可能的靜態化也是提高性能的必要手段，將社區內的帖子、文章進行實時的靜態化，有更新的時候再重新靜態化也是大量使用的策略，像Mop的大雜燴就是使用了這樣的策略，網易社區等也是如此。
同時，html靜態化也是某些緩存策略使用的手段，對于系統中頻繁使用數據庫查詢但是內容更新很小的應用，可以考慮使用html靜態化來實現，比如論壇中論壇的公用設置信息，這些信息目前的主流論壇都可以進行后臺管理并且存儲再數據庫中，這些信息其實大量被前臺程序調用，但是更新頻率很小，可以考慮將這部分內容進行后臺更新的時候進行靜態化，這樣避免了大量的數據庫訪問請求。
2、圖片服務器分離
大家知道，對于Web服務器來說，不管是Apache、IIS還是其他容器，圖片是最消耗資源的，于是我們有必要將圖片與頁面進行分離，這是基本上大型網站都會采用的策略，他們都有獨立的圖片服務器，甚至很多臺圖片服務器。這樣的架構可以降低提供頁面訪問請求的服務器系統壓力，并且可以保證系統不會因為圖片問題而崩潰，在應用服務器和圖片服務器上，可以進行不同的配置優化，比如apache在配置ContentType的時候可以盡量少支持，盡可能少的 LoadModule，保證更高的系統消耗和執行效率。
3、數據庫集群和庫表散列
大型網站都有復雜的應用，這些應用必須使用數據庫，那么在面對大量訪問的時候，數據庫的瓶頸很快就能顯現出來，這時一臺數據庫將很快無法滿足應用，于是我們需要使用數據庫集群或者庫表散列。
在數據庫集群方面，很多數據庫都有自己的解決方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是類似的方案，您使用了什么樣的DB，就參考相應的解決方案來實施即可。
上面提到的數據庫集群由于在架構、成本、擴張性方面都會受到所采用DB類型的限制，于是我們需要從應用程序的角度來考慮改善系統架構，庫表散列是常用并且最有效的解決方案。我們在應用程序中安裝業務和應用或者功能模塊將數據庫進行分離，不同的模塊對應不同的數據庫或者表，再按照一定的策略對某個頁面或者功能進行更小的數據庫散列，比如用戶表，按照用戶ID進行表散列，這樣就能夠低成本的提升系統的性能并且有很好的擴展性。sohu的論壇就是采用了這樣的架構，將論壇的用戶、設置、帖子等信息進行數據庫分離，然后對帖子、用戶按照板塊和ID進行散列數據庫和表，最終可以在配置文件中進行簡單的配置便能讓系統隨時增加一臺低成本的數據庫進來補充系統性能。
4、緩存
緩存一詞搞技術的都接觸過，很多地方用到緩存。網站架構和網站開發中的緩存也是非常重要。這里先講述最基本的兩種緩存。高級和分布式的緩存在后面講述。
架構方面的緩存，對Apache比較熟悉的人都能知道Apache提供了自己的緩存模塊，也可以使用外加的Squid模塊進行緩存，這兩種方式均可以有效的提高Apache的訪問響應能力。
網站程序開發方面的緩存，Linux上提供的Memory Cache是常用的緩存接口，可以在web開發中使用，比如用Java開發的時候就可以調用MemoryCache對一些數據進行緩存和通訊共享，一些大型社區使用了這樣的架構。另外，在使用web語言開發的時候，各種語言基本都有自己的緩存模塊和方法，PHP有Pear的Cache模塊，Java就更多了，.net不是很熟悉，相信也肯定有。
5、鏡像
鏡像是大型網站常采用的提高性能和數據安全性的方式，鏡像的技術可以解決不同網絡接入商和地域帶來的用戶訪問速度差異，比如ChinaNet和 EduNet之間的差異就促使了很多網站在教育網內搭建鏡像站點，數據進行定時更新或者實時更新。在鏡像的細節技術方面，這里不闡述太深，有很多專業的現成的解決架構和產品可選。也有廉價的通過軟件實現的思路，比如Linux上的rsync等工具。
6、負載均衡
負載均衡將是大型網站解決高負荷訪問和大量并發請求采用的終極解決辦法。
負載均衡技術發展了多年，有很多專業的服務提供商和產品可以選擇，我個人接觸過一些解決方法，其中有兩個架構可以給大家做參考。
硬件四層交換
第四層交換使用第三層和第四層信息包的報頭信息，根據應用區間識別業務流，將整個區間段的業務流分配到合適的應用服務器進行處理。 第四層交換功能就象是虛IP，指向物理服務器。它傳輸的業務服從的協議多種多樣，有HTTP、FTP、NFS、Telnet或其他協議。這些業務在物理服務器基礎上，需要復雜的載量平衡算法。在IP世界，業務類型由終端TCP或UDP端口地址來決定，在第四層交換中的應用區間則由源端和終端IP地址、TCP和UDP端口共同決定。
在硬件四層交換產品領域，有一些知名的產品可以選擇，比如Alteon、F5等，這些產品很昂貴，但是物有所值，能夠提供非常優秀的性能和很靈活的管理能力。Yahoo中國當初接近2000臺服務器使用了三四臺Alteon就搞定了。
軟件四層交換
大家知道了硬件四層交換機的原理后，基于OSI模型來實現的軟件四層交換也就應運而生，這樣的解決方案實現的原理一致，不過性能稍差。但是滿足一定量的壓力還是游刃有余的，有人說軟件實現方式其實更靈活，處理能力完全看你配置的熟悉能力。
軟件四層交換我們可以使用Linux上常用的LVS來解決，LVS就是Linux Virtual Server，他提供了基于心跳線heartbeat的實時災難應對解決方案，提高系統的魯棒性，同時可供了靈活的虛擬VIP配置和管理功能，可以同時滿足多種應用需求，這對于分布式的系統來說必不可少。
一個典型的使用負載均衡的策略就是，在軟件或者硬件四層交換的基礎上搭建squid集群，這種思路在很多大型網站包括搜索引擎上被采用，這樣的架構低成本、高性能還有很強的擴張性，隨時往架構里面增減節點都非常容易。這樣的架構我準備空了專門詳細整理一下和大家探討。
對于大型網站來說，前面提到的每個方法可能都會被同時使用到，我這里介紹得比較淺顯，具體實現過程中很多細節還需要大家慢慢熟悉和體會，有時一個很小的squid參數或者apache參數設置，對于系統性能的影響就會很大，希望大家一起討論，達到拋磚引玉之效。
大型網站建設問題；
1、多個服務器集群后session同步問題
可以通過算法計算使同一個ip訪問同一臺服務器
可以復制sessio各個服務器（不推薦開銷大）
session存在第三方中間件如redis中
2、數據庫壓力過大
利用數據庫主從數據復制的特性進行數據庫讀寫分離
添加nosql中間件存放熱點數據
用搜索引擎存放部分要讀的數據
根據業務拆分數據或者分表需要考慮分布式主鍵的問題
3、頁面緩存
將訪問生成的response緩存起來 定時更新 下次訪問直接返回緩存的response
4、拆分應用
大型網站建設需要注意事項；
網站所選擇的網絡提供商：網通電信兩個交叉通信很慢，考慮那些兩個都接入速度很快的，比如網信通（我以前公司的網站和游戲都在上面）
1.網站架構體系（WEB服務器？多少、數據庫服務器多少？、緩存服務器、圖片服務器、備份服務器）
2.數據結構及數據算法（數據庫結構一定要優化，如果表太大，請用分表設置模式，如果能分數據庫參考petshop）
3.緩存（大網站不能沒有緩存：數據庫緩存、數據緩存、頁面緩存、圖片緩存）
4.壓力測試（沒有這個測試的大網站表搞笑了）
5.代碼優化（算法真tmd的很重要）
6.開發架構（架構擴展性一定要考慮，很多時候架構能解決很多問題）
7.測試測試再測試
8.不停的監控在監控性能及運行狀態
具體的來說涉及到：
1. 網站運行技術框架要求
技術范圍 說明
.net2.0
MSSQL2005
JMAIL
IIS6.0
SERV-U
AJAX
HTML
W3C
JAVASCRIPT
2. 網站瀏覽速度要求（10月份速度、頁面大小要求）
網頁的加載速度與網頁內容大小成正比，網頁越大，加載越慢，網頁越小加載越快
1) 網頁加載速度
標準 6秒
慢 > 10秒
非常慢 > 20秒
快 <5秒
非常快 <2秒
2) 網頁大小
標準 350k
大 > 400k
非常大 > 500k
小 <250k
非常小 <150k
3) 首頁加載速度必須小于6秒
4) 訂餐網頁加載速度必須小于8秒
5) 網頁服務器緩存
6) 網頁圖片緩存
7) 減少頁面圖片大小
說明：此要求為10月份網站速度、頁面大小要求。
3. 網站兼容性要求
兼容瀏覽器 說明
IE6 完全兼容
Ie6補丁打全后 完全兼容
IE7 完全兼容
FIREFOX 完全兼容
TT 完全兼容
遨游 流暢訂餐流程
4. 網站安全性要求
1) 無SQL注入點
1. 字符注入
2. 數字注入
3. 其他注入
2) 敏感Cookie必須加密
1. 用戶數字id
2. 訂單信息
3) 過濾cookie欺騙程序
4) 無錯誤明細輸出給客戶，返回我們定義好的錯誤信息給客戶
5) 權限受限嚴格驗證
5. 穩定性要求
1) 程序無明顯錯誤，如：不定期出現某些亂碼問題
2) 并發用戶達到500人/秒正常運行
6. 可靠性要求
1) 保證安全性能
2) 保證穩定性
7. 搜索引擎優化需求
1) 頁面TITLE要求顯示不同頁不同TITLE，并顯示名稱關鍵字
2) 頁面內關鍵字
3) 網站遍歷功能
各大門戶網站都用了CDN. 你們可以考慮自己做.
3臺Linux服務器,1臺Windows服務器. 或者更多. windows服務器放主站點,URL靜態化.
linux1做電信squid服務器. 緩存整個站點的電信訪問.
linux2做網通squid服務器. 緩存網通訪問.
linux3做DNS服務器,做個智能DNS解析.
這樣做,電信用戶訪問站點,則訪問電信緩存服務器. 網通用戶訪問站點,則訪問網通緩存服務器.
當緩存沒有查詢內容的時候,才由緩存服務器去windows服務器取數據,并緩存.
當然你也可以架設鐵通的服務器. 或者搞緩存服務器隊列.
1、HTML靜態化
其實大家都知道，效率最高、消耗最小的就是純靜態化的html頁面，所以我們盡可能使我們的網站上的頁面采用靜態頁面來實現，這個最簡單的方法其實也是最有效的方法。但是對于大量內容并且頻繁更新的網站，我們無法全部手動去挨個實現，于是出現了我們常見的信息發布系統CMS，像我們常訪問的各個門戶站點的新聞頻道，甚至他們的其他頻道，都是通過信息發布系統來管理和實現的，信息發布系統可以實現最簡單的信息錄入自動生成靜態頁面，還能具備頻道管理、權限管理、自動抓取等功能，對于一個大型網站來說，擁有一套高效、可管理的CMS是必不可少的。
除了門戶和信息發布類型的網站，對于交互性要求很高的社區類型網站來說，盡可能的靜態化也是提高性能的必要手段，將社區內的帖子、文章進行實時的靜態化，有更新的時候再重新靜態化也是大量使用的策略，像Mop的大雜燴就是使用了這樣的策略，網易社區等也是如此。
同時，html靜態化也是某些緩存策略使用的手段，對于系統中頻繁使用數據庫查詢但是內容更新很小的應用，可以考慮使用html靜態化來實現，比如論壇中論壇的公用設置信息，這些信息目前的主流論壇都可以進行后臺管理并且存儲再數據庫中，這些信息其實大量被前臺程序調用，但是更新頻率很小，可以考慮將這部分內容進行后臺更新的時候進行靜態化，這樣避免了大量的數據庫訪問請求。
2、圖片服務器分離
大家知道，對于Web服務器來說，不管是Apache、IIS還是其他容器，圖片是最消耗資源的，于是我們有必要將圖片與頁面進行分離，這是基本上大型網站都會采用的策略，他們都有獨立的圖片服務器，甚至很多臺圖片服務器。這樣的架構可以降低提供頁面訪問請求的服務器系統壓力，并且可以保證系統不會因為圖片問題而崩潰，在應用服務器和圖片服務器上，可以進行不同的配置優化，比如apache在配置ContentType的時候可以盡量少支持，盡可能少的 LoadModule，保證更高的系統消耗和執行效率。
3、數據庫集群和庫表散列
大型網站都有復雜的應用，這些應用必須使用數據庫，那么在面對大量訪問的時候，數據庫的瓶頸很快就能顯現出來，這時一臺數據庫將很快無法滿足應用，于是我們需要使用數據庫集群或者庫表散列。
在數據庫集群方面，很多數據庫都有自己的解決方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是類似的方案，您使用了什么樣的DB，就參考相應的解決方案來實施即可。
上面提到的數據庫集群由于在架構、成本、擴張性方面都會受到所采用DB類型的限制，于是我們需要從應用程序的角度來考慮改善系統架構，庫表散列是常用并且最有效的解決方案。我們在應用程序中安裝業務和應用或者功能模塊將數據庫進行分離，不同的模塊對應不同的數據庫或者表，再按照一定的策略對某個頁面或者功能進行更小的數據庫散列，比如用戶表，按照用戶ID進行表散列，這樣就能夠低成本的提升系統的性能并且有很好的擴展性。sohu的論壇就是采用了這樣的架構，將論壇的用戶、設置、帖子等信息進行數據庫分離，然后對帖子、用戶按照板塊和ID進行散列數據庫和表，最終可以在配置文件中進行簡單的配置便能讓系統隨時增加一臺低成本的數據庫進來補充系統性能。
4、緩存
緩存一詞搞技術的都接觸過，很多地方用到緩存。網站架構和網站開發中的緩存也是非常重要。這里先講述最基本的兩種緩存。高級和分布式的緩存在后面講述。
架構方面的緩存，對Apache比較熟悉的人都能知道Apache提供了自己的緩存模塊，也可以使用外加的Squid模塊進行緩存，這兩種方式均可以有效的提高Apache的訪問響應能力。
網站程序開發方面的緩存，Linux上提供的Memory Cache是常用的緩存接口，可以在web開發中使用，比如用Java開發的時候就可以調用MemoryCache對一些數據進行緩存和通訊共享，一些大型社區使用了這樣的架構。另外，在使用web語言開發的時候，各種語言基本都有自己的緩存模塊和方法，PHP有Pear的Cache模塊，Java就更多了，.net不是很熟悉，相信也肯定有。
5、鏡像
鏡像是大型網站常采用的提高性能和數據安全性的方式，鏡像的技術可以解決不同網絡接入商和地域帶來的用戶訪問速度差異，比如ChinaNet和 EduNet之間的差異就促使了很多網站在教育網內搭建鏡像站點，數據進行定時更新或者實時更新。在鏡像的細節技術方面，這里不闡述太深，有很多專業的現成的解決架構和產品可選。也有廉價的通過軟件實現的思路，比如Linux上的rsync等工具。
6、負載均衡
負載均衡將是大型網站解決高負荷訪問和大量并發請求采用的終極解決辦法。
負載均衡技術發展了多年，有很多專業的服務提供商和產品可以選擇，我個人接觸過一些解決方法，其中有兩個架構可以給大家做參考。
硬件四層交換
第四層交換使用第三層和第四層信息包的報頭信息，根據應用區間識別業務流，將整個區間段的業務流分配到合適的應用服務器進行處理。 第四層交換功能就象是虛IP，指向物理服務器。它傳輸的業務服從的協議多種多樣，有HTTP、FTP、NFS、Telnet或其他協議。這些業務在物理服務器基礎上，需要復雜的載量平衡算法。在IP世界，業務類型由終端TCP或UDP端口地址來決定，在第四層交換中的應用區間則由源端和終端IP地址、TCP和UDP端口共同決定。
在硬件四層交換產品領域，有一些知名的產品可以選擇，比如Alteon、F5等，這些產品很昂貴，但是物有所值，能夠提供非常優秀的性能和很靈活的管理能力。Yahoo中國當初接近2000臺服務器使用了三四臺Alteon就搞定了。
軟件四層交換
大家知道了硬件四層交換機的原理后，基于OSI模型來實現的軟件四層交換也就應運而生，這樣的解決方案實現的原理一致，不過性能稍差。但是滿足一定量的壓力還是游刃有余的，有人說軟件實現方式其實更靈活，處理能力完全看你配置的熟悉能力。
軟件四層交換我們可以使用Linux上常用的LVS來解決，LVS就是Linux Virtual Server，他提供了基于心跳線heartbeat的實時災難應對解決方案，提高系統的魯棒性，同時可供了靈活的虛擬VIP配置和管理功能，可以同時滿足多種應用需求，這對于分布式的系統來說必不可少。
一個典型的使用負載均衡的策略就是，在軟件或者硬件四層交換的基礎上搭建squid集群，這種思路在很多大型網站包括搜索引擎上被采用，這樣的架構低成本、高性能還有很強的擴張性，隨時往架構里面增減節點都非常容易。這樣的架構我準備空了專門詳細整理一下和大家探討。
對于大型網站來說，前面提到的每個方法可能都會被同時使用到，我這里介紹得比較淺顯，具體實現過程中很多細節還需要大家慢慢熟悉和體會，有時一個很小的squid參數或者apache參數設置，對于系統性能的影響就會很大，希望大家一起討論，達到拋磚引玉之效。
大型網站建設問題；
1、多個服務器集群后session同步問題
可以通過算法計算使同一個ip訪問同一臺服務器
可以復制sessio各個服務器（不推薦開銷大）
session存在第三方中間件如redis中
2、數據庫壓力過大
利用數據庫主從數據復制的特性進行數據庫讀寫分離
添加nosql中間件存放熱點數據
用搜索引擎存放部分要讀的數據
根據業務拆分數據或者分表需要考慮分布式主鍵的問題
3、頁面緩存
將訪問生成的response緩存起來 定時更新 下次訪問直接返回緩存的response
4、拆分應用
做到服務化，各個服務可能會出現重復代碼，注意分布式事物，需要消息中間件支撐
大型網站建設需要注意事項；
網站所選擇的網絡提供商：網通電信兩個交叉通信很慢，考慮那些兩個都接入速度很快的，比如網信通（我以前公司的網站和游戲都在上面）
1.網站架構體系（WEB服務器？多少、數據庫服務器多少？、緩存服務器、圖片服務器、備份服務器）
2.數據結構及數據算法（數據庫結構一定要優化，如果表太大，請用分表設置模式，如果能分數據庫參考petshop）
3.緩存（大網站不能沒有緩存：數據庫緩存、數據緩存、頁面緩存、圖片緩存）
4.壓力測試（沒有這個測試的大網站表搞笑了）
5.代碼優化（算法真tmd的很重要）
6.開發架構（架構擴展性一定要考慮，很多時候架構能解決很多問題）
7.測試測試再測試
8.不停的監控在監控性能及運行狀態
具體的來說涉及到：
1. 網站運行技術框架要求
技術范圍 說明
.net2.0
MSSQL2005
JMAIL
IIS6.0
SERV-U
AJAX
HTML
W3C
JAVASCRIPT
2. 網站瀏覽速度要求（10月份速度、頁面大小要求）
網頁的加載速度與網頁內容大小成正比，網頁越大，加載越慢，網頁越小加載越快
1) 網頁加載速度
標準 6秒
慢 > 10秒
非常慢 > 20秒
快 <5秒
非常快 <2秒
2) 網頁大小
標準 350k
大 > 400k
非常大 > 500k
小 <250k
非常小 <150k
3) 首頁加載速度必須小于6秒
4) 訂餐網頁加載速度必須小于8秒
5) 網頁服務器緩存
6) 網頁圖片緩存
7) 減少頁面圖片大小
說明：此要求為10月份網站速度、頁面大小要求。
3. 網站兼容性要求
兼容瀏覽器 說明
IE6 完全兼容
Ie6補丁打全后 完全兼容
IE7 完全兼容
FIREFOX 完全兼容
TT 完全兼容
遨游 流暢訂餐流程
4. 網站安全性要求
1) 無SQL注入點
1. 字符注入
2. 數字注入
3. 其他注入
2) 敏感Cookie必須加密
1. 用戶數字id
2. 訂單信息
3) 過濾cookie欺騙程序
4) 無錯誤明細輸出給客戶，返回我們定義好的錯誤信息給客戶
5) 權限受限嚴格驗證
5. 穩定性要求
1) 程序無明顯錯誤，如：不定期出現某些亂碼問題
2) 并發用戶達到500人/秒正常運行
6. 可靠性要求
1) 保證安全性能
2) 保證穩定性
7. 搜索引擎優化需求
1) 頁面TITLE要求顯示不同頁不同TITLE，并顯示名稱關鍵字
2) 頁面內關鍵字
3) 網站遍歷功能
各大門戶網站都用了CDN. 你們可以考慮自己做.
3臺Linux服務器,1臺Windows服務器. 或者更多. windows服務器放主站點,URL靜態化.
linux1做電信squid服務器. 緩存整個站點的電信訪問.
linux2做網通squid服務器. 緩存網通訪問.
linux3做DNS服務器,做個智能DNS解析.
這樣做,電信用戶訪問站點,則訪問電信緩存服務器. 網通用戶訪問站點,則訪問網通緩存服務器.
當緩存沒有查詢內容的時候,才由緩存服務器去windows服務器取數據,并緩存.
當然你也可以架設鐵通的服務器. 或者搞緩存服務器隊列.
- 基于用戶創新
界面設計日新月異，夢創義堅持基于用戶需求的界面創新設計……
- 服務設計思維
互聯網的格局發生的改變，在我們進行設計服務時更是考慮不同用戶、不同……
- 洞察用戶心理
洞察用戶有意識和無意識的行為以及心理特征通過構造一系列的服務來促進……
- 查看更多 >>
最新新聞Latest News
- 中小型企業網站建設完應該如何營銷
- 很多中小型企業往往糾結于以下10個問題：一、我們起步比別人晚，我們的……
- 做企業網站到底做給誰看？
- 設計經常時不時的遇到一些企業客戶，常常搞不清楚誰會真正看你的企業網……
- 傳統企業進軍移動互聯網，從移動云網站開始
- 移動互聯網是移動通信和互聯網融合的產物，其發展的重要基礎便是智能手……
- 網站建設和運營五大細節決定用戶黏性
- 網站的成功離不開搜索引擎優化，更離不開最基礎最根本的用戶群體，如何……
- 2015年值得關注的電子商務5大趨勢
- 線上線下銷售的界線正在變得越來越模糊。在2015年，這一趨勢仍將繼續。……
|
公安部備案號 11010502032413
