集群架構規劃和設計只要是涉及到高並發高流量的項目，基本上都需要。

本文主要圍繞兩個方面，一個是IDC的規劃和選擇，另一個是CDN。

一、IDC的規劃和選擇

IDC的選擇是網站上線前要做的最重要的事情之一。哪怕發展初期只有一臺服務器，選擇一個位置不錯的機房托管，都會助益良多。

也許有人會問IDC是什麽？

我引用百度百科來回答:

IDC為互聯網內容提供商（ICP）、企業、媒體和各類網站提供大規模、高質量、安全可靠的專業化服務器托管、空間租用、網絡批發帶寬以及ASP、EC等業務。IDC是對入駐（Hosting）企業、商戶或網站服務器群托管的場所；是各種模式電子商務賴以安全運作的基礎設施，也是支持企業及其商業聯盟（其分銷商、供應商、客戶等）實施價值鏈管理的平臺。 名詞解釋（業務理解非演講內容） ICP：互聯網信息服務，比如新浪、搜狐、網易。互聯網信息服務可分為經營性信息服務和非經營性信息服務兩類。

IDC翻譯過來的單詞極速互聯網數據中心。

1.網站性質決定基礎面

首先，我們需要對網站的性質和情況又足夠確定的信息。這不單單是說當前的情況，還包括對未來至少一年的預期。因為IDC合同至少要簽一年。

網站性質，第一指網站用戶的分布範圍。區域性的網站必然選擇本區域內的IDC服務，比如各省衛視的網站，甚至更小一些的各市信息港等;全國性質的網站，要考慮到北上廣浙等經濟發達地區才是主力消費人群的集聚地，提高這部分用戶的訪問體驗，就需要盡量把IDC選擇在這些區域內；全球性質的網站，比如外貿性質的，或者選擇國內運營商主力外聯節點位置，或者幹脆選擇海外IDC，像香港、美國、日本、新加坡和英國等。

其次考慮網站具體業務的性質。新聞門戶類的網站，與娛樂遊戲類的網站，在高峰時段、流量類型等方面的要求不一樣。比如新聞門戶，高峰在早9點上班前後;而娛樂遊戲類，高峰在晚9點餐飲結束後,可以一直持續到次日淩晨2點，周末更是流量高峰的高峰;至於電子交易類，13點午餐後也有個高峰時段。

再次還有用戶數量級。IDC需要應對的用戶訪問量是十萬、百萬還是千萬，直接關系到對機櫃和出口帶寬的需求。而這也是考察IDC時很重要的一點。當然這個數據換算本身也涉及業務性質的區別。

2.IDC廠商服務質量

考察IDC廠商的服務質量，有如下幾個參考指標?

(1)IDC出口總帶寬

出口總帶寬和剩余帶寬幾乎可以認為是最關鍵的指標。如果不了解這個問題，當業務飛速發展時會發現想擴展帶寬都擴展不了，簡直是致命的打擊。

(2)連通性和穩定性

確定帶寬可以滿足以後，下一步就是確認網絡質量，即IDC出口到各大節點或者其他IDC網絡的連通性和穩定性。這方面建議自行測試一兩天，如果業務類型對雙休日要求比較嚴格，甚至可以測試一星期來確認其穩定性。

ping測試顯然是最常用的，一般來說，萬分之三以下的丟包率是完全可以接受的。但是不能只以ping測試決定，某些IDC會針對ICMP包進行專門的優先級設置，所以還需要進一步模擬業務流量的HTTP測試等。

(3)電力供應

需要了解電流上限，這涉及到機櫃和主機的比例。另一個重要問題則是IDC的雙路電力是哪雙路，是否真的足以保證供電率。如果都沒有雙路，基本是不用考慮。

(4)空調散熱和機櫃密度
這個問題可能不太引起關註，但是溫度對服務器壽命確實有影響。

(5)走線和環境管理

走線是比較能體現IDC工程師水準的一件事。通常根據這些小細節，可以推測出IDC的綜合實力。類似的還有出入證件檢查是否嚴格，是否提供鞋套、顯示器、鍵盤、推車和板凳等。

(6)其他售後服務

包括是否協助上架、是否可以7x24小時接收重啟服務電話、接電話到完成操作的響應速度、除值班電話以外是否還有應急聯系人等。

3.BGP真偽的驗證

