架构设计：实现负责消息转发、推送的网关服务

本文首发在这里
请先看完负责网络、定时、坐下、站起、重连等，支持多类游戏的无锁房间

主要实现了接受客户端附带JWT的WebSocket连接即订阅，此协程阻塞读客户端消息保持长连接，这样系统将在需要时可以向指定用户编号推送消息（待实现），在客户端请求进入房间时创建新协程gRPC双向流连接并阻塞读游戏服务端消息

消息流大致如下

• mq -> gate_server -> client
• client <-> gate_server <-> game_server

服务端

cd ~/go/src/github.com/panshiqu/server/game_server
go run main.go

# k8s容器化借助kube-dns以前暂时手动修改host
sudo sh -c 'echo "127.0.0.1 dice" >> /etc/hosts'

# JWT_KEY base64 decode: default_key
cd ~/go/src/github.com/panshiqu/server/gate_server
JWT_KEY=ZGVmYXVsdF9rZXk= go run main.go

客户端

# 以下导入可以二选一，它们的代码基本可以对比
# "github.com/panshiqu/server/gate_server/client" // WebSocket gate_server
# "github.com/panshiqu/server/game_server/client" // gRPC stream game_server
cd ~/go/src/github.com/panshiqu/server/game_server/game/dice/client

# JWT header base64 decode: {"alg":"HS256","typ":"JWT"}
# JWT payload base64 decode: {"id":1}
go run main.go -token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6MX0.teQ2o406CHCk91dbp2D3p6ErkfIOELXlyKTkgMiPUT8
# 输入 sitdown、standup 等

简单说明

• 重启几乎没有代价
• 优雅停服并非必要，但已实现
• 会话的成员变量有意没有加锁，后果可控就行
• 网关连接游戏时会尝试从Redis中获取在线用户所在的服务进行重连（待实现）
• 同一个网关可以接受同一用户的多个连接即订阅，与不限制同时连接到不同网关的表象保持一致
• 原本设想的是多个客户端共享网关与游戏之间的一条连接，避免自写服务发现暂时每个客户端按需新建
• 阻塞读游戏协程中的错误均会转成pb.ErrorResponse并尝试向客户端推送pb.Cmd_Error
• 网关处理异常可采用断开客户端连接的方式，触发客户端重连进而快速恢复

关于web_server（待实现）

• HTTP、RESTful API、无状态，负责充值、签到、抽奖、排行榜等业务逻辑
• 若牵涉到的数据缓存在游戏内，则游戏来处理或通知游戏变化量
• 敬请期待实现后再来阐述更多细节

写在最后

• 本文主要内容基本均以注释的形式写入代码
• 基于此刻源码成文，代码大概率会继续完善，也会尽量同步更新此文，但话不绝对