Featured image of post Game and Cloud Computing
Game Tech

Game and Cloud Computing

小朋友，你是否有很多問號

# 有緣千里來相會

技術來來說，Dota2、CS2、PUBG等被稱之爲會話類遊戲(Session-Based Game)，指至少兩名玩家會連接到同一個戰局/房間，並在有限的時間內完成競技。一場對局的開始與結束，對應一個session的生命週期。

那，打Dota2的小朋友，你是否有很多問號？
這四個狗艹的豬隊友是怎麼和哥們排到一塊的？
作爲一個知識分子，我的問題是 “我的四個隊友，和我的五個對手竟然能跨越時空相遇與一局遊戲，這背後到底是怎樣高深的技術”

  1. 用戶啓動Dota2，與對應的主界面(大廳)的網絡地址建立鏈接
  2. 點擊「開始DOTA」，這時一個合適的(自作聰明的)匹配機制，將旗鼓相當的對手與隊友聚在一塊
  3. 基於云原生技術，彈性地獲取相應的計算與網絡資源，爲這羣小可愛建立一場專屬的對局(session)
  4. 這場對局的玩家，能知曉此次對局的地址，並可直接連接到這一場對局
  5. 對局結束(一方世界樹倒塌)之後，對局信息會寫入相應存儲，玩家斷開鏈接，這場對局結束並被銷毀(計算與網絡資源被釋放)
  6. 同時另一場真正的會話類遊戲也正式開啓 本次對局玩家會連接到同一個聊天室，親切地對各自的家庭成員進行友好慰問 因爲不是本文重點故省略

# 遊戲何故要上雲

這個時代爆款遊戲現象成爲常態
以2024年爆款遊戲「幻獸帕魯」爲例，二月處於巔峯時期、遊戲人數突破200W，而後人氣迅速下滑，九月十月十一月在線人數只有3W，最近回暖到10+W

幻獸帕魯

如果遊戲公司採用建立IDC數據中心(Internet Data Center)來支持業務，不考慮建設週期較長、假設經過巨大的努力與資金投入，成功地建設了足量的計算與網絡資源服務了第一波玩家，風頭過後熱度巨幅下降造成的資源浪費成本損失是遊戲公司難以承受的。實際上新型遊戲的infra團隊，也無法提前做IDC capacity planning，bc遊戲的受歡迎程度無法預估

既然自建私有雲不科學，那看看公有雲

  1. 可以認爲GCP (Google Cloud Platform)，AWS(Amazon Web Services) 等廠商在各自的Regions裏擁有近乎無限的資源
  2. 雲廠商採用Pay-as-you-go(用多少算多少)的計費模式，成本可控
  3. 雲廠商網絡質量高，服務質量高，可用性高，穩定性高

理所當然的，遊戲業務乘上了雲的東風

# 雲可以，爲何雲原生

對於很多業務場景，傳統物理機/虛擬機技術已經是時代的眼淚，雲原生(Cloud Native)改造則是近些年的重頭戲

  1. 雲原生DevOps技術的不斷演進，軟件、運維工程師可以輕鬆地完成自動化部署與遊戲軟件的迭代
  2. Container容器技術、與Kubernetes容器編排系統，提供了彈性擴縮容能力，這正是遊戲行業應對高峰與低谷需求的關鍵解決方案之一。每一個遊戲戰局，對應一個k8s的Pod；匹配開始，戰局建立，Pod創建成功(對應創建的是Deployment、Service等，這裏略去)；對局結束，Pod銷毀同時計算資源釋放；在高峯期時集羣自動擴容，機器數量增多，來承載更多的Pod；低谷期集羣自動縮容，機器數量減少減少成本。
  3. 與傳統k8s網絡模型不同的是。各廠商利用雲原生CNI技術，提供各自的EIP(Elastic IP)方案 or 。Pod建立時會被分配一個Unique、彈性的Public IP，允許用戶直接訪問。在戰局結束後，Pod會被銷毀，Public IP也會被回收
  4. 雲原生技術的穩定性與高可用性

# 負載不一定均衡

# EIP 簡單而不簡單

正如上文所述，在會話類遊戲裏，一組玩家通過給定的Unique IP連接到一個固定的戰局，這個場景下不需要Load Balancer的Load Balancing能力，但需要Load Balancer做Traffic Routing的能力
簡單地說，一個用戶斷線重連N次，用戶並不是被負載均衡隨機地轉發到一個隨機的Pod上、從而加入一個隨機的戰局，而是重新連接被轉發到EIP對應的Pod、加入原先的戰局

爲Pod分配EIP聽起來非常直觀，但這其實反k8s常規，通常需要基於雲廠商提供的CNI網絡方案的配合，並非所有雲都支持此種能力

不過值得思考的是，這個功能，GCP、AWS這兩個行業top2都選擇不做。這些老牌頂級公有云提供的能力是，暴露出來的用於訪問instance的公網ip，實際都需要走一層NAT才能抵達instance，即實質上instance只有內網ip

# 四層接入

通常來說，四層的協議對Latency Sensitive的遊戲業務來說非常重要，用四層接入支持部分遊戲場景是常見的
給定一個四層加速服務的ip地址，這個ip地址可以分配給複數的LoadBalancer Type k8s Service，而每個k8s Service只基於各自指定的port來route traffic到指定的Pod(1 replica deployment)。當然，因爲port數量有限，如果戰場數目非常大，會需要更多的ip地址

例如基於AWS Global Accelerator的四層加速方案，Guidance for Game Server Hosting Using Agones and Open Match on Amazon EKS

L4 AGA Solution

# 七層接入

有很多採用了七層協議（如HTTP、WebSocket）的移動端遊戲，通過七層網關(Gateway)根據域名進行路徑匹配，將request轉發到對應的ingress->service->Pod上

# 天下沒有不散的筵席

寫累了，還在等公司可能解散的消息，不知道結尾該怎麼皮一下

comments powered by Disqus