1 从服务器是否需要主动推送消息到客户端，我们可以简单分为http服务和tcp/websocket服务。（虽然大多数时候是混合使用），后面一篇会讲长连服务架构。
对于http服务游戏，注定是延迟较高的。单个消息处理时间为RTT+业务处理时间。
http3（quick），http2和http1在延迟上基本不会有区别，毕竟http本质上是一个文本协议，是为了获取资源设计的。
较高延迟，无法推送，玩家之间弱交互。能选择的游戏类型就较少。比如放置类，挂机类等。本质上就是一个单机游戏+商业化的外壳。（可以http轮询，实现弱交互）。
优势：
开发快速，postman就可以支持大多数测试。功能测试友好。golang框架可选beego，gin等。
api服务比长连服务的社区基础更好。现成的技术方案多。在游戏运营迭代更新阶段。我们更需要关注的是如何让项目稳定运行，提供数据收集分析平台给运营等。
bug是一定会出现的，我们需要做的是降低出现bug的风险。
需要网关来做细粒度业务的拆分。可选的有云服务商提供的网关（比如某里的alb）。或者部署kong，zuul等。
gin内部集成熔断和限流。（提供有限的服务比不提供服务要好很多，在突发情况下，甚至可以考虑放弃部分没有价值的用户）
用户数量达到一定量级，或者灰度发布需求等，需要搭建负载均衡（云厂商也有）。
日志可选elk。
服务监控以及细粒度的业务监控可选prometheus。
动态实时配置可选nacos。
服务拆分到一定数量，层级2层以上可选go-micro重建整个服务，或者基于gin等集合插件，go-kit是个不错的插件库；同时需要整个数据流的监控，可选zipkin，jeager等。
附git链接：
基础服务：
GitHub - gin-gonic/gin: Gin is a HTTP web framework written in Go (Golang). It features a Martini-like API with much better performance -- up to 40 times faster. If you need smashing performance, get yourself some Gin.Gin is a HTTP web framework written in Go (Golang). It features a Martini-like API with much better performance -- up to 40 times faster. If you need smashing performance, get yourself some Gin. - GitHub - gin-gonic/gin: Gin is a HTTP web framework written in Go (Golang). It features a Martini-like API with much better performance -- up to 40 times faster. If you need smashing performance, get yourself some Gin.
https://github.com/gin-gonic/ginhttps://github.com/beego/beego
https://github.com/beego/beego
微服务：
需要的一些熔断限流器客户端服务均衡请求追踪等，可以从micro里面直接找到
https://github.com/asim/go-microhttps://github.com/asim/go-micro日志（格式化j的日志更好处理）：
https://github.com/uber-go/zaphttps://github.com/uber-go/zap
附：（完整架构图）
