闲聊go开源微服务框架pitaya(1)

闲聊go开源微服务框架pitaya(1)

go极少有经典的框架,关于pitaya,摘自网上的一段话:

“基于golang,可伸缩的分布式游戏服务器框架

使用的技术比较先进 ETCD实现服务发现 NATS GRPC实现rpc可以docker部署， 国外公司TFG Co 开源项目.

地址：https://github.com/topfreegames/pitaya

Zooba(动物王者) appstroe排行很高的moba、吃鸡类游戏”

特别适用于房间类游戏,也可以用于多人社交游戏,比如有自己的房间,别人可以访问自己的房间,自己可以布置房间,有公共的广场一起玩,走元宇宙的思路.适合快速接入新框架,快速推进项目.本身开源框架肯定有些缺点,不过可以不断迭代优化.

关于消息转发,NATS 与GRPC二选一,框架默认使用nats消息队列.

Etcd,nats均可默认拉起即可.

网络通信支持tcp和websocket.

Pitaya的核心配置在config文件夹下的config.go文件里面.

消息处理主要在service文件夹的handler.go文件里面,包括握手,心跳,具体消息处理.具体消息又分为本地消息和远程需要被转发的消息.

消息转发依据route字符串: “服务器类型.组件名.函数名”,使用底层封装的app.rpc转发该类型所有服务器或者app.rpcto发送指定服.

App.rpcto 需要传入Route字符串加serverid

App.rpc 需要传入Route字符串即可

服务器类型分前端服务器和后端服务器,在例子中可以看到main函数中设置:

isFrontend := flag.Bool("frontend", true, "if server is frontend")

即可设置该进程为前端服务器,负责是接收玩家消息转发到后端服务器,也可以加入本地处理消息函数,比如登录验证.

下面这行代码即可设置为后端服务器:

isFrontend := flag.Bool("frontend", false, "if server is frontend")

后端服务器负责主要的游戏逻辑.

关于底层消息发送是使用自定义消息id还是使用route字符串,都可以,pitaya底层的消息id是原样返回的,如果使用框架的前端库会发现pitaya底层消息id是依次加1,发送到服务器的,如果前端不发route,可以将该id替换成自定义消息id,前端服务器收到该id后,再做底层映射.如果不使用消息id,使用route字符串做消息底层设计,好处是不用做id到route的映射,动态加入后端服或者更新后端服加入新消息,不用重启gate服,不影响现有服的运行,可动态加入.

真实收发的消息结构,是被封装了一层的:

type Message struct {
   Type       Type   // message type
   ID         uint   // unique id, zero while notify mode
   Route      string // route for locating service
   Data       []byte // payload
   compressed bool   // is message compressed
   Err        bool   // is an error message
}

上面data是整个消息,ID是框架底层的自增消息id,compressed设置成true即可压缩消息,减少带宽.type有四种类型:

Request:  "Request",
Notify:   "Notify",
Response: "Response",
Push:     "Push",

Request和notify是前端通知服务器的消息类型,服务器回复的response或push推送消息.

心跳机制,pitaya底层是服务器负责主动发送玩家,对于玩家掉线处理非常及时,也可以改为玩家主动发送心跳到服务器,关闭服务器的心跳主动推送那块,然后只负责定时检测玩家心跳是否超时,不断重置timer时间即可.

这篇好文章是转载于：学新通技术网