摘要：在技術上微信小游戲和小程序的區(qū)別是什么開發(fā)商在開發(fā)一款小游戲的時候通常會遇到什么問題怎么去規(guī)避和解決，來自騰訊游戲云資深架構師余國良，將會給我們帶來微信小游戲架構設計與開發(fā)方向。

轉(zhuǎn)載來源：云加社區(qū)
原作者：余國良

小游戲自發(fā)布以來，微信平臺上已經(jīng)出現(xiàn)了不少現(xiàn)象級的小游戲，包括跳一跳。在技術上微信小游戲和小程序的區(qū)別是什么？開發(fā)商在開發(fā)一款小游戲的時候通常會遇到什么問題？怎么去規(guī)避和解決，來自騰訊游戲云資深架構師余國良，將會給我們帶來微信小游戲架構設計與開發(fā)方向。

小游戲最大的特點是去中心化分發(fā)以及好友關系鏈的傳播。這里面會帶來很多機遇和挑戰(zhàn)，機遇就是有可能帶來爆款，挑戰(zhàn)是以往的經(jīng)驗可能就不適用了，包括技術上的。

那么微信小游戲的特點對我們的架構提出哪些要求？這里我列舉了兩個要點。

第一個是全區(qū)全副的需求。為了充分利用微信的社交網(wǎng)絡，要求游戲是全區(qū)全服的。第二個要求就是在線擴縮容的需求，因為任何一款游戲都可能成為爆款，在微信上有幾何式的增長，所以幾乎成為剛需。

我們看一個案例，這個案例是我們騰訊云上一個真實客戶的案例。它的小游戲在上線很短的時間內(nèi)從幾萬人飆升到200萬左右。這個客戶經(jīng)歷了什么？首先游戲上線之后，很快發(fā)現(xiàn)流量增速迅速，系統(tǒng)流量不夠了，這個時候我們可以通過云主機在線分配。但是第一個瓶頸出現(xiàn)了，當吞吐量達到上線的時候很難進行擴展，他們連夜進行了調(diào)整，將實際數(shù)量迅速擴展到幾十個。但是接下來另外一個瓶頸又出現(xiàn)了，他們用的數(shù)據(jù)庫也是單數(shù)據(jù)庫，同樣有擴展性的問題。這個問題可以通過改用集群版數(shù)據(jù)庫來解決。最終雖然所有的問題得到了解決，但是耽誤了時間也產(chǎn)生了損失，他們在線人數(shù)也出現(xiàn)了比較大的下滑。

通過這個案例我們想說明的是，我們希望小游戲的架構足夠輕，足夠小，但是重點問題也需要提前考慮，避免問題爆發(fā)的時候產(chǎn)生不必要的損失。

那么我們怎么樣來設計架構，小游戲?qū)ξ覀兲岢鲞@個要求，接下來我會從兩個層面來進行分析，首先是計算層面，再是存儲層面。

先看這么一個架構，我們不妨稱之為無狀態(tài)化的分層架構，簡單說就是按照節(jié)點的關系和按照架構關系分別進行銜接，然后下面這個節(jié)點靈活進行伸縮。

這個架構簡單使用應對一般的休閑性游戲也是夠用的，我們看一下它在騰訊云上的追加時間是什么樣的。國際客戶端通過CLB擴展平衡接入到后臺服務，我們經(jīng)過BGT高防對游戲進行保護，當出現(xiàn)流量的時候，高防服務可以對流量進行清洗然后回收到系統(tǒng)中。我們用不同的彈性制作主來承載不同的服務，通過內(nèi)網(wǎng)進行銜接以方便實現(xiàn)動態(tài)擴容。

這里用到一些騰訊云的產(chǎn)品我們做一些介紹，首先是CLB，騰訊的CLB單集群提供超過1.2億的最大連接數(shù)，輕松應對億級訪問量，單集群可處理峰值40GB/S的流量，每秒處理包量可達600萬。

第二個就是我們的彈性伸縮服務AS，彈性伸縮服務我們可以在不同的時期對集群的節(jié)點數(shù)量進行伸縮。我們的出發(fā)策略包括這么幾個，一個是定時策略、監(jiān)控告警策略、手動擴縮容策略。在騰訊云上，一千臺云主機的平均耗時是63秒，接入彈性伸縮服務以及流動的基礎能力，我們可以很方便的對服務進行快速動態(tài)的擴縮容。

第三個就是我們的BGT高防服務，在必要的時候我們可以通過BGT高防對于游戲進行保護，它的特點首先平臺擁有T級的防護帶寬，然后有精準的算法，在提供防護的同時我們可以最大程度保障網(wǎng)絡覆蓋質(zhì)量。

優(yōu)勢就是可靠性高，單節(jié)點鼓掌不影響整體可用性，以及好擴展和收縮。局限性，無狀態(tài)化要求對存儲層補寫數(shù)據(jù)。對于這個問題我們往往把比較高的對象緩存到節(jié)點內(nèi)存中，這對LB就提出一些要求。因為擴展中需要知道發(fā)送給某個對象的發(fā)送到哪個節(jié)點，它是要建立對象到節(jié)點的流動性關系，顯然通用的LB是沒有辦法做到這一點的。

