大部分都是吐槽哈哈哈哈哈，那我说点有用的吧

目前的项目是卡牌，功能偏单机，只有部分功能会有玩家交互。根据这种游戏的特点，客户端 Unity 服务端 Go ，Http API+json 进行主要功能逻辑的通讯，外加一条 websocket 做服务器主动推送消息（跑马灯之类的），聊天接第三方 SDK 。数据库 MongoDB ，Redis 做缓存。服务间通讯用 GRPC 。服务器使用 docker 镜像，线上 k8s 无状态集群。

这个架构的好处是能充分利用云服提供的各项服务：无状态服务保证你负载均衡路由到任何一个节点都可以正常运行，并且干掉了传统游戏服务器的网关；使用 Mongo 可以不用过多考虑 MySQL 之类关系数据库的建表问题，随时加功能随时扩展字段； http+json 的组合让客户端自己写服务器逻辑，不用考虑 protobuf 的协议转换；我在 gin 当中封装了数据库操作使得这帮客户端不用操心 find 、insert 等，只处理 if else 就够了，对玩家数据的修改会统一做脏数据检测存盘，这样开发效率极高也没有前后端扯皮问题；日志不存盘，直接让云服去容器控制台捞就好了。

总的原则就是降低人员成本，无论是运维人员还是开发人员。运维只需要把内网测试完毕的镜像推到云上让 k8s 滚动更新，对玩家来说就是永不停服。负载均衡会把流量路由到合适的节点。分片 Mongo 性能也能保证，热点数据丢 Redis 缓存。开发人员只需要招几个 Unity 客户端，写客户端逻辑的时候顺手就把服务端写了，反正都是 if else 。当然这套架构服务端如果换 C#可能会更方便，但我个人比较喜欢 Go 所以就没和客户端统一语言。