在IDC規劃和采購時，大家可能聽的比較多的一句話就是“雙線BGP接入”，甚至五線七線等。那麽這些宣傳的真偽如何?

其實我們可以通過其IP及AS好歸屬很簡單對比出來。

BGP真偽驗證可以參考這篇博文:https://hqidi.com/73.html

二、CDN規劃

在集群規劃中，有一句話叫“緩存為王”。這個思想，可以從操作系統底層設計開始，層層類推到網站集群的總體規劃。

當然，這其中如CPU二級緩存、RAID卡緩存之類，我們通過對比測試發現其作用，並作出恰當的采購和維護即可。而在網絡數據層面，諸如MySQL的query cache、InnoDB buffer pool,或者memcached、Redis等，多有賴於數據庫管理人員和後端開發人員，運維人員以配合為主，這裏不再贅述。從網頁服務器之外，到用戶瀏覽器這一段，才是運維的主要戰場。這個戰場，又分為兩個部分:第一部分是瀏覽器緩存,前雅虎首席性能官史蒂夫.桑德斯針對網站性能有一句名言，叫做"最快的HTTP請求是沒有產生請求"，就是針對瀏覽器緩存來說的;第二部分是代理服務器緩存，在大規模網絡環境下，這一部分可以擴展成為一個完整的內容分發網絡（Content Delivery Network）。

關於CDN可以參考我的這篇文章:https://www.cnblogs.com/youcong/p/9607448.html

1.CDN原理

CDN的工作原理用一句話概括，就是將內容提供商的數據，以最快捷的方式分發到離用戶盡可能近的地方與用戶交互，以節省內容重復傳輸的時間。“互聯網高速公路的最後一公裏”，正是對CDN的形象描述。

上面這句話中，有三個關鍵字，分別代表CDN技術中的三個關鍵點。

(1)內容數據:在早期互聯網環境中，80%以上的內容都是靜態文本，CDN技術近乎特指靜態內容加速。到如今，互聯網上提供的內容，在靜態文本和圖片之外，還包括各種動態生成的頁面、視頻、視頻碼流等。

(2)分發方式:從內容提供商到離用戶最近的CDN節點，數據流向可以由內容提供商主動發往CDN節點的，也可以是由CDN節點向內容提供商發請求下載。不同的分發方式，會導致CDN的效果、實現和管理方式，都大不相同。

(3)盡可能近:互聯網上的距離與現實距離並不完全等同。尤其在國內的現實環境中，同城網民跨網訪問都慢如蝸牛。這裏，我們需要對用戶的上網接入環境有所判斷，找到真正“近”的CDN節點提供服務。

CDN工作原理圖:

2.DNS原理

DNS是提高集群可用性的重要工具，也是CDN系統最常用的全局負載調度工具。掌握DNS的原理和管理，是網站運維人員的重要職責。

(1)DNS的由來

在網絡剛剛出現的時候，只有IP地址。後來出現主機名的概念，於是NIC（NetWork Information Center,互聯網信息中心)提供了一個文本文件供大家下載，文件名叫"hosts.txt",裏面存儲有整個網絡中所有主機的主機名和對應的IP地址。每隔幾天，NIC就收集一次全網主機的信息來更新這個文本，然後各主機的管理員們隨後下載這個文本維護新的主機名映射。同時這也是Hosts文件的由來。

互聯網的先行者們大大低估了這個“怪物”的成長速度。IPv4的故事大家已經熟知，hosts.txt則更早碰到了天花板-沒人能維護這個飛速增長的主機名和IP地址映射關系。

所以為了規範互聯網上百花齊放的主機名，同時也為了構建一個可管理的體現，最終形成了RFC1034,DNS就此誕生了（這段簡要的概述，描繪了DNS的前世今生）。

(2)DNS的設計
DNS設計之初，提出了如下幾個要求?

(1)能夠指明網絡地址、路由等信息。

(2)分布式存儲(以確保數據正確性，在失敗時可以使用緩存數據)。

(3)數據格式支持多協議傳輸,這裏指的是應用層協議,即FTP、SSH、RSYNC、SMTP等。

(4)支持多協議訪問,這裏指的是網絡層協議，即TCP和UDP協議。

可以說，DNS系統，是全世界最早、規模最大的分布式系統。

(3)DNS組成