另外一個問題在這個架構中同時節(jié)點沒有辦法發(fā)送請求，但是對于游戲來說，我們很多時候希望同時的節(jié)點之間發(fā)送請求。比如說我們向好友發(fā)送組隊邀請的時候，好友的對象和我的對象不在同一個節(jié)點，那么就需要將請求發(fā)送到好友的節(jié)點，然后再轉(zhuǎn)發(fā)到好友的客戶端。

但是對于無狀態(tài)化分層架構來說往往就需要通過共享數(shù)據(jù)，存在實時性和性能損耗的問題。為了解決這兩個問題，我們看一下星型的架構。

不同節(jié)點之間通過router進行剖析，實現(xiàn)節(jié)點之間共融的儀器。比如說A節(jié)點中的Player1對象要向發(fā)送B節(jié)點中的Play2對象發(fā)送請求、邀請，可以將消息發(fā)送到router，router再轉(zhuǎn)發(fā)到大節(jié)點處理之后再發(fā)送到朋友客戶端。在這個結構中，所有的節(jié)點都是對等的關系，中間的router可以實現(xiàn)互通，它是比較靈活。但是它有一個明顯的問題，router是一個單點，有容縮小和可擴展性。建立（英）可以實現(xiàn)主備的自動切換，主節(jié)點不行的時候可以切換到節(jié)點。他們之間的連接，我們可以把多結構連接在一起實現(xiàn)架構的擴展。比如說Player1在（英）發(fā)送A節(jié)點，Player發(fā)到B節(jié)點。當Player1向Player額2發(fā)送組隊邀請的時候，可以將消息先發(fā)送到router1，router1再轉(zhuǎn)發(fā)到router2，最終到達B節(jié)點。router能夠?qū)⑾l(fā)到對象，它就要保持全局的這樣一個裝。

我們看一下router做了哪些事情？收斂鏈接，簡化內(nèi)部通信管理，建立通用的對象陸游機制，簡化游戲開發(fā)。第三通過router我們也可以實現(xiàn)負載均衡和廣播，router具有通用性，可以作為通用的游戲界面。

在擴展性方面，我們可以在兩個層面進行擴展，比如說可以發(fā)現(xiàn)節(jié)點不夠的時候可以進行添加，分散相應的router，然后加入到系統(tǒng)中來。當一個達到極限的時候，我們可以通過副機來進一步做擴展，添加新的。假設我們有0和1，需要添加2的時候這個流程可以是這樣的。我們先對2進行部署，當2起來的時候，router1和router2可以發(fā)現(xiàn)新節(jié)點，并且建立到它的連接。連接之后router2會向router1或者router0并且將自己的信息同步給router1和router0，這樣就建立了。當play2登錄到router2的時候，router2會將信息同步給router2和router0，這是架構的擴展過程。

這個圖是擴展的信息結構在騰訊云的實踐，像比較高的游戲，比如說坦克大戰(zhàn)游戲我們實行多點布局，比如說華南的玩家可以加入到華東，廣州的UPC和上海的UPC可以實現(xiàn)內(nèi)網(wǎng)連接。

下面我們看一下存儲層的設計，我們的目標是建立一個大存儲層以滿足動態(tài)擴容的問題。我們要滿足數(shù)據(jù)庫水平擴展的問題，如果自己做的話有三種方法。第一種基于增量區(qū)間的分配，它的由點是可以實現(xiàn)動態(tài)擴容，但是存在性能熱點的問題。因為永遠都是訪問量最大，而老分片隨著流失出現(xiàn)性能限制的情況；第二種方法，根據(jù)ID的閃電池分散到不同的分片，沒有性能熱點的問題，但是加新的節(jié)點的時候，往往對數(shù)據(jù)進行單切，比較難以實現(xiàn)快速自動擴容。第三種方法就是將兩者結合，可以同時解決兩個問題，需要增加中間的數(shù)據(jù)路由。

為了簡化大存儲的設計，我們可以用一些分布式數(shù)據(jù)庫產(chǎn)品，比如說騰訊云的DCDB，它的原理是通過增加中間的代理層，到多個物理感，像復雜性完全封裝在代理層。

這兩個圖是我們對DCDB做性能測試，第一個圖是單分片對比MYSQL的性能，隨著CPU的核和現(xiàn)存數(shù)的增加呈線性增長。DCDB支持新發(fā)現(xiàn)的擴容和現(xiàn)有的擴容。擴容池系統(tǒng)會自動進行搬遷并且切換相應的流量，可以做到對業(yè)務層進行感知。我要做的只要在頁面中點擊幾下按鈕。

第二個產(chǎn)品是TCaplus，特點有三個支持Protobuf接口訪問，接口友好，適合游戲開發(fā)，第二個，將Cache與硬盤結合，第三村塾空間無上線，單表最大支持sotb。TCaplus目前在騰訊內(nèi)部得到最廣泛的應用，數(shù)百款游戲都是以TCaplus作為主數(shù)據(jù)庫，其中包括王者榮耀、絕地求生等游戲。

想要獲取原文PPT及了解更多小程序開發(fā)相關內(nèi)容，歡迎微信掃描下方二維碼關注「微信極客WeGeek」公眾號，共筑微信生態(tài)。