你后端有用开源框架？打算用 Actix Web
我用的axum，之前用rust做小说网站也是用的axum
引入一个匹配中心就好了，云托管本质需要你的服务是无状态的。你既然要能够获得匹配的玩家，可以把玩家的索引数据缓存到 redis ，然后分配服务去取不就好了？服务中只有逻辑，无状态数据。有也是内存态的请求队列数据。
有道理，我看看能不能让多个实例通信
分布式组件设计，当哪个地方数量遇到瓶颈了，就独立出来做单独的组件（进程）。
这里就可以把玩家管理和匹配抽出来做玩家服，然后房间内帧同步的功能就独立的纯房间服，外面再带一个管理服务器和服务发现的路由组件。
要想实现一个支持完美扩容、所有玩家“同服”的游戏服务器，架构太复杂了，要区分的服务也很多，还得依赖相应的基础设施。
所以还是决定保持轻量化路线了，不使用数据库、redis和其他缓存中间件，仅作为基于rust的单体服务，直接在云托管上部署，或者随便找个服务器往上一丢，就能跑起来。
扩容实例就相当于“开服”了，总之能接住流量，不至于让玩家干瞪眼玩不了。
一般为客户端连接门服务器，门服务rpc连接后端逻辑服务器，逻辑服务器之间也用rpc通信，这样子玩家登录的就是大世界了，新增一个服务器就只需要连接已有的门服务器就能参与通信了
这个是分布式Websocket都会遇到的问题。除了实例扩容、缩容外，玩家断线重连时也会遇到类似问题，自己实现的话很麻烦。我做过类似需求的项目，分布式Websocket的部分，可用Centrifugo来解决。它可以帮你管理所有Websocket连接，支持节点扩容、缩容、断线重连。它的前端js库支持心跳检测、历史消息重放、断线重连、Token验证等常用功能。你只要聚焦游戏的核心逻辑，然后告诉Centrifugo给哪几个id的设备发什么消息即可。
如果要支持在云上方便部署，就要做成镜像。有多个服务也不怕，可以写个Docker Compose或K8s的yaml，也是单个服务器也行、云托管自动伸缩也行。
github上有开源的rust服务器项目吗，可以站在巨人肩膀上前进
分开设计，多个大厅服务器，单个或多个匹配服务器，匹配成功之后负载均衡到游戏服务器
git在哪里，去哪里围观
玛德你们怎么这么能学？我前端还没学完，你们连Rust这种据说巨难的都用会了…[狗子摇头.gif]
语言本身没有难的 规则都摆在那里的，比COCOS的文档要明确丰富的多了，但用语言做出东西来 才是难的
rust 亲测很难，所有权、生命周期、多线程、异步，可变不可变，还有其它杂七杂八的几西混在一起，难度几何倍数增加，为了性能和安全性，在易用性上差很多。那种感觉就像学完英文来学中文：卧槽，中文怎么有几万个字，而英文就 26 个字母。虽然长期肯定是 rust 强大，但暂时搞不了，第一次看完教程没办法入。估计还得再看几遍。
我也看好rust服务器
rust好啊，rust得学
rust是真好
但我感觉强类型语言写的东西放心，js ts php 这些比较两个对象都不放心，，
ts 也可以勉强算强类型了，我觉得写得非常顺畅，现在关键差在计算性能。