遊戲對伺服器的彈性擴展需求——遊戲雲間系列一

遊戲對伺服器的彈性擴展需求——遊戲雲間系列一

前言

雲計算從幾年前的概念炒作到今天各種公私有雲的蓬勃發展，越來越多的使用者開始接觸並嘗試將雲作為業務運營的載體，已有不少敢於嘗鮮的使用者體驗了雲計算所帶來的靈活性和成本優勢。 我自己也從最初對雲的模糊認識到嘗鮮，再到大規模的使用雲平臺，有很多感觸，雲計算技術和平臺目前也處於逐步完善和穩定中，因此把一些見解寫出來供參考，同時也想和大家一起探討如何利用雲計算技術更好的提升遊戲開發和運營品質。

對於遊戲行業來說，私有雲由於其封閉性且目前並沒有成熟的標準化方案，除了個別高大上的端游開發或者運營商可能會用，對大多數遊戲公司並不適用，拋開成本和技術門檻不講，就目前互聯網時代的遊戲行業豐富多變的特點， 私有雲有著很大的局限性。 其實不論什麼雲，在底層技術上是相似的，但是由於國內對於資料中心和網路方面的政策限制，也導致了私有雲的種種局限性。 本系列將從開發到運維等多個角度探討雲計算技術特別是公有雲平臺的特點以及一些技術架構。 歡迎大家踴躍討論，分享遊戲領域的雲技術經驗！

遊戲雲間之一：彈性擴展

說到雲計算，大家聽到的最多的兩個優點就是：1. 成本優勢 2. 靈活或者說叫彈性擴展。

成本問題涉及到的因素比較多，我們暫時不去討論，先談談雲的靈活性(彈性擴展)。 那麼什麼是彈性擴展呢？ 有點像我們用自來水，用多少就開多少，按使用量付錢；而不是像以前，吃水要先計算人數，然後做規劃去挖幾口井打水。 對於遊戲開發和運營來說，雲計算就像自來水，在遊戲生命週期的不同階段對於網路、計算、存儲等資源的需求都不一樣而且是頻發變化的。 在端游時代，這些都可以基於經驗被準確估算，包括使用者量的曲線都是可以被預測的，但是到移動互聯網時代呢？ 遊戲領域的特點是：快速開發，使用者爆發量大，生命週期短。

比如去年流行的瘋狂猜圖遊戲，剛上線就以迅雷不及掩耳之勢瘋狂傳播，每天新增使用者數超過30萬，使用者量的爆發是難以預料的。 而現在很多遊戲的開發時間也很短，特別是頁游、手游等，短則幾個禮拜，長也不過幾個月，由於國內玩家的特點以及遊戲的可玩性等因素，很多遊戲的生命週期都基本在1-2年左右，使用者量的爆發也基本是在遊戲面市的最初一段時間裡， 所以整個遊戲IT系統的架構都是從突增的爆發到平穩再到逐漸縮減。

想想一下沒有雲計算的傳統做法吧，我們要先做使用者數預測，然後估算同時線上的使用者量及IT資源消耗情況，隨著遊戲推廣的廣告宣傳，使用者數迅速增加至100萬，沒有問題，因為兩個月前我們已經把遊戲伺服器部署好了。 可是移動互聯網時代的遊戲使用者數預測是很難的，除了遊戲本身的可玩性，很多外部因素也會對使用者數有較大影響，比如流行趨勢、國家政策、公共事件等。 比如前一段流行的flappy bird遊戲，開發時我想沒有人會想到這個遊戲會火到爆棚，還好這只是個單機遊戲，如果換做是網游，那麼傳統的預先部署伺服器的做法可能面臨狀況就是，要麼是使用者數不足而導致IT資源閒置， 要麼是使用者數激增導致短時間（一兩周內）伺服器已經滿負荷運轉，即便是遊戲運營反應很快，馬上去採購，下單，部署，調試，至少兩周時間過去了，而這兩周正是決定遊戲命運的關鍵時刻，在這兩周內的任何宕機、 訪問延遲等事件都會導致使用者的流失，並且再也不會回來。

那有了雲計算會是什麼樣呢？

在開發階段，只需購買幾台夠用的低配置雲主機即可；在內測和公測階段，根據雲主機負載適量增加新的伺服器；在遊戲正式上線的推廣階段，可以隨時根據使用者數的增長和伺服器負載隨時調配資源，根據激增的使用者量，按需擴充機器 ；而在遊戲生命週期的後半段，隨著使用者量的下降，逐漸關閉一些雲主機，確保在用的雲主機一直保持在忙碌狀態；甚至可以做到在玩遊戲的高峰期比如晚上7-12點，或者城戰等大訪問量時間段，增加雲主機或者頻寬量， 而在訪問量低的時間段減少相應資源。

這種想法是不是很美好？ 確實很好，但是，硬體或者說虛擬IT資源是可以彈性擴展的，遊戲軟體本身如何實現彈性擴展呢？ 怎麼能保證增加伺服器後，遊戲軟體也可以隨之擴展，並且擴容必須是線上的，對已有系統不能有任何影響呢？

