|
|
1、Web Server 與 DB Server 分離
小型網(wǎng)站或 B/S 項目，因同時在線人數(shù)不多，尚可讓同一臺物理主機，既做 Web Server，又做 DB Server。但此二者皆會占用大量的 CPU、內(nèi)存、磁盤 I/O，最好讓二者分別用不同的服務(wù)器主機來提供服務(wù)，以分散壓力、提高負載承受能力。此外，二者若在同一網(wǎng)段，應(yīng)盡量用內(nèi)網(wǎng) Private IP 進行訪問，而不要用 Public IP 或主機名稱。
基本上跑 Web 上的應(yīng)用程序，不管用什么軟、硬件，同時處理多個用戶的 request，通常都比較消耗 CPU；但對數(shù)據(jù)庫而言，CPU 就不見得會大量消耗，而是內(nèi)存和磁盤 I/O 用得比 Web Server 多。因此一般建議 Web Server 用普通的 PC 即可，但要用好一點的 CPU；而 DB Server 就不能草率，應(yīng)盡量買高級的服務(wù)器，并要有 RAID 5 或 6 的磁盤陣列 (硬件的 RAID，性能遠比操作系統(tǒng)或軟件做的 RAID 要好)，并有 4 GB 以上的內(nèi)存。當然如果操作系統(tǒng)、數(shù)據(jù)庫都用 64 位版本的最好，例如升級到 64 位的 SQL Server 和 64 位的 Windows Server，這樣內(nèi)存都可配置到 64 GB；不過要記得，太舊的 PC，一些周邊硬件的 driver 可能不支持 64 位的操作系統(tǒng)和軟件。
如果在線人數(shù)持續(xù)增加，則可增加多臺 Web Server 和 DB Server，用「服務(wù)器集群 (cluster)」、「負載均衡 (Load balancing) 集群」、「高可用性集群 High-availability (HA)」、數(shù)據(jù)庫集群，以實現(xiàn)更大規(guī)模的分布式布署。
Deployment Plan（部署規(guī)劃）：
http://msdn.microsoft.com/zh-cn/library/ms978676.ASPx
Three-Tiered Distribution（三級分布）(硬件、不同主機的物理級分層)：
http://msdn.microsoft.com/zh-cn/library/ms978694.ASPx
Three-Layered Services Application（三層服務(wù)應(yīng)用程序）(軟件、代碼上的分層)：
http://msdn.microsoft.com/zh-cn/library/ms978689.ASPx
Tiered Distribution（分級分布）：
http://msdn.microsoft.com/en-gb/library/ms978701(zh-cn).ASPx
Deployment Patterns：
http://msdn.microsoft.com/zh-cn/library/ms998478.ASPx
http://msdn.microsoft.com/en-us/library/ms998478.ASPx
-----------------------------------------------------
2、負載均衡 (Load Balance)
負載均衡技術(shù)發(fā)展了多年，有很多專業(yè)的服務(wù)提供商和產(chǎn)品可選擇，基本上又可分為「軟件」和「硬件」的解決方案：
(1) 硬件：
硬件的解決方案稱作 Layer 4 Switch (第 4 層交換)，可將業(yè)務(wù)流分配到合適的 AP Server 進行處理，知名產(chǎn)品如 Alteon、F5 等。這些硬件產(chǎn)品雖比軟件的解決方案要貴得多，但是物有所值，通常能提供遠比軟件優(yōu)秀的性能，和方便、易于管理的 UI 界面，供管理人員快速配置。據(jù)說 Yahoo 中國當初接近 2000 臺服務(wù)器時，只用三臺 Alteon 就搞定了 [1]。
(2) 軟件：
Apache 這一款眾所皆知的 HTTP Server，其雙向 Proxy / Reverse Proxy 功能，亦可達成 HTTP 負載均衡功能，但其效率算不上特別好。而另一款 HAProxy 就是純粹用來處理負載均衡的，且具有簡單的緩存功能。
以操作系統(tǒng)內(nèi)置的負載均衡功能來講，Unix 如 Sun 的 Solaris 有支持，Linux 上則有常用的 LVS (Linux Virtual Server)，而微軟的 Windows Server 2003 / 2008 則有 NLB (NETwork LoadBalance)。
LVS 是利用 ipvsadm 這一個以 IP 為主的負載均衡程序，來達到讓所有 TCP/IP 的通訊協(xié)議都可以進行負載均衡。由于它是 Linux Kernel 所支持，因此效率相當好，占用的 CPU 資源相當?shù)停秉c是 ipvsadm 無法針對 Layer 4 以上的網(wǎng)絡(luò) packet 數(shù)據(jù)進行分析。
至于 Windows Server 的 NLB，其原理是不論有多少臺服務(wù)器，都全部共用一個「集群的 IP」，如下圖 1 的 Active Load balancer，和下圖 2 的 Virtual Server 1 (Web Server)，以及 Virtual DB Server，依照負載均衡的類型來做分配 (Active/Active、Active/Standby、...)，而用戶在外面只會看到單一個 IP，至于背后有多少臺服務(wù)器，用戶并不需要知道 (如同 Cluster 集群和云計算的概念)。
圖 1 分布式用戶 vs 服務(wù)器農(nóng)場 (Web Server farm)
圖 2 紅色箭頭為 Failover 架構(gòu) (HA)，其功能與 Load Balance 不同
上圖 2 中，有四臺 Real Server (Web Server)，以及三臺 Real DB Server，形成 Web 及 DB 的服務(wù)器集群 (Cluster)。我們看到最上方的 Virtual Server 1 本身不具備任何的數(shù)據(jù)服務(wù) (如：.NET 代碼、圖片...等)，只有一個功能，就是將用戶的連線 request 請求，重新導(dǎo)向下方的四臺 Real Server。這種利用重新導(dǎo)向 (director) 的方式，將服務(wù)負載分布給 Real Server 的方式，就稱作 Load Balance。
現(xiàn)在似乎還沒有一種做法，能自動計算主機的「負載」情形，例如計算 CPU 已使用多少百分比，以決定要把 request 丟向哪一臺 Real Server；現(xiàn)在一般都還是按照輪替 (Round-robin) 的方式，或加上一些權(quán)重的設(shè)置而已。
若我們在 Server 上設(shè)置 Load Balance，且要執(zhí)行 ASP.NET 程序，就要注意一個問題，就是 Session 的存儲位置是在哪一臺 Web Server 的內(nèi)存上，以避免發(fā)生有用戶表單填寫得比較久，等到他提交時，已經(jīng)被 Windows Server 的 NLB 將工作階段切換到另一臺 Web Server 主機上了。此時就可考慮將 Session State，改存儲在 SQL Server 里。
至于用軟件做的 Load Balance 其性能如何呢？基本上用軟件做的，性能一定不會是 1 + 1 = 2，但通常能提高 Availability，亦即常聽到的 HA (高可用性集群 High-availability)，即 Failover 方式，如上圖 2 的最上方，紅色箭頭左側(cè)的 Virtual Server 2，是能夠偵測 Virtual Server 1 宕機或無法提供服務(wù)時，自動將自己的 IP address 取代 Virtual Server1。因此 HA 是指提供「不會中斷的服務(wù)」，而本帖討論的 Load Balance 是指提供「能承受高度負載的服務(wù)」，兩者指的不是同一件事。MIS 人員應(yīng)視公司的硬件資源、成本和預(yù)算，考量是否兩者都要做。
Load-Balanced Cluster（負載平衡群集）：
http://msdn.microsoft.com/zh-cn/library/ms978730.ASPx
http://msdn.microsoft.com/en-us/library/ms978730.ASPx
Server Clustering（服務(wù)器群集）：
http://msdn.microsoft.com/en-gb/library/ms998414(zh-cn).ASPx
Installing NETwork Load Balancing (NLB) on Windows Server 2008：
http://blogs.msdn.com/clustering/archive/2008/01/08/7024154.ASPx
Linux load balancing support & consulting：
http://www.NETdigix.com/linux-loadbalancing.php
Load Balancing (WCF, 與本文無直接關(guān)系)：
http://msdn.microsoft.com/zh-cn/library/ms730128.ASPx
http://msdn.microsoft.com/en-us/library/ms730128.ASPx
-----------------------------------------------------
3、展示和功能的分層
大型網(wǎng)站中，常會為了將來的可擴展性、源代碼維護方便，而將前臺的展示 (HTML、Script)，和后臺的商業(yè)邏輯、數(shù)據(jù)庫訪問 (.NET/C#、SQL)，切成多層。
根據(jù) Martin Fowler 在 P of EAA 里的說法：Layer 是指「邏輯」上的分層 (logical separation)，Tier 是指「物理」上的分層 (physical separation)。若我們的 ASP.NET 站臺，是用「虛擬」的分層 (N-Layer)，來切開 UI - BLL - DAL，通常不會有性能上的問題；但若是用「物理」的分層 (N-Tier)，亦即如上圖 2 和下圖 3，可能每一臺 AP Server 都負責(zé)不同的商業(yè)邏輯 (銷售、庫存、物流、制造、會計、...)，各自的源代碼都存放在不同的物理主機上，且可各自獨立運作，此時就要考慮到每一臺 AP Server 在彼此協(xié)調(diào)合作，以及調(diào)用 Web Service (XML 的性能不佳)、執(zhí)行分布式事務(wù)上的性能問題。
圖 3 「物理」上的分層，各種商業(yè)邏輯可能存在多臺物理主機上
談到「物理」分層上的分布式事務(wù) (Distributed Transaction)，微軟的 Enterprise Services、COM+、WCF、WF 用到操作系統(tǒng)上的 MS DTC 來協(xié)調(diào)事務(wù)，由于 MS DTC 和這些應(yīng)用程序各自處于不同的 Process，在溝通上會遇到序列化、反序列化的動作，還要整合事務(wù)中所有的 AppDomain 和不同主機上的資源，無可避免地一定會拖累性能。
Web Applications: N-Tier vs. N-Layer ：
http://codebetter.com/blogs/david.hayden/archive/2005/07/23/129745.ASPx
-----------------------------------------------------
4、數(shù)據(jù)大表拆分
對比較大的數(shù)據(jù)表，或歷史數(shù)據(jù)比較多的數(shù)據(jù)表，可根據(jù)一定的邏輯進行拆分。若每天的數(shù)據(jù)量非常大，則可采用按日存放，再用一個「匯總表」來記錄當天的一個匯總值；也可先將比較大的表拆分成多個表，再通過「索引表」進行關(guān)聯(lián)處理，以避免查詢大表造成的性能問題 [1]。
另也可用「表分區(qū)」的方式，將數(shù)據(jù)存儲在不同的文件上，然后再部署到獨立的物理服務(wù)器，以增加 I/O 吞吐，改善讀寫的性能。
此外，在本文的系列作「30 分鐘快快樂樂學(xué) SQL Performance Tuning」曾提過，若一個數(shù)據(jù)表的字段過多 (與剛才提的記錄量過多不同)，應(yīng)垂直切割成兩個以上的數(shù)據(jù)表，并可用同名的 Primary Key 一對多連結(jié)起來，如：Northwind 的 Orders、Order Details 數(shù)據(jù)表。以避免在訪問數(shù)據(jù)時，以「集簇引 (clustered index)」掃描時會加載過多的數(shù)據(jù)，或修改數(shù)據(jù)時造成互相鎖定或鎖定過久。
-----------------------------------------------------
5、圖片服務(wù)器分離
對于 Web Server 來說，用戶對圖片的請求是最消耗系統(tǒng)資源的，因此可視網(wǎng)站的規(guī)模和項目的特性，部署獨立的圖片服務(wù)器，甚至多臺圖片服務(wù)器。
-----------------------------------------------------
6、讀寫分離
同時對數(shù)據(jù)庫進行「讀」和「寫」的操作，是非常沒效率的一種訪問方式。比較好的做法，是根據(jù)讀、寫的壓力和需求，分別建立兩臺結(jié)構(gòu)完全相同的數(shù)據(jù)庫服務(wù)器，將負責(zé)「寫」的那臺服務(wù)器的數(shù)據(jù)，定時復(fù)制給負責(zé)「讀」的服務(wù)器。
-----------------------------------------------------
7、擴容性應(yīng)對突增流量
大型網(wǎng)站在設(shè)計架構(gòu)的時候，必須考慮到以后的容量擴充 [1]。對于活動類的網(wǎng)站來說，不定時的突增流量是巨大的。在網(wǎng)站主存儲服務(wù)器上，采用配置文件形式，指定每一個存儲盤柜上存儲的數(shù)據(jù)文件的 ID 范圍。當前臺服務(wù)器需要讀取一個數(shù)據(jù)的時候，首先通過詢問主存儲服務(wù)器上的接口，獲得該數(shù)據(jù)所在的盤柜及目錄地址，然后再去該盤柜讀取實際的數(shù)據(jù)文件。如果需要增加盤柜，則只要修改配置文件即可，前臺程序完全不受影響。
-----------------------------------------------------
8、緩存
緩存 (Cache) 是數(shù)據(jù)庫或?qū)ο笤趦?nèi)存中的臨時容器，使用緩存可大幅減少數(shù)據(jù)庫的讀取，改由內(nèi)存來提供數(shù)據(jù)。例如我們可以在 Web Server、DB Server 之間增加一層「數(shù)據(jù)緩存層」，在內(nèi)存中建立被頻繁請求對象的副本，如此一來，不訪問數(shù)據(jù)庫也可供給數(shù)據(jù)。例如，有 100 個用戶請求同一份資料，以前需要查詢數(shù)據(jù)庫 100 次，現(xiàn)在則只需要 1 次，其余都可從緩存數(shù)據(jù)中獲得，而且讀取速度、網(wǎng)頁反應(yīng)速度會大幅提升。
提供緩存的產(chǎn)品有很多種，還可分為用硬件或軟件所做的緩存，如：ASP.NET 內(nèi)置的緩存功能、第三方廠商的緩存套件、Hibernate 和 NHibernate 里也有 Session 和 SessionFactory 的緩存機制、Oracle 的 cache group 技術(shù)，還有我先前在「用 IIS 7、ARR 與 Velocity 建設(shè)高性能的大型網(wǎng)站」這篇文章介紹的，微軟官方新一代的分布式緩存技術(shù) Velocity，另外像 Proxy Server (代理服務(wù)器) 也可以作為網(wǎng)頁的緩存：
客戶端 <----> 代理服務(wù)器 <----> 目的服務(wù)器
在 .NET 的類庫中，有提供 CacheDependency 和 AggregateCacheDependency 這兩個類，可用來將 ASP.NET 中緩存的對象 (如：DataSet)，和一或多個物理文件 (如：XML 文件) 或數(shù)據(jù)庫中的表，去建立一種關(guān)聯(lián)。當其中任一個 XML 文件被修改或移除時，與其關(guān)聯(lián)的 DataSet 也會一并從內(nèi)存里移除；當然，也可透過您程序中設(shè)定的時間自動移除。
ASP.NET 2.0 以后的緩存，最大的改變在于 CacheDependency 類已經(jīng)被微軟重新改寫過，我們也可透過自定義類去繼承它后再改寫，以達成以下功能：
• 從 Active Directory 中的請求，讓緩存失效 (緩存被自動移除)
• 從 MSMQ 或 MQSeries 中的請求，讓緩存失效
• 從 Web Service 中的請求，讓緩存失效
• 創(chuàng)建用于 Oracle 的 CacheDependency
• 其他
此外，SQL Server 中還有一種 SqlCacheDependency (緩存相依性)，可監(jiān)聽數(shù)據(jù)表中的數(shù)據(jù)是否曾經(jīng)改變，亦即避免用戶在緩存期間查到的數(shù)據(jù)是舊的，達到如果數(shù)據(jù)不變化，用戶就一直從緩存中取得數(shù)據(jù)；一旦數(shù)據(jù)有變化，就自動更新緩存中的數(shù)據(jù)。啟用 SqlCacheDependency 的方式，只要透過 ASPNET_regsql.exe 這個工具，搭配參數(shù)輸入命令，就會在 SQL Server 中產(chǎn)生一個新的 ASPNET_SqlCacheTablesForChangeNotification 表，如下圖 4 所示，這張表的的每一條記錄，都代表您要監(jiān)聽的其中一個表；最右側(cè)的 changeId 字段，其值為供系統(tǒng)判斷，用戶對 ASP.NET 中的請求，應(yīng)由內(nèi)存中的緩存來提供，抑或要至數(shù)據(jù)庫重新做查詢。
圖 4 啟用 SqlCacheDependency 后，自動添加用來監(jiān)聽的表
另外再談到，我在「網(wǎng)站性能越來越差怎么辦？」這篇文章，也有提過下面的內(nèi)容：
(4) 用程序或軟件做緩存
用程序做緩存，如 ASP.NET 從 1.x 時代，就已內(nèi)建的 Cache (緩存) 機制；或用一些第三方的輔助軟件、Framework。
(5) 用硬件做快取或緩沖、砸錢加裝 AP Server
他還在原本的網(wǎng)頁服務(wù)器，與數(shù)據(jù)庫服務(wù)器的架構(gòu)中，加入一組應(yīng)用程序服務(wù)器，作為網(wǎng)頁服務(wù)器 cache 數(shù)據(jù)的來源。
改版之后的新網(wǎng)站，搜尋速度提升許多，先前每日的統(tǒng)計數(shù)據(jù)中，處理速度超過 3 秒的數(shù)據(jù)超過 50 萬筆；而改版后，每星期超過 3 秒的查詢不到 10 筆。
(6) 用硬件做緩存 (cache)
全盛時期，來自美國 blog 的流量每天達 80 萬次。這個數(shù)字其實不高，對程序高手來說是小菜一碟，但筆者是半吊子工程師，知識有限也因此可能程序?qū)懙貌缓茫l頻被主機供貨商發(fā)信警告，要求改善網(wǎng)站系統(tǒng)性能。最后，我決定開發(fā) cache system。cache system 緩存系統(tǒng)上線后，將數(shù)據(jù)庫讀寫，從每天 80 萬次降低到每天 16 萬次。
回復(fù)：
Peter.z.lu
中間件可以有很多選擇：
Ncache, Coherence, Velocity, MemCache...
另外，還有像是 Memcached、Cacheman 這種分布式緩存的系統(tǒng)。前者可基于 Linux 和 Win32 平臺使用，通過在內(nèi)存里維護一個巨大的 hash 表，可存儲圖像、視頻、文件及數(shù)據(jù)庫檢索的結(jié)果，并且支持多服務(wù)器，可解決 ASP.NET 內(nèi)置的緩存機制僅適用于單獨的服務(wù)器；后者據(jù)說是微軟旗下 Popfly 項目組成員 Sriram Krishnan 的作品，將來也有可能成為微軟的正式產(chǎn)品。
-----------------------------------------------------
9、分布式系統(tǒng)數(shù)據(jù)結(jié)構(gòu) - 以 MySpace 為例
在網(wǎng)絡(luò)上流傳一篇很火紅的文章「從 MySpace 數(shù)據(jù)庫看分布式系統(tǒng)數(shù)據(jù)結(jié)構(gòu)變遷」，內(nèi)容提到 MySpace 這個大型的社區(qū)網(wǎng)站，使用微軟平臺的 Windows Server、SQL Server、ASP.NET 技術(shù)，如今每個月的用戶訪問量高達 500 億，且已有 2 億個以上的用戶注冊。以下僅節(jié)錄該文的重點：
- 第一代架構(gòu) - 添置更多的 Web 服務(wù)器
在 MySpace 有 50 萬個注冊用戶的時候，網(wǎng)站只用了兩臺 Dell 雙 CPU、4 GB 內(nèi)存的 Web Server (分散用戶的請求)、一臺 DB Server (所有數(shù)據(jù)都存儲在這)。 - 第二代架構(gòu) - 增加數(shù)據(jù)庫服務(wù)器
運行在三臺數(shù)據(jù)庫服務(wù)器上，一臺用于更新數(shù)據(jù) (由它復(fù)制到其他兩個)、另兩臺用于讀取數(shù)據(jù)，因為看網(wǎng)頁的人多，而需要寫入的人少。等到用戶數(shù)和訪問量增加了，就再加裝硬盤。
后來數(shù)據(jù)庫服務(wù)器的 I/O 成了瓶頸，就按照垂直分割模式設(shè)計，把網(wǎng)站里的不同功能，如：登錄、用戶資料和博客，搬移到不同的數(shù)據(jù)庫服務(wù)器中，以分擔(dān)訪問壓力；若要增加新功能，就再投入新的數(shù)據(jù)庫服務(wù)器。
當注冊用戶達到 200 萬后，還從存儲設(shè)備與數(shù)據(jù)庫服務(wù)器直接交互的方式，切換到 SAN (存儲區(qū)域網(wǎng)絡(luò))，一種高帶寬、專門設(shè)計的網(wǎng)絡(luò)系統(tǒng)，可將大量磁盤存儲設(shè)備連接在一起。MySpace 讓數(shù)據(jù)庫連接到 SAN。但是當用戶增加到 300 萬人后，垂直分割策略也變得難以維持下去，后來架構(gòu)師后來將主機升級成 34 個 CPU 的昂貴服務(wù)器，卻也無法負荷。 - 第三代架構(gòu) - 轉(zhuǎn)到分布式計算架構(gòu)
架構(gòu)師將 MySpace 移到分布式計算架構(gòu)，它在物理上分布的眾多服務(wù)器，整體必須邏輯上等同于單臺機器。拿數(shù)據(jù)庫來說，就不能再像過去那樣將應(yīng)用拆分，再以不同數(shù)據(jù)庫分別支持，而必須將整個站點看作一個應(yīng)用。這次，不再按站點功能和應(yīng)用分割數(shù)據(jù)庫，MySpace 開始將它的用戶按每 100 萬一組分割，然后將各組的全部數(shù)據(jù)分別存入獨立的 SQL Server 實例。后來 MySpace 的每臺數(shù)據(jù)庫服務(wù)器實際運行兩個 SQL Server 實例，也就是說每臺服務(wù)器會服務(wù)大約 200 萬用戶。 - 第四代架構(gòu) - 增加數(shù)據(jù)緩存層
當用戶達到 900-1000 萬時，MySpace再次遭遇存儲瓶頸問題，后來引用了新的 SAN 產(chǎn)品，但站點目前的要求，已經(jīng)超越 SAN 的 I/O 磁盤存儲系統(tǒng)、及其讀寫數(shù)據(jù)的極限速度。
當用戶達到 1700 萬時，增加了一個數(shù)據(jù)緩存層，其位于 Web 服務(wù)器和數(shù)據(jù)庫服務(wù)器之間，其唯一職能是在內(nèi)存中建立被頻繁請求數(shù)據(jù)對象的副本。以前每一位用戶查詢一個信息，就請求一次數(shù)據(jù)庫；現(xiàn)在當任一個用戶請求數(shù)據(jù)庫后，緩存層就會保留一個副本，當其他用戶再訪問時就不需要再請求數(shù)據(jù)庫了，如此一來，不訪問數(shù)據(jù)庫也可以供給數(shù)據(jù)。 - 第五代架構(gòu) - 轉(zhuǎn)到支持 64 位處理器的操作系統(tǒng)和數(shù)據(jù)庫軟件
當用戶數(shù)達到 2600 萬時，轉(zhuǎn)到了還處于 Beta 版、但支持 64 位處理器的 SQL Server 2005。在升級到 64 位的 SQL Server 2005 和 Windows Server 2003 后，MySpace 每臺服務(wù)器配備了 32 GB 內(nèi)存，后來又提升到了 64 GB。
從 MySpace 數(shù)據(jù)庫看分布式系統(tǒng)數(shù)據(jù)結(jié)構(gòu)變遷：
http://www.cnblogs.com/cxccbv/archive/2009/07/15/1524387.html
http://www.Javaeye.com/topic/152766
http://smb.pconline.com.cn/database/0808/1403100.html
http://idai.blogbus.com/logs/14736411.html
-----------------------------------------------------
NET技術(shù)：網(wǎng)站性能優(yōu)化 - 數(shù)據(jù)庫及服務(wù)器架構(gòu)篇，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
