介绍
这将是一个完整的，完全践行 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：
/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" }
/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 输出的如下关键信息：
Message={ Request Manager.Login }Message={ Request DeskManger.UnCompleteDesk}
客户端根据 Web API(v1/user/login/guest) 返回的游戏服务器地址 192.168.31.125:33251，进行了 socket 连接并与 Nano Game Server 进行了通讯。
关于 Nano 协议快速入门，大家可查看： 3分钟快速理解 Nano 通信协议（内含记忆脑图）
最后，一句话描述业务流程
用户单击登录按钮 -> 查询服务器是否启用游客(Guest)登录 -> （如果启用？）进行游客登录 -> 获取游戏服务器地址 -> 连接游戏服务器 -> (连接成功？)进入游戏大厅
关于登录流程的详细业务和代码逻辑，我们下篇再详细讨论。
