原創 遊戲雲間之一 彈性擴充套件

2021-09-23 22:50:14 字數 2877 閱讀 4310

文/肖凱

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

遊戲雲間之一:彈性擴充套件

說到雲計算,大家聽到的最多的兩個優點就是:

1. 成本優勢 2. 靈活或者說叫彈性擴充套件。

成本問題涉及到的因素比較多,我們暫時不去討論,先談談雲的靈活性(彈性擴充套件)。那麼什麼是彈性擴充套件呢?有點像我們用自來水,用多少就開多少,按使用量付錢;而不是像以前,吃水要先計算人數,然後做規劃去挖幾口井打水。

對於遊戲開發和運營來說,雲計算就像自來水,在遊戲生命週期的不同階段對於網路、計算、儲存等資源的需求都不一樣而且是頻發變化的。在端遊時代,這些都可以基於經驗被準確估算,包括使用者量的曲線都是可以被**的,但是到移動網際網路時代呢?

遊戲領域的特點是:快速開發,使用者爆發量大,生命周期短。

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

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

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

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

由於遊戲程式的邏輯是一樣的,不管是分割槽還是分服,無非是資料不同。那麼目前最常見的做法就是利用負載均衡裝置來實現彈性擴充套件。負載均衡是做什麼用的呢?就是對外表現出同乙個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臺,隨著使用者公升級的完成,再逐個關閉更新伺服器,這些通過雲平台的彈性擴充套件很方便的就能實現。

因此從遊戲開發、推廣、穩定器、衰落等各個階段,

雲平台可以像自來水一樣即開即用,按需使用,按用量支付費用

。而能也能保證在遊戲開發和運營的各個階段的效率和資源利用率都能得到極大的提高。

遊戲雲間之五 遊戲架構

說起架構,分為兩塊,乙個是軟體層次的 架構,另外乙個是硬體層次的系統架構。軟體層次的,模組劃分 重構及業務層的架構為主。系統層次的,以網路 部署 伺服器集群為主。軟體層次的架構,在於前期 研發。硬體層次的系統架構,在於後期的伺服器部署上線。今天的內容主要偏向於遊戲領域的系統架構。談起系統架構,無外乎...

遊戲雲間之二 網路環境問題

我還記得幾年前玩網遊的時候,很多遊戲登入前先要選服 網通服 電信服或者是雙線服。之所以造成這個現象是由於歷史政策限制導致,不同運營商之間的互聯互通不但成本高,而且速度慢,跨運營商的網路質量極不穩定。所以很多遊戲為了有更好的使用者體驗和節省成本,按照運營商網路分伺服器,這麼做確實可以保證網速,但問題來...

原創 iPhone遊戲開發入門

最近這幾個月一直在做android和iphone的應用開發,雖然做的時間不長,但覺得還是相當有意思的!總體乙個感覺,如果只是做應用,如最近在做的釣魚管理,聊天軟體啊等等,其實還是挺簡單的,無外乎就是對各種控制項及手機硬體功能 如陀螺儀,指南針等 的使用。只要掌握了如何使用控制項,如何使用手機硬體功能...