338
《架構真經：互聯網技術架構的設計》水平擴展
水平擴展
在實踐中，我們經常告訴客戶，“向上擴展注定會失敗”。這是因為在超高速增長的環境裏，公司計劃以水平方式擴展（又稱之為向外擴展）至關重要。大多數情況下，這是通過對跨越多個係統工作負荷的拆分或者複製完成的。數據拆分的實施，類似我們在第2章中描述的眾多方法中的一種，當超高速增長的公司無法擴展時，他們唯一的選擇就是購買更大和更快的係統。當由最昂貴的係統提供商所提供的最快和最大的係統遇到擴展瓶頸時，這些公司就遇上了大麻煩。這是1999年eBay受到傷害的根本原因，十多年後的今天我們仍然能夠在客戶的業務中看到它的影子。擴展的限製和矛盾不僅是物理問題。它們更多是由邏輯爭用所引起的，更大和更快的硬件根本無法解決。在深入討論這個話題之前，讓我們先聽聽一位首席技術官是如何從防火牆的實施過程中吸取這方麵教訓的。
克裏斯·施瑞穆斯是醫療財務管理公司ZirMed的首席技術官，他們提供的服務使醫療保健組織能夠通過一個全麵的端到端平台，在優化其收入的同時保障患者們（客戶）的健康。因為ZirMed係統需要處理患者的敏感數據（PII），所以受到醫療電子交換法案（HIPAA）的約束，克裏斯和他的團隊設計的數據中心網絡具有非常嚴格的防火牆策略。係統的網絡層和應用層之間的通信需要通過防火牆。克裏斯回憶道，“我們原來的設計要求部署兩套非常強大的防火牆，可以透視產品中的每個子網。在公司規模很小的時候，係統運行得很不錯。每當係統接近容量閾值時，可以不斷地添加硬件設備來擴大容量。於是我們不停地購買更大的設備。從早期非常小的設備開始，到後來持續不斷地向上擴展。在最終改變防火牆設備模式之前，已經變成兩個巨大的運營商級別的設備了。這些設備每箱配備了四個刀片服務器。”
兩台設備被配置成高可用性（HA）模式，供應商聲稱這種配置允許服務在故障發生時可以無縫轉移。不幸的是，ZirMed的產品在會話期間依賴狀態，並且會話狀態無法在一對防火牆之間做優雅失敗的平滑配置。克裏斯繼續說，“防火牆供應商一直在跟我們說，在機箱之間有一個高速網絡，可以保持所有的套接字和會話，因此可以完成無縫故障轉移。但是他們所說的無縫與我所說的無縫完全不同，因為每次應用失敗都會出現套接字短暫停止連接的問題，所以造成網絡服務器在嚐試重新連接數據庫時出錯。事實上，直到這時候我們才知道供應商配置了相對積極的故障轉移策略。如果設備運行中單機配置，該策略隻在係統出現危機的最後一步重新啟動，而當它在高可用配置下配對運行時，就更加積極，當主機上有風吹草動時，會啟動故障轉移把防火牆轉移到備機。所以係統在雙節點高可用狀態運行時，設備的故障率比單節點運行時高。這反過來給應用帶來了很多麻煩。”
因為其實施的複雜性，ZirMed還被防火牆的其他問題所困擾。“我們使用內容可尋址存儲係統，它依賴於網絡多播協議，消息要跨越所有的節點，以通知它們。”克裏斯解釋說，“我們嚐試過把那部分拆分出來，而且自認為已經拆出來了，但實際上並沒有做到。所有的UDP（用戶數據報文協議）流量都要通過防火牆。最終，UDP流量把防火牆壓倒了，結果連發出的連接請求都無法進入刀片服務器，因為我們無法看到這一點，所以不得不把供應商請過來查看。這個係統太過複雜，有底盤，還有很多刀片服務器分布在各處，我們搞不清楚這個係統是如何工作的。”
克裏斯和他的團隊開始討論，是否應該選擇不同的供應商，購買另外一對更大的防火牆，但是後來他們有些如夢方醒。克裏斯說，“當構建軟件時，我們清楚地知道必須要向外擴展而不是向上擴展。為什麼在購買硬件的過程中不采用相同的方法呢？正是這個簡單的問題使團隊徹底改變了思路。最終，我們從越來越大的全麵防護變成現在針對性很強和更小的防火牆實施。”
在ZirMed的新設計中，他們實施了四對防火牆。雖然略多，但從管理角度來看，設備本身要簡單得多。在這裏我們再次看到了令人不安的“複雜性”。更多的設備等於係統更複雜，因為更多的設備需要更多的管理和監督。但是從另外一個角度來看，更多的設備等於更低的複雜性，因為總體故障率降低，需要管理的事件減少。“我們現在有更小的設備，供應商們知道如何把它們構建得非常非常好，”克裏斯指出。“這些防火牆很簡單。我們完全掌握這些設備。它也使我們對這些設備上運行的內容了解得更多，更重要的是，現在的設計允許設備數量從4個增加到6個、8個、10個或12個，或任何我們需要的容量。我們還可以繼續添加單個設備，隔離出不同的網絡分區。當然，我們必須做一些防火牆規則的調整，但是它允許我們在硬件層向外擴展，而不是向上擴展。”
向外擴展而不是向上擴展的好處很多。克裏斯總結說：“我們已經看到了巨大的勝利，勝利太多，甚至以我們不太明白的方式取得成功。我們計劃把研發環境建立防火牆規則的工作交給應用技術團隊。他們沒必要是防火牆專家。他們可以動手建立防火牆規則然後通過評審，因為我們知道在這些規則被推送到生產環境之前，網絡工程師將會審查，因為我們廣域網的防火牆阻止了外部的流量，所以這麼做並沒有增加風險。這不僅讓擴展更加靈活，而且也使防火牆的管理更加靈活，這些體現在把能力有效地賦予團隊。”
聽了克裏斯是如何意識到向外而不是向上擴展的重要性，現在讓我們討論一下有關這個主題的一些規則。本章將圍繞著如何把係統設計為水平擴展，而非向上擴展的思路展開討論，包括使用商品化硬件，以及如何把這個概念應用到數據中心。
規則10——向外擴展
內容： 向外擴展是通過複製或拆分服務或數據庫而分散事務負載的方法，與此相對的是向上擴展，即通過購買更大的硬件而實現的擴展。
場景： 任何預計會迅速增長或想追求低成本高效益的係統、服務或數據庫。
用法： 用AKF擴展立方體因地製宜確定正確的拆分方法，通常最簡單的是水平拆分。
原因： 以複製數據和功能為代價實現事務的快速擴展。
要點： 讓係統向外擴展，為成功鋪好路。期待能向上擴展，結果卻發現自己跑得越來越快，已經無法再購買到更快和更大的係統，千萬不要掉進這個陷阱。
當客戶和事務快速增長，而係統卻無法擴展到多台服務器時，該怎麼辦？在理想的情況下，可以分析各種選項，不是購買更大的服務器，就是投入研發資源使產品可以在多台服務器上運行。能在所有層級上讓產品運行在多個服務器上叫做向外擴展。不斷地在更大的硬件上運行任何層級的係統就是向上擴展。在方案分析中，可能會根據投資回報率（ROI）決定購買更大的服務器，而不是投入研發資源來修改應用，因為這麼做的成本更低。雖然我們認為決策分析的方法較好，但是，對快速增長的公司和產品來說，這樣的決策有缺失，以我們的經驗，即便是對溫和增長的公司，這樣的決策也存在問題。
這樣的分析中最常見的錯誤是，未能分析底層硬件和基礎設施的更新換代周期。把一台64位服務器的處理器從兩個八核升級到四個八核，從成本比例上看與得到的計算資源改進一致（大致是成本的兩倍，改善結果有可能略低於阿姆達爾定律所估算的兩倍）。當我們繼續購買更大的有更多處理器的服務器時謬誤就出現了。成本與計算處理能力的曲線是一個冪律，較大服務器所帶來的處理能力的增加與成本增加不成比例（見規則11）。假設公司不斷取得成功和成長，你將繼續沿著曲線購買更大的係統。雖然可能預測技術更新的時間，但將被迫在一個令人難以置信的高價位購買係統，相反，如果有水平擴展的架構，那麼就可以購買相對更便宜的係統。總的來說，總資本支出明顯增加。通過投入技術資源解決這個問題的成本當然會隨著代碼規模和係統複雜度的增加而增加，但這個成本應該是線性的。因此分析的結論應該是立即花時間修改代碼以向外擴展。
使用某大型服務器供應商所提供的在線定價和配置實用程序，圖3-1中顯示了七台服務器的成本，除了處理器及其內核越來越多外，服務器的其他配置（內存、磁盤等）都盡可能相近。不可否認，從計算資源角度看，兩個四核處理器不完全等同於一個八核處理器，但成本比較接近。請注意數據模擬線呈指數趨勢。
圖3-1 單位核的成本
根據我們400多個客戶的經驗，這種分析的結論幾乎總是修改代碼或數據庫，實現向外而非向上擴展。多種技術的更新周期，要求大型服務器反複不斷地投入資本，使問題更加嚴重，從而促使購買交易的達成。這就是為什麼向上擴展就是向上失敗，這是AKF合作夥伴的信念。向上擴展最終會停在一個點，要麼是成本太高，要麼是沒有更大的硬件。例如，我們有一個客戶有能力將其用戶分散到不同的係統裏，卻繼續向上擴展其數據庫硬件。他們最終停在首選硬件供應商提供的六個最大的服務器上。這些係統的單價超過300萬美元，全部六台服務器的硬件成本接近2000萬美元。隨著客戶需求的增加，該客戶掙紮著繼續向上擴展，他們開展了一個數據庫水平擴展的項目。采用四台單價35萬美元的較小的服務器替換那些大型服務器。最後，他們不僅成功地向外擴展繼續為客戶服務，而且實現了近1000萬美元的成本節省。該公司繼續使用舊係統，直到最終過期報廢，然後以成本較低的較小的係統替換。
大多數應用要麼從一開始就可以在多個服務器上運行，要麼可以很容易地修改以適應多服務器的情況。大多數的SaaS應用可以通過簡單地複製代碼到多個應用服務器，然後把它們配置在負載均衡器的後麵來實現。應用服務器彼此之間不必互相通知，從負載均衡器發來的請求可以由任何一個服務器來處理。如果應用必須跟蹤狀態（參見第10章有關為什麼要消除狀態），一個可能的解決方案是負載均衡器允許使用會話cookie，以維持客戶的瀏覽器和特定的應用服務器之間的關係。一旦客戶提交了初始請求，相應的服務器繼續服務該客戶直到會話結束。
對數據庫進行擴展往往需要更多的規劃和技術工作，正如我們在開頭解釋的那樣，這是要花費精力的。在第2章中，我們涵蓋了三種應用或數據庫擴展的方法。在AKF擴展立方體中被標示為X、Y和Z軸，分別對應著複製（克隆），拆分不同的東西（服務），拆分類似的東西（客戶）。
你可能會反駁，但這是真的。“英特爾的聯合創始人戈登·摩爾在1965年預測，放置在集成電路上的晶體管數量將每兩年增加一倍。”摩爾定律已經驚人地保持了超過50年而屹立不倒。正如戈登·摩爾在2005年接受采訪時承認的那樣［1］，這條定律不可能永遠成立。另外，如果貴公司是真正的超高速增長公司，客戶或交易的增長速度會比每兩年翻一番更快，貴公司可能是每個季度翻一番。此外，阿姆達爾定律暗示不可能獲得摩爾定律的全部好處，除非耗費大量的時間優化可以並行的解決方案。如果依靠摩爾定律來擴展係統，那麼無論是應用還是數據庫都很有可能失敗。
規則11——用商品化係統
（金魚而非汗血寶馬）
內容： 盡可能采用小型廉價的係統。
場景： 在超高速增長的生產係統采用該方法，在比較成熟的產品中以此為架構原則。
用法： 在生產環境中遠離那些龐大的係統。
原因： 可快速和低成本增長。隻采購必要的容量，不浪費在尚未明確的容量需求上。
要點： 構建能夠依靠商品化硬件的係統，不要掉進高利潤和高端服務器的陷阱。
超高速增長可能是一個孤獨的領域。有那麼多的東西需要學習，而可供學習的時間又非常有限。但請放心，如果接受我們的建議，你就會有很多的好朋友——那些消耗電力、散發熱量、擾動空氣、努力賺錢的電腦朋友們。而在超高速增長的世界裏，我們相信擁有很多低成本的小“金魚”要比擁有幾隻高成本的“純種”汗血寶馬更好。
在本科的微積分教科書裏有幾行我最喜歡的字，“對漫不經心的旁觀者來說，這應該是顯而易見的<插入一些完全不起眼的文字>。”
這個特別聲明給我留下了深刻的印象，主要是因為對我來說作者當時所呈現的既不直觀也不明顯。擁有大量較小的電腦看起來似乎並不比擁有少量龐大的係統更有優勢。事實上，更多的計算機可能意味著更多的電力、空間和冷卻需求。多且小經常比少且大好的原因有兩個，本章後麵會詳細介紹。
設備供應商受益於把利潤最高的產品賣給你。幾乎對於每個供應商來說，具有最高利潤的產品往往是處理器最多的最大的產品。為什麼會是這樣？許多公司依靠更快和更大的硬件來完成必要的處理工作，卻不願意在擴展自己基礎設施的地方投入。因此，設備製造商把這些公司當成人質索要更高的價格和利潤。但是這裏麵有個有趣的問題，與有同等數量處理器的較小係統相比，這些更快和更大的機器並非真正能夠做更多的工作。以CPU為例，這些機器比較小的係統擁有更少的處理能力。在添加CPU時，每個CPU的工作量比單CPU的係統（不考慮核數）少。這有很多原因，包括多處理器調度算法的低效率、內存總線訪問速度衝突、結構障礙、數據障礙等。在虛擬化環境中，管理虛擬機的開銷隨著物理機規模的增加而增加。效率最佳的似乎是兩個CPU或四個CPU的物理主機。
仔細回顧一下我們剛才說過的話，你花錢買進更多CPU，但實際上每個CPU所做的事情卻更少，供應商總共盤剝你兩次！
當與以前的信息衝突的時候，大多數提供商很可能會在第一階段否認。聰明的供應商會迅速改變說法，指出整體擁有成本將會下降，因為較大服務器比較小服務器消耗的電力比較少。他們可能會說，你可以與某夥伴合作，通過把係統分區（或虛擬化），來獲得小係統消耗較少電力的好處。這使我們意識到：必須算算賬。
實際上，更大的係統可能會消耗更少的電力並降低成本。隨著電力成本的增加和係統成本的降低，毫無疑問係統存在著合適的規模，可以最優化電力消耗、係統成本和計算能力。供應商絕不是信息的最佳來源。你應該自己算清賬。算賬的結果絕對不會促使你購買市場上能買到的最大的係統，因為這並不劃算。為了弄清楚應該如何回應供應商的論點，我們把它們分解成幾個組成部分。
我們把電力成本和單位電力消耗，與獨立第三方的係統利用率基準數據進行比較。仍然可以找到在適合範圍內的商品化硬件（也就是說還沒有被供應商作為高端係統加價），然後最大化計算能力，同時滿足最小電力和空間的要求。幾乎在所有情況下，當考慮所有成本時，整體的擁有成本通常會下降。
關於虛擬化，請記住沒有免費的軟件。虛擬化（域或分區）的理由很多。但是將係統虛擬化成四個單獨的域，與購買四套規模相當的係統相比，永遠不會獲得更大的處理能力和吞吐量。因為虛擬化必須利用CPU的資源來運行，而這些資源一定要有它的出處。另外，在比較大的分域係統中的大係統容量，與同等規模的小係統容量相比是一個錯誤。
促使我們使用商品化係統而不是昂貴係統的其他原因是什麼？雖然我們積極計劃擴展，但是擴展速度是有成本的。對商品化硬件我們更容易談判。雖然我們可能有很多這種係統，但是丟棄它們也很容易，而且可以隨心所欲地安排工作，而比較昂貴的係統則需要花大量的時間去掌握。雖然這似乎有些難以理解，但是，與比較昂貴的係統（汗血寶馬）相比，我們已經成功地使用較少的人管理更多的商品化係統（金魚）。我們維護這些係統的成本較低，而且也可以負擔得起更多的係統冗餘，因為每個單元上的部件（例如CPU）較少，係統失敗的機會也比較低。
最後，讓我們來解釋一下為什麼把這些東西稱之為“金魚”。因為這些係統非常便宜，如果它們“死掉”，你可能會輕鬆地丟棄它們，而不是投入大量的時間來修複。另一方麵，“汗血寶馬”代表了相當大量的投資，因此需要時間來維護和修複。最後，我們更喜歡有很多的小朋友，而不是幾個大朋友。
規則12——托管方案擴展
內容： 把係統部署到三個或更多活的數據中心，以降低總體成本、增加可用性並實現災難恢複。數據中心可以是自有設施、托管或雲計算（IaaS或PaaS）實例。
場景： 任何正在考慮添加災難恢複數據中心（冷備）的快速增長的業務，或希望通過三數據中心方案優化成本的成熟業務。
用法： 根據AKF擴展立方體來擴展數據。以“多活”方式配置係統。使用IaaS/PaaS（雲計算）來解決突發容量問題，新投資或者作為三數據中心方案的一部分。
原因： 數據中心故障的成本對業務的影響可能是災難性的。三個或更多個數據中心的解決方案的成本通常比兩個數據中心少。考慮使用雲計算作為部署之一，高峰流量來臨時向雲擴展。擁有基礎流量的設施；租賃解決高峰流量的設施。
要點： 在實現災難恢複時，可以通過係統設計實現三個或更多個活躍數據中心以降低成本。IaaS和PaaS（雲計算）可以快速地擴展係統，應用於高峰需求期。通過係統設計確保如果三個數據中心中隻要兩個可用，則功能完全不受影響。如果係統擴展到三個以上數據中心，則為N-1個數據中心可用，功能完全不受影響。
數據中心已成為迅勐發展公司擴展的最大痛點之一。因為數據中心需要長時間的規劃和建設，而且經常是在快速增長期間我們所想到的最後幾件事情之一。有時候我們想到的“最後一件事”往往就是使我們的公司陷入最危險境地的事情。
建設和運行數據中心所需要的核心能力很少與某個技術團隊重疊；避免擁有自己的數據中心，直到公司的規模大到可以通過建設和運行自己的數據中心來節省成本成為可能。在成長期間使用托管和雲計算提供商；讓他們承擔數據中心的操作風險以及數據中心建設的計劃。通過自有數據中心實現成本節約的最低有效數據中心的規模大約是3MW的IT容量——約相當於9000個雙插槽的服務器。構建這樣的數據中心，對使用標準化設計和設備經驗豐富的公司需要12個月，對選擇使用新設計和新設備的公司需要24個月。根據指定設施的冗餘級別，所需資本從3000萬美元到5000萬美元不等。建設和運行數據中心並不是一個簡單的任務。避免建設和運行自己的數據中心，直到公司規模大到自建數據中心劃算的時候。
此條規則是針對“如何”和“為什麼”拆分數據中心以應對快速增長的簡要回答。
首先，讓我們回顧幾個基礎。為了故障隔離（有助於高可用性）和事務增長，我們想要使用在規則8和規則9中分別給出的Y軸和Z軸拆分的方法。為了高可用性和事務的增長，我們將按照規則7所述的沿X軸複製（或克隆）數據和服務。最後，我們將假設你嚐試過應用第10章中介紹的規則40，要麼有一個無狀態的係統，要麼可以繞過有狀態的需要而允許多數據中心部署。正是對數據和服務的這種拆分、複製和克隆以及無狀態，奠定了分散數據中心並使其跨越多個設施和地區的基礎。標準化的係統配置、代碼部署和監控使托管網站和雲計算網站之間可以實現無縫擴展。
如果沿著Z軸適當地拆分數據（見規則9），我們就可以潛在地將數據定位到更靠近請求數據的用戶。如果在拆分數據的同時保持以個人用戶為單位的多租戶模式，那麼我們就可以選擇靠近最終用戶地理位置的數據中心。如果服務的最小單位是公司，我們也可以定位在所服務公司的旁邊（如果它是一個大公司，至少是那些公司中員工最多的辦公室）。
讓我們從三個數據中心開始。每個數據中心大約是33%數據的“家”。我們將其稱為數據集A、B和C。每個數據中心的每個數據集都有一半數據被複製到對應的數據中心。假設做Z軸拆分（見規則9）和X軸數據複製（見規則7），數據中心A中客戶數據的50%會存儲在數據中心B，另外的50%將存儲在數據中心C。如果任何數據中心失敗，失敗數據中心中50%的數據和關聯的事務將會被轉移到其對應的數據中心。如果數據中心A失敗，其數據和事務的50%將被轉移到數據中心B，另外的50%被轉移到數據中心C。如圖3-2所示。結果是運行係統總共需要200%的數據，每個數據中心隻包含66%的必要數據，每個數據中心包含主備兩份拷貝，主拷貝（運行係統所需數據的33%）和其他每個數據中心副本的50%（在總共33%的額外數據中運行係統需要16.5%）。
圖3-2 數據中心複製的拆分
讓我們做些計算來了解為什麼這個配置比其他方案更好。假設發生地理上孤立的災難事件，我們需要至少兩個數據中心存活。有分別標記為A和B的兩個數據中心，你可能決定數據中心A處理所有的流量，數據中心B做冷備份。在熱/冷（或主動/被動）配置中，兩個數據中心都需要配置100%的計算和網絡資產，其中包括100%的網絡和應用服務器、100%的數據庫服務器和100%的網絡設備。電力和互聯網連接的需求也與此類似。每個數據中心可能需要保持略微超過服務所需容量的100%來處理需求激增所帶來的峰值流量。假設兩個數據中心各保持110%的容量。當為一個數據中心購買額外的服務器時，也必須為另外一個數據中心購買。你也可能決定使用自己的專線連接兩個數據中心，以確保數據複製的安全。運行兩個數據中心將有助於在發生重大災難時存活，因為在災難發生最初會有50%的交易失敗，直到將流量轉移到備用數據中心，但是從預算或財務角度它幫不了忙。數據中心可能的宏觀設計如圖3-3所示。
圖3-3 雙數據中心配置，“熱”和“冷”
但是三數據中心的解決方案可以降低成本。因為對所有的非數據庫係統，在係統發生故障時，每個數據中心隻需要具備150%的容量就可以運行100%的流量。無論采用什麼方法數據庫都需要200%的存儲，無法降低成本。電力和設施消耗大約也是單個數據中心需求的150%，顯然需要更多的人來應付三數據中心的需求，這個開銷可能比150%略高。唯一不成比例增加的地方是網絡互聯，因為三個數據中心比兩個數據中心需要兩個額外的連接（而不是一個）。數據中心的新配置如圖3-4所示，相關運營成本的比較見表3-1。三個數據中心中的任何一個都可以是雲數據中心，這也可以減少運營需要增加的人員。
圖3-4 三數據中心配置，三個熱數據中心
表3-1 成本比較
配置 網絡 服務器 數據庫 存儲 節點互連 總成本
單數據中心 100% 100% 100% 100% 0 100%
冷熱雙數據中心 200% 200% 200% 200% 1 200%
雙活雙數據中心 200% 200% 200% 200% 1 200%
三活三數據中心 150% 150% 150% 200% 3 ～166%
如上所述，選擇三個數據中心而不是兩個可以減少硬件成本25%（從峰值的200%需要降到150%）。據此推斷需要50台服務器以滿足高峰期需求，企業應該購買51台服務器並把它們托管在51個不同的數據中心。從學術角度來看，這的確最小化了硬件支出，但是試圖使用這麼多網站所帶來的網絡和管理成本的增加使這個想法顯得十分荒唐。
三數據中心配置的一個很大的好處是能夠利用空閑容量創建測試區（如負載和性能測試），以及在需求高峰期間利用這些閑置資產的能力。這些尖峰幾乎隨時可以發生。這也許是因為一些特殊的和計劃外的新聞發布，也許隻是某個關係格外良好的個人或公司有一些令人難以置信的瞬間流量刺激。手頭上的災備能力開始獲得流量，我們很快開始購買額外的容量！
正如我們所暗示的，運行三個或更多的數據中心也有一些缺點。因為所有數據中心都是活的，每個數據中心都在發揮作用，所以也帶來了一些額外的操作複雜性。我們認為，雖然有些額外的複雜性存在，但是並不比運行熱／冷數據中心顯著。保持兩個數據中心同步很困難，特別是團隊沒有機會驗證單一數據中心在需要的時候是否可以發揮作用。繼續運行三數據中心有些挑戰，但並不是特別難。
即使其他成本最終下降，網絡傳輸成本仍以相當快的速度增長。對於完全連接的數據中心拓撲，每個新節點（N+1）都需要N個額外的連接，其中N是先前的節點數。公司通常通過協商批量折扣和壓低第三方傳輸供應商成本，從而妥善地處理這筆費用。另一個選擇是將流量轉發到對等網絡以優化成本和性能，特別是當流量的峰值不規則或顯著大於基線流量的時候。這需要仔細分析可能帶來的好處以及轉發到對等網絡的成本。
當然，利用好IaaS的彈性，你就不需要“擁有”一切。一種做法是分別在三個地理位置（如亞馬遜AWS的“地區”）“租賃”一個數據中心。或者采用混合的方法，保持托管設施和自有數據中心的混合，然後動態增加，即按季節或每天根據需求擴展到公共雲。
最後，基於多活數據中心的模型，我們可以預見員工及其相關成本會增加。如果數據中心的規模很大，我們可能會將員工安排居住在數據中心的附近，而不是依靠遠程工作。即使現場沒有員工，我們也可能需要不時地前往數據中心去驗證設置、與第三方合作提供商配合等。如果有一個數據中心是雲，那麼不太需要現場工作，因此可以潛在地緩解工作人員的增加。隨著服務器總數的增長，標準化的配置、部署工具和監控將有助於優化員工數量。當進行成本核算時，使用多個數據中心還有其他的好處，如確保數據中心接近最終客戶減少頁麵加載時間。下麵總結了多活數據中心實施的優點、缺點和架構考慮。
多活數據中心要考慮的因素
多活數據中心的優點包括：
比熱-冷數據中心配置有更高的可用性。
比熱-冷數據中心配置有更低的成本。
動態路由到附近的數據中心使客戶的響應時間更快。
在SaaS環境中推出產品有更大的靈活性。
在操作上比熱-冷數據中心配置有更大信心。
特別是當PaaS/IaaS /雲計算是整體解決方案的一部分時，利用閑置資源輕鬆快速地“按需”增長以應付突然出現的流量高峰。
多活數據中心的缺點包括：
更高的操作複雜度。
人員數量少許增加。
出差和網絡成本增加。
建立多活數據中心的架構考慮因素包括：
盡可能消除對狀態的需要。
盡可能減少動態調用，將客戶路由到最近的數據中心。
研究數據庫和狀態的複製技術。
規則13——利用雲
內容： 有目的地利用雲技術按需擴展。
場景： 當需求是臨時的、突增的、偶發的，響應時間不是產品的核心問題。要將其當成是“租用風險”——新產品對未來需求的不確定性，需要在快速改變或放棄投資間抉擇。公司從雙活向三活數據中心遷移時，雲可以作為第三數據中心。
用法：
采用第三方雲環境應對臨時需求，如季節性業務變動、大的批處理任務或者是測試中需要的QA環境。
當用戶請求超過某個峰值時，把應用設計成可以從第三方雲環境對外提供服務。擴展雲以應對高峰期，然後再把活躍的節點數減少到基本水平。
原因： 在雲環境中配置硬件需要幾分鍾，在自己的托管設施配置物理服務器需要幾天甚至幾周。當臨時使用時，雲的成本效益非常高。
要點： 在所有網站中利用虛擬化，並在雲中擴展以應付意想不到的突發需求。
雲計算是許多供應商提供的IaaS產品的一部分，例如亞馬遜、穀歌、IBM和微軟。供應商提供的雲主要有四個特征：按使用付費，按需要擴展，多租戶和虛擬化。第三方雲通常由許多運行係統管理（hypervisor）軟件的物理服務器組成，可以模擬較小的虛擬服務器。例如具有32GB內存、8個處理器的機器可以虛擬成4台機器，每台允許使用兩個處理器和8GB的內存。
客戶可以使用其中一台虛擬服務器，並且根據他們使用時間的長短收費。提供這些服務的每個供應商的定價不同，但通常使用虛擬服務器與購買物理服務器的盈虧平衡點大約是12個月。這意味著如果連續12個月每天24小時使用服務器，花費將超過采購物理服務器的成本。如果這些虛擬服務器可以基於需求啟動和停止，那就可能節省成本。因此，如果每天隻需要這個服務器工作六個小時完成批處理任務，那麼盈虧平衡點就會延長到48個月。
成本當然是決定是否使用雲的重要因素，雲的另外一個明顯優勢在於係統的準備通常隻需要幾分鍾，而物理硬件的係統準備則要用天或周來計算。公司購置額外硬件需要批準、訂購、接收、上架和加載，很容易花上幾個星期。在雲環境中，添加額外的服務器可以在幾分鍾內完成。此外，托管中心可能沒有空間來容納新的硬件，因此需要等待新機架的建設，這又會延遲交貨時間。
使用第三方雲環境的公司有兩種理想方式，就是當需求是臨時的或不一致的時候。臨時需求可以以夜間批處理作業的形式出現，需要幾個小時的大量計算資源或每個月為發布下一個版本會周期性地進行幾天QA測試。不一致的需求可以通過促銷或者網絡星期一的季節性的形式出現。
我們有一個客戶每晚都充分利用第三方雲環境來處理當天的數據，並把處理好的數據加載到數據倉庫。他們運行數百個虛擬實例，處理數據，然後關閉實例，確保隻支付自己所需要的計算資源量。另一個的客戶為他們的QA工程師提供虛擬實例。他們為要進行測試的軟件版本構建機器映像，然後當QA工程師需要一個新環境或刷新後的環境時，分配一個新的虛擬實例。因為使用虛擬實例作為QA環境，不會出現幾十個測試服務器處在大部分時間無人使用的狀態。我們的另一個客戶，當他們的需求超過一定程度時，使用雲環境來提供廣告服務。存儲的數據每隔幾分鍾同步一次，所以從雲平台提供的廣告服務幾乎和那些從托管設施服務的廣告一樣。這個特定的應用在處理數據同步時可能有輕微的延遲，因為在請求時投放廣告，即使不是絕對最好的廣告，仍然要比因無法擴展而沒有投放廣告好。
雲的另一個有吸引力的特性是它是“租賃風險”的理想選擇。如果貴公司是一個新的創業公司，不確定市場是否會對產品有需求。或者，貴公司是一個成熟的公司，有新產品計劃，想滿足現有市場或未來市場。也許你正在給現有產品添加功能並以現有解決方案單獨部署的形式提供服務，但不確定客戶是否願意采用該功能。這些案例都代表著風險——客戶不願意接受任何產品構建的風險。在這些例子中，租賃有風險產品的係統容量更有意義，因為如果有風險你可以輕鬆地拋棄它，而不需要消耗硬件的費用。
想想你的係統，哪些部分最適合雲環境？通常有些組件，諸如批量處理、測試環境或峰值容量，把它們放在雲環境更有意義。因為雲環境允許根據需要在非常短的時間範圍內實現按需擴展。
總結
雖然向上擴展是個適合中慢速增長公司的選擇，但那些增長速度持續超過摩爾定律的公司，將會在毫不知情的情況下，突然發現自己所擁有的高端昂貴的係統的計算能力遭遇極限。我們見過的幾乎所有影響大的服務故障都是同一個原因，產品自以為“了不起”。我們相信，提前做好擴展計劃，以便在需求出現時可以輕鬆地拆分係統是明智的。按照我們的規則擴展係統和數據中心，利用雲來處理意外需求，依靠廉價的商品化硬件，為超高速成長做好準備！
注釋
1. Manek Dubash, “Moore’s Law Is Dead, Says Gordon Moore,” TechWorld, April 13, 2005, www.techworld.com/news/operating-systems/moores-law-is-dead-says-gordonmoore-3576581/.
最後更新：2017-05-19 15:32:21