一個完整的DNS系統，由下面的三個元素組成。

a.域名空間和資源記錄

域名空間是一個樹狀結構。樹狀結構的每個節點都對應一個資源集(可能為空);每個節點的標記為0~63B；節點的域名由從節點到根的標記連接組成。

當域名的節點最多不超過127個，不過一般來說，實際軟件實現中支持的域名長度不會超過255B。

資源記錄是和名字相關的數據。

b.名字服務器

服務器端程序，用來保留域名空間和資源記錄，並響應相關客戶請求。一般名字服務器只保存域名空間的一個子集，以使子集成為這個子集的權威。一個子集內的信息又叫做一個區，其他信息通過其他名字服務器查詢。

c.解析器

客戶端程序，可以訪問至少一個名字服務器，接收這個名字服務器返回的結果或者轉向其他名字服務器查詢。

(4)DNS查詢過程

a.遞歸查詢

遞歸查詢可以用一句話來歸納："請對方辯友正面回答!",也就是說，客戶端請求必須得到名字服務器一個"yes or no"的響應結果，然後完成這次解析。

一般情況下，電腦客戶端都會使用遞歸查詢。

b.叠代查詢

叠代查詢可用醫院咨詢臺做比喻。

進醫院看病的人，先到咨詢臺問:“我牙疼找誰看?”

咨詢臺會說:"你掛牙科號，上三樓右拐牙科分診臺。”

也就是說:服務器端(咨詢臺)返回一個可能知道該域名(牙科)解析結果的名字服務器(分診臺)，然後客戶端重新去那臺查詢。

註意:叠代查詢這個過程是可以累加的，因為本次獲得的這個名字服務器，可能會繼續返回一個"可能"知道該域名的名字服務器。就好像你到了三樓分診臺，按提示到了某診室，裏頭還有好幾個醫生，然後你要再詢問一次，才知道最後誰給你看病。

3.DNS查詢結構實現

關於DNS查詢結構實現涉及比較多東西，後期會詳講。

4.DNS調度

(1)DNS負載均衡

因為A記錄可以返回多個，所以在LVS沒有誕生的中古時代，人們使用DNS做負載均衡的。不過這種負載均衡有很多問題:沒有健康檢查、沒有權重設置、沒有哈希分布、沒有故障轉移等。最重要的是，DNS設計中的TTL時間會導致故障發生時，即便運維人員手動幹預，依然無法讓用戶的訪問路由立刻變更為最新狀態。

所以，DNS負載均衡至今依然是一項重要的應用，但絕對不是可信賴的負載均衡應用。

(2)動態DNS

所謂動態DNS，即針對相同的DNS解析請求，可以根據實際情況的變化響應不同的解析結果。

一類動態DNS以F5的GTM為代表，從公開文檔中可知其首選調度算法是RTT。但是我們註意到DNS首選協議是UDP的，只有在數據包大小大於512B和zone transfer的時候才采用TCP協議。而UDP協議並沒有RTT概念。由此可知，GTM是采用被動RTT方式來更新自己內部的動態路由表的。其工作流程大致如下:

a.NS返回一臺GTM的IP給LDNS，LDNS請求到IP;

b.GTM在就近路由表中查詢並返回離LDNS最近的解析結果;

c.如果路由表中還沒有LDNS所在網段，這臺GTM會聯合其他GTM共同對LDNS發起TCP請求，計算RTT並匯總RTT結果，從而更新路由表返回最近結果;

另一類動態DNS則是根據請求的IP地址對應的view做區分，幾個主要的DNS服務軟件如Bind9、TinyDNS、WINMyDNS都支持這種動態解析。這種動態解析的運維難點，在於如何收集足夠準確的IP段地址歸屬信息，並保持定期更新。目前來看，主要來源有幾個:每月MaxMind的GeoLite數據庫、不定期更新的純真數據庫和自建DNS數據庫的請求日誌歸類分析。

5.其他調度方法

除了最常見的DNS調度外，CDN中還有其他調度方式，近年來比較常見的，是針對特定場景下的IP調度方式。

(1)視頻流調度

在之前對DNS原理的介紹中，我們已經知道采用DNS調度的最大問題，就是用戶配置的DNS是不受網絡運維控制,因此帶來的解析偏差，會導致請求響應的跨網絡長距離訪問。對於圖片或者頁面文本，結果可能是由十幾毫秒變成幾十或上百毫秒。而文件越大，傳輸延遲效果會明顯。這對於視頻網站來說，是最不可忍受的事情。

