遊戲雲間之一 : 彈性擴充

前言 

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

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

遊戲雲間之一：彈性擴充 

說到雲計算，大家聽到的最多的兩個優點就是：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，将其加入到負載均衡裝置後面，整個系統就無縫的擴容了。那麼就有同學會問，安裝配置似乎也沒那麼容易吧，如果是傳統的實體伺服器，确實，至少也得需要個CD光牒裝機吧，如果是雲主機呢？ 有鏡像就可以了，所謂鏡像就有點像在pc機上的iso或者虛拟機的vmdk檔案，将原有的game server 系統、軟體、配置整個做一個鏡像，在增加新的雲主機時，直接從鏡像建立，沒有任何安裝配置過程，新的game server分分鐘就啟動好了，如果通過api操作，算上啟動時間，整個過程10分鐘以内就可以搞定了，是不是很快？而随着雲計算平台的完善，彈性擴充将來也會變成一種服務，也就是說你隻需要設定政策，比如在所有伺服器負載超過90%時新增伺服器，當伺服器負載低于60%時，釋放雲主機，整個系統就變得非常靈活，不用再為突增的使用者量發愁了。 

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

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

大掌門這個遊戲大家都知道，使用者量和收入在業内遙遙領先，可以說這個遊戲的成功是離不開對于雲平台的利用，正是有了雲計算的各種彈性，才能很好地應對使用者量的激增，同時系統的穩定性也得到了保證。再舉一個小例子，就是遊戲更新伺服器的使用，更新伺服器隻有在遊戲釋出更新包時才需要，并且會在更新包釋出時會有一個非常巨大的通路量，如果隻有一台更新伺服器，用戶端更新的壓力吃不消，使用者體驗會變差，那麼在更新包釋出時，在雲平台上臨時部署多台更新伺服器，比如5台，随着使用者更新的完成，再逐個關閉更新伺服器，這些通過雲平台的彈性擴充很友善的就能實作。 

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