雲原生專案實踐DevOps(GitOps)+K8S+BPF+SRE，從0到1使用Golang開發生產級麻將遊戲伺服器—第3篇

為少發表於2021-02-07
devGitK8SGolang遊戲伺服器

通過伺服器日誌和客戶端抓包瞭解遊客（Guest）登入流程

系列文章

  1. 雲原生專案實踐DevOps(GitOps)+K8S+BPF+SRE，從0到1使用Golang開發生產級麻將遊戲伺服器—第1篇
  2. 雲原生專案實踐 DevOps(GitOps)+K8S+BPF+SRE，從 0 到 1 使用 Golang 開發生產級麻將遊戲伺服器—第2篇

介紹

這將是一個完整的，完全踐行 DevOps/GitOps 與 Kubernetes 上雲流程的 Golang 遊戲伺服器開發的系列教程。

這個系列教程是對開源專案 Nanoserver 的完整拆解，旨在幫助大家快速上手 Golang（遊戲）伺服器後端開發。通過實踐去理解 Golang 開發的精髓 —— Share memory by communication(通過通訊共享記憶體)。

同時這個專案可能還會涉及到 Linux 效能調優（BPF 相關的工具）和系統保障（SRE）的相關的工作。

Step-By-Step 開發 Mahjong Server

  • 單體架構理解 Mahjong Server 業務 -> Nano Distributed Game Server（分散式） + 微服務 改造。
  • Demo：go-mahjong-server

遊客登入業務分析

遊客(Guest)登入 這裡主要還是用於開發與除錯程式。

回顧一下 Nano 框架

關於 Nano Game Server 的快速上手大家可以參看我之前寫的 -> 5 分鐘上手 Nano 遊戲伺服器框架

Nano 術語

  • 元件(Component)：nano 應用的功能就是由一些鬆散耦合的 Component 組成的，每個 Component 完成一些功能。
  • Handler：它定義在 Component 內的方法，用來處理具體的業務邏輯。
  • 路由(Route)：用來標識一個具體服務 或者客戶端接受服務端推送訊息的位置。
  • 會話(Session)：客戶端連線伺服器後, 建立一個會話儲存連線期間一些上下文資訊。連線斷開後釋放。
  • 組(Group)：Group 可以看作是一個 Session 的容器，主要用於需要廣播推送訊息的場景。
  • 請求(Request), 響應(Response), 通知(Notify), 推送(Push)：Nano 中四種訊息型別。

Nano 元件的生命週期

type DemoComponent struct{}

func (c *DemoComponent) Init()           {}
func (c *DemoComponent) AfterInit()      {}
func (c *DemoComponent) BeforeShutdown() {}
func (c *DemoComponent) Shutdown()       {}
  • Init：元件初始化時將被呼叫。
  • AfterInit：元件初始化完成後將被呼叫。
  • BeforeShutdown：元件銷燬之前將被呼叫。
  • Shutdown：元件銷燬時將被呼叫。

整個元件的生命週期看起來非常的清晰。

為 Nano Game Server 開啟 Debug 模式

internal/game/game.go，我加入了 nano.WithDebugMode()

nano.Listen(addr,
  nano.WithPipeline(pip),
  nano.WithHeartbeatInterval(time.Duration(heartbeat)*time.Second),
  nano.WithLogger(log.WithField("component", "nano")),
  nano.WithSerializer(json.NewSerializer()),
  nano.WithComponents(comps),
  nano.WithDebugMode(),
)

啟動遊戲伺服器並檢視其啟動日誌

這個主要是瞭解 Nano Server 啟動的時候都註冊了哪些遊戲?業務邏輯。

日誌 -> The current server running in singleton mode：這句話告訴我們 Nano 伺服器當前啟動模式是單體。Nano 也可以作為分散式系統執行，他內建了一個小型的分散式系統設計（可以學習下它的架構，入門分散式系統開發）。

通過日誌我們清晰的看到，Nano 註冊了三個元件 Manager，DeskManager，ClubManager，用來管理所有的遊戲?業務邏輯。

Manager(Handlers)：

  • Manager.CheckOrder
  • Manager.Login

DeskManager(Handlers)：

  • DeskManager.DissolveStatus
  • DeskManager.QiPaiFinished
  • DeskManager.VoiceMessage
  • DeskManager.ClientInitCompleted
  • DeskManager.Exit
  • DeskManager.OpChoose
  • DeskManager.Ready
  • DeskManager.UnCompleteDesk
  • DeskManager.DingQue
  • DeskManager.Dissolve
  • DeskManager.Join
  • DeskManager.ReJoin
  • DeskManager.RecordingVoice
  • DeskManager.Resume
  • DeskManager.CreateDesk
  • DeskManager.Pause
  • DeskManager.ReConnect
  • DeskManager.ReEnter

ClubManager(Handlers):

  • ClubManager.ApplyClub

分析 Nano Debug 日誌和 Charles 捕獲

如何代理 API 到本地 Nanoserver 和以及捕獲 http 請求？ -> 大家可以參看系列的第一篇

Charles API 捕獲

我們清晰的看到這一次的操作呼叫了兩個 API：

  1. /v1/user/login/query -> 查詢是否已啟用遊客(Guest)登入
POST http://192.168.31.125:12307/v1/user/login/query HTTP/1.1
content-type: application/json

{
    "channelId": "konglai",
    "appId": "konglai"
}
  1. /v1/user/login/guest -> 進行遊客登入
POST http://192.168.31.125:12307/v1/user/login/guest HTTP/1.1
content-type: application/json

{
    "channelId": "konglai",
    "appId": "konglai",
    "imei": "c0a4ce912c48a3d0b17b59e6b97f1dca"
}

伺服器 Debug 日誌輸出

我們看到了 Nano Server 輸出的如下關鍵資訊：

  1. Message={ Request Manager.Login }
  2. Message={ Request DeskManger.UnCompleteDesk}

客戶端根據 Web API(v1/user/login/guest) 返回的遊戲伺服器地址 192.168.31.125:33251，進行了 socket 連線並與 Nano Game Server 進行了通訊。

關於 Nano 協議快速入門，大家可檢視： 3分鐘快速理解 Nano 通訊協議（內含記憶腦圖）

最後，一句話描述業務流程

使用者單擊登入按鈕 -> 查詢伺服器是否啟用遊客(Guest)登入 -> （如果啟用？）進行遊客登入 -> 獲取遊戲伺服器地址 -> 連線遊戲伺服器 -> (連線成功？)進入遊戲大廳

關於登入流程的詳細業務和程式碼邏輯，我們下篇再詳細討論。

我是為少
微信：uuhells123
公眾號：黑客下午茶

相關文章