視頻播放與頁面顯示不同，它是一個長期運行的過程，追求的不是瞬間的響應速度，而是長期的碼流穩定。一般的高清網絡視頻(720p),碼流要求在4Mbps以上。如果服務器距離用戶接入還要經過十多跳路由反復接力，那效果肯定不如人意。

所以視頻網站，一般會使用IP調度來盡可能的解決這個問題，思路如下:

a.視頻播放器發出請求到網站的調度服務器。這一步可以先通過DNS調度調度來降低後期運算和復雜度;

b.調度服務器根據HTTP請求的來源IP，確認用戶接入的實際歸屬;

c.調度服務器查找實際歸屬地最近的視頻服務器IP，處理原請求的文件路徑部分,拼接形成實際的視頻播放下載地址並返回302響應;

d.視頻播放器根據得到的302響應，從視頻服務器下載視頻播放;

(2)動態生成頁面元素鏈接

視頻流調度說的方法看起來不錯，但實際是有其局限性的，它意味著原本一次就能完成的請求，被拆成兩次才完成。其中重新建連等時間是多出來的，在動輒上兆字節(MB）大小的視頻請求中，TCP建連、Header解析等時間可以忽略不計，但是在一個頁面上有上千個只有幾千字節(KB）甚至幾字節大小的小文件元素請求的條件下，這個時間累積起來就非常影響用戶體驗了。

不過在大規模網站實踐中，對於頁面元素，也有一些變通的方法，可以針對特定情況來實現IP調度。針對頁面大量使用的某一類元素，比如用戶頭像、商品圖片等。因為其流量較大，重要性較高，原本就配備了專用的服務集群。這些元素在發布端不需要域名來做發布路徑的對應區分即可提供服務。這時，我們可以把調度計算的負載，從圖片發布的集群轉移到動態頁面生成發布的服務器上。稍微改造之前提到的調度流程變成下面這個步驟。

a.瀏覽器發送頁面請求到動態頁面服務器,同樣這一步使用DNS調度來降低復雜度;

b.動態頁面服務器根據HTTP請求的來源IP，確認用戶接入的實際歸屬;

c.動態頁面服務器查找離實際歸屬地最近的圖片服務器IP，替換動態頁面模板的圖片文件路徑的主機名部分，拼接形成實際的圖片下載地址;

d.模板編譯成完整的頁面內容後,響應返回給瀏覽器解析渲染;

e.瀏覽器直接根據圖片元素中的地址發起請求;

(3)BGP和anycast

anycast是一種網絡技術，最早是1998年在RFC1546中提出的，意思是"主機向一個任播地址發送數據報,網絡負責盡力將數據報傳遞到至少一個,最好也只是一個，按任播地址接收數據的服務器上。其設計初衷是徹底簡化在網絡中尋找特定服務器的任務。

從基礎概念上聽起來有點像後來大家熟悉的LVS。事實上anycast的幾個重要優勢，比如負載均衡、集群冗余和攻擊防護，也都是LVS提供的，不過anycast因為通常運行在路由器層面，所以它可以簡便地確定來源主機與目的主機組中的哪臺主機最近。目前，anycast技術最典型的運用就是公共DNS服務。比如我們所熟知的Google Public DNS,其地址為8.8.8.8.

在部署上，anycast對網絡資源要求極高，一般需要有自己的自治域號，自治域內不同的路由器對應不同的上聯自治域，並采用BGP協議廣播相同地址，這個IP地址就是anycast地址。路由器後端，可以是直連服務器，也可以是通過負載均衡集群，或者仍然采用anycast方式聯系服務器。

anycast地址只能作為目的地址,不能作為源地址。因為每次報傳輸的實際主機可能都是不一樣的。這點，我們可以通過DNS解析測試驗證:配置8.8.8.8後,實際在DNS服務器收到的localDNS地址並不是8.8.8.8.後來IPV6出現後，新的RFC2373中修改明確了anycast的定義。

6.動態加速概述
傳統的CDN系統，都是運用在靜態文件加速上的，即便是視頻點播，也是flv文件通過關鍵幀信息技術切分成一個個小的靜態文件。不過隨著技術和業務需求的發展，CDN系統也確定在慢慢出現針對動態業務的改進和擴展

(1)動靜元素分離

現在的互聯網應用，大多是富媒體形式，頁面中圖片、樣式、客戶端腳本的數量和字節數，都遠遠超過頁面載體HTML文件。而頁面加速的根本目的，是為了給應用用戶更好的體驗。只有樣式符合預期的頁面，才是對用戶友好的、合格的頁面:只有頁面元素完整顯示，才是頁面真正加載完畢。

元素的本質變化分為兩個方面，一個是實時變化，一個是非實時變化。

一般請求下，實時變化的元素少數，非實時變化的占大多數。將緩存控制的範圍從CDN擴展到瀏覽器端時，很多可以緩存幾秒鐘的元素，也可以歸入非實時變化的範疇。那麽，真正絕對不能緩存的元素就更少了。

現在，更詳細地規劃原有域名拆分計劃，保證至少實時和非實時變化的元素不要在同一域名下發布。其次，讓過期比較敏感的元素，和不敏感的元素甚至永不過期的元素也在不同域名下發布。

在緩存過期維度以外，域名拆分通常還有另一個維度，即平均文件大小的差異。通常1MB以下和1MB以上的文件，會拆分到不同域名，甚至可以更詳細到以100KB為界。這通常有緩存性能方面的考慮。

這樣，頁面上的大多數元素，都可以通過普通的CDN技術完成加速。只剩下少量的HTML、JSON等數據，需要每次等待源站遙遠的響應。

動靜元素分離是至今為止加速動態網站訪問最基礎最有效的方法。

(2)動態頁面局部更新

動態頁面最早期的實現方法是這樣的，在cgi中解析處理請求參數,通過數據庫處理返回值，拼接字符串，然後返回最後的頁面結果。

稍後的實現進化成這樣:動態程序員解析處理請求參數,通過數據庫處理返回值後傳遞給模板系統,替換對應模板中的變量,生成最後的頁面結果並返回。

後面這個辦法，因為開啟了模板系統的本地緩存，所以發布服務器響應性能可以提高很多。但是對於全網CDN系統來說，這些響應都是實時變動的內容,都無法緩存。

a.SSI和ESI

動態頁面繼續發展，人們逐漸發現所謂的動態頁面中很多內容其實還是不變的，沒必要一次又一次地生成，於是，SSI在模板技術的基礎上被發明出來。

使用SSI，動態頁面服務器只需要生成變化內容的那部分頁面代碼，然後由靜態頁面發布服務器，在響應請求時，通過SSI技術解析加載全部內容。這樣，動態服務器的負載降低了，服務響應相對也就是更快了。

b.分級校對

ESI對頁面開發人員能力有一定要求，不太適合通用情況。在標準HTML代碼的環境下，也可以通過一些辦法來盡力節約動態頁面的傳輸。

下面說下基於跨網高延遲條件的設計方案:

001.CDN系統分為邊緣節點和中心節點兩層;

002.邊緣節點收到用戶請求，發起回源請求到中心節點;

003.中心節點發起回源請求到實際的頁面發布服務器，並接收最新結果;

004.中心節點本地比對最新結果和上一個版本，得到一個補丁版本;

005.中心節點返回補丁版本給邊緣節點;

006.邊緣節點應用補丁更新本地緩存文件到最新版本，並返回給用戶;

(3)傳輸網絡優化

Web2.0以來，用戶與服務器端的交互比重逐漸增加，已經不再是一邊倒的下載流量，上傳流量的優化也成為了CDN系統需要關註的問題。

針對這一方面的問題，目前主要是對TCP/IP層做一些優化。TCP協議設計要求是針對普適場景，有以下三個特征:

a.慢啟動

TCP初始滑動窗口較小，默認是3。然後在建連的往返過程中翻倍增加。

在互聯網接入帶寬動輒上10MB的今天，這麽小的滑動窗口初始值，顯然是一種浪費。

因為網頁元素本身較小，國內最大的CDN廠商藍汛曾經統計過其服務的全部客戶流量的總統計數，其平臺的平均文件大小，只有4KB左右。

自Google首先提出這個問題，並將此初始值提高到10之後，這個做法已經逐漸得到廣泛認可。隨後，Linux內核從2.6.34版本開始可以通過IP命令直接修改這個參數，從3.0版本開始默認設置也提高到了10。

當然了，這個設置也不是萬能藥。其主要適用的是短連接和小文件的場景。對自身業務是否會有較大地性能提升，還需要經過實際測試來判定。

b.以丟包判斷鏈路擁塞

主要考慮的是可靠鏈路上的擁塞問題，也就是說如果發現鏈路堵塞了，就減少小滑動窗口，慢一點發包，等擁塞解除再恢復原先的傳輸速度。

而事實中，在移動互聯網的環境下，更多的是移動網絡本身的信道問題導致鏈路錯誤引起丟包，結果TCP的滑動窗口一直維持在比較小的狀態，整個數據傳輸陷入越傳越慢的惡性循環。從這個場景出發，對於移動網絡，出現擁塞時更好的應對反而是盡快地重發數據報。

c.滑動窗口的加性增乘性減

在傳輸過程中，如果一切正常，滑動窗口會在每個RTT都加1,。但是如果發生擁塞時，滑動窗口直接減半。這種加減辦法對視頻播放等應用比較不利，一次瞬間的帶寬抖動，需要多幾倍的時間才能恢復到之前的傳輸狀態。

目前有很多商業產品在做TCP優化相關的工作。從部署架構上，可以分為單邊加速和雙邊加速。從協議原理上區分，采用的技術包括數據包快速重傳、滑動窗口加速滑動、ACK復制、合並數據包統一校驗等。

在TCP的擁塞控制算法方面，Linxu2.6.8到2.6.19版本之間使用BIC，之後默認使用CUBIC。FreeBSD使用New Reno。此外，還有Vegas、HSTCP、FAST TCP、TCP SACK等。它們各自針對之前提到的三個主要特征做了相應的修改，以適應其他環境。

比如Vegas和FAST TCP不再以丟包為鏈路擁塞的判斷依據而是參考發包隊列的長度;HSTCP則修改了滑動窗口的增減規則，當前窗口越大，增加速度相對標準TCP就越快而減少得也越慢;DataCenterTCP則通過帶有ECN（顯示擁塞通知)的ACK包的比例，動態確定滑動窗口的減少程度。

(4)SPDY簡介

在應用層上，也有各種對於加速的嘗試。比如HTML5協議中的WebSocket技術、HTTP協議1.1版本規定的Presisent connnection和pipelining技術、以及很可能成為HTTP協議2.0版本的SPDY技術。

現有的HTTP協議，存在幾個嚴重不足?

a.一個HTTP連接在同一時刻智能獲取一個資源,而且一旦當前請求耗時比較長，後續請求都會被阻塞;

b.瀏覽器與服務器之間只能是單向的,即瀏覽器主動向服務器發請求;

c.Header信息在每次HTTP請求中都要完整地發送一遍;

WebSocket和pipelining也可以解決一部分上述問題。但是這兩種技術都要求對網頁進行較大程度地改造甚至是重寫。而SPDY目前則在HTTP協議前提下，通過SSL層的處理，實現了對原有頁面代碼的兼容。

主要來說，SPDY有如下特點:

a.采用多路復用技術，在一個連接上並發請求,而且細化到CSS等重要類型的文件可以優先請求;

b.服務器可以主動給瀏覽器推送數據以加強預加載的能力,最新的協議說明中,甚至列出服務器可以給瀏覽器推送DNS記錄的待實現項;

c.在同一連接內，不用重復發送相同的Header信息，而且Header信息還是通過壓縮方式傳輸的;

d.強制使用SSL以提高安全性。當然這個特點在社區討論中還屢屢被抵制;

從2012年以來，Google、Twitter、FaceBook、Amazon等網站都支持SPDY;而瀏覽器方面，Chrome、Firefox、Opera、Silk也都支持SPDY;服務器方面，Google最早推出的是Apache的mod_spdy模塊,F5公司隨後在其負載均衡產品跟進，Jetty、Nginx等也逐步完成SPDY的支持工作。可以說，SPDY的大規模使用，只等IE6等陳舊瀏覽器淘汰即可。

最後還要說一下，本篇還要續篇，可以理解為下文，下文主要講緩存和本地負載均衡。希望這篇文章能夠給大家帶來有益的啟發和收獲。

網站運維技術與實踐之集群架構規劃