gRPC 提供连接复用等对小请求优化的功能，为什么绝大部分抽卡游戏都是用普通 HTTP API 而不是 gRPC？目前我还没见过一款用 gRPC 的游戏

没用性能问题别强上新东西，ws 够用

可能不是瓶颈吧...游戏内资源文件才是大头

你先把体量做到原神的级别，再来考虑优化的事情

掉包率是游戏传输最大的问题，gRPG 也是 tcp ，解决不了问题。行业内解决方案就是用 kcp+udp 重发包来解决。

你看原神，鸣潮啊，都是用这个方案来处理的。

协议的话无所谓，一般我看用 protobuf 也挺多的。

因为很多游戏后端用的并不是 go 啊。 还有一些后端是多语言异构的，你搞 grpc ，等于说把路走窄了

搞个中台应该还可以，你可能在找一个腾讯曾经的弃案

https://github.com/tencentyun/qcloud-documents/blob/master/product/%E6%B8%B8%E6%88%8F%E6%9C%8D%E5%8A%A1/%E6%B8%B8%E6%88%8F%E6%9C%8D%E5%8A%A1%E5%99%A8%E5%BC%95%E6%93%8E/%E5%BC%80%E5%8F%91%E6%8C%87%E5%8D%97/%E6%95%B4%E4%BD%93%E6%B5%81%E7%A8%8B.md

按每个请求 100ms 算，每个 HTTP 1.1 的长连接也能做到 10rps ，这会成为卡牌类游戏的瓶颈吗？如果不够，升级到 HTTP 2 工作量也不大。很多游戏是 H5 ，发起 HTTP 请求是最天经地义的。

grpc 是 http2 根本不可用来做游戏，要是 quic 可能还行。

@DefoliationM quic 不是大厂国内丢包到没法玩