云原生项目实践DevOps(GitOps)+K8S+BPF+SRE，从0到1使用Golang开发生产级麻将游戏服务器—第3篇

通过服务器日志和客户端抓包了解游客（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
公众号：黑客下午茶
posted @ 2021-02-07 11:55  为少  阅读(1303)  评论(1)  编辑  收藏  举报