自行開發分散式的遊戲軟體架構是一種方式，但是技術門檻太高，並且想要做的穩定和完善還是需要不小的投入。

由於遊戲程式的邏輯是一樣的，不管是分區還是分服，無非是資料不同。 那麼目前最常見的做法就是利用負載均衡設備來實現彈性擴展。 負載均衡是做什麼用的呢？ 就是對外表現出同一個IP或者訪問入口，對內實際上對應多台伺服器。 負載均衡設備有這麼幾個作用：1. 輪詢後端的伺服器的負載，將請求分發至合理的伺服器上，確保伺服器的load是平均的   2. 確保業務連續性，在某一個或者幾個伺服器發生故障時，請求只會被轉發至健康的伺服器，這一點也可以用來避免game伺服器的單點失敗或者實現災備功能。

那麼負載均衡要怎麼實現呢，可以利用開源軟體自行實現，如果是使用雲服務，那麼國外如amazon的ELB，國內如阿裡雲的SLB等，有興趣的可以google之.

有了負載均衡，就有了彈性擴展的基礎，既然負載均衡後的game server都是對等的，那麼在訪問量增加的情況下，安裝配置好一台新的game server，將其加入到負載均衡設備後面，整個系統就無縫的擴容了。 那麼就有同學會問，安裝配置似乎也沒那麼容易吧，如果是傳統的物理伺服器，確實，至少也得需要個光碟裝機吧，如果是雲主機呢？ 有鏡像就可以了，所謂鏡像就有點像在pc機上的iso或者虛擬機器的vmdk檔，將原有的game server 系統、軟體、配置整個做一個鏡像，在增加新的雲主機時，直接從鏡像創建，沒有任何安裝配置過程，新的game server分分鐘就啟動好了，如果通過API操作，算上啟動時間，整個過程10分鐘以內就可以搞定了，是不是很快？ 而隨著雲計算平臺的完善，彈性擴展將來也會變成一種服務，也就是說你只需要設定策略，比如在所有伺服器負載超過90%時新增伺服器，當伺服器負載低於60%時，釋放雲主機，整個系統就變得非常靈活，不用再為突增的使用者量發愁了。

可能就會有同學問，負載均衡後的game server確實解決了計算層面的彈性，那麼資料怎麼辦，如果我的資料容量或者訪問出現瓶頸了如何彈性擴展？ 說到資料，我們就先講下存儲的問題，雲存儲早已是大家耳熟能詳的，存儲的雲化是比較容易做的，因此存儲這一層的虛擬化早已完成，很多雲存儲宣稱空間無限，當然存儲速度也是很重要的衡量因素。 那麼資料庫呢，如何避免單一資料庫伺服器造成的瓶頸，熟悉mysql的同學應該都知道分庫分表，在大規模資料量和訪問量的資料庫中，按照一定的規則將資料庫壓力分攤至多個資料庫實例，比如按使用者id等等，網上類似的資料很多， 目前分庫分表的工作還是需要自己規劃。 據瞭解有的雲平臺已經準備推出分散式的資料庫服務，也就是說對外(應用層）看到的是一個資料庫，實際上底層對應多個資料庫實例。 分庫分表、負載分攤等都由雲系統自動完成。 如果這項服務推出，那資料層面的彈性話將變得非常容易，只需根據遊戲資料量或訪問量增減則自動調整資料庫規模，這一切都會變得非常靈活和智慧。 這個功能將是非常激動人心的，讓我們拭目以待看哪個雲平臺能率先推出這種分散式資料庫服務。

再來簡單說說頻寬問題(後續會進一步討論），很多遊戲運營的苦惱是頻寬，對很多遊戲來說頻寬是重中之重。 既然是雲，頻寬的彈性增減就更是必不可少了，而雲平臺通過API可以立即調整頻寬，這比IDC託管或者自建伺服器頻寬擴容方便的太多，雲平臺的頻寬完全可以自由掌控，甚至自動化。

大掌門這個遊戲大家都知道，使用者量和收入在業內遙遙領先，可以說這個遊戲的成功是離不開對於雲平臺的利用，正是有了雲計算的各種彈性，才能很好地應對使用者量的激增，同時系統的穩定性也得到了保證。 再舉一個小例子，就是遊戲補救伺服器的使用，補救伺服器只有在遊戲發佈升級包時才需要，並且會在升級包發佈時會有一個非常巨大的訪問量，如果只有一台補救伺服器，用戶端更新的壓力吃不消，使用者體驗會變差，那麼在升級包發佈時， 在雲平臺上臨時部署多台補救伺服器，比如5台，隨著使用者升級的完成，再逐個關閉補救伺服器，這些通過雲平臺的彈性擴展很方便的就能實現。

因此從遊戲開發、推廣、穩定器、衰落等各個階段，雲平臺可以像自來水一樣即開即用，按需使用，按用量支付費用。 而能也能保證在遊戲開發和運營的各個階段的效率和資源利用率都能得到極大的提高。

原創作者：架構雲肖凱 文章來自：HTTP://game.aliyun.com 轉發請標明出處