很少这么用的，没必要较真这个。
这刁图还是给你拿出来了
这是rust？没用过rust，还以为和C++差不多呢 这不就是JS吗
是 js 啊，我用 php、js 这些判空总感觉不放心，， 
感谢@花心大萝卜 的提醒，我决定支持全球同服功能了。
打算同时支持单体模式和全球同服模式。
纯单体模式：扩容后就是独立小服务器，这种模式下尽量避免扩容，如果就想这么用，也是可以的。
匹配中心模式：用同一个docker地址部署两个服务，用环境变量区分服务的类型：匹配中心服务、房间服务
对于匹配中心服务，需要给他配置房间服务的内网地址；对于房间服务，需要给他配置匹配中心服务的内网地址，房间服务需要在匹配中心服务中注册；
匹配中心可以有多个实例，可以借助数据库、redis实现所有玩家的匹配；匹配成功后，匹配中心通过内网地址与房间服务通信创建房间，这个内网通信环节有会话亲和性功能，可以指定房间服务实例id进行通信。
其实这里改成“全实例同服”比较符合我的需求，只是解决扩容后的匹配问题 
终极方案：只需部署一个服务，再加一个数据库(mysql或者redis)，就可以实现一个弹性伸缩、无单点故障(所有实例对等)、全实例同服的联机对战服务器。
场景描述：
- 当多个用户通过唯一的外网服务地址(后面有负载均衡)发起连接时，可能是不同的实例接收连接，它们通过数据库实现玩家的匹配，此时可能是来自不同实例的几名玩家匹配成一局游戏；
- 通过数据库实现只让其中某一个实例通过唯一的内网服务地址(后面有负载均衡)请求建立房间，实际建立房间的实例可以是任何一个实例，可能是它自身，然后把会话亲和性ID保存在数据库中；
- 这局游戏的其他玩家所在的实例可以通过亲和性ID主动和那个房间实例进行通信。
瓶颈只在数据库了，如果达到瓶颈，再优化不迟，比如分层存储方案、采用消息队列等中间件。
我现在用 微信云托管 开发微信小程序，也是这种方案，多实例加 MySQL 和 Redis，，
感觉可以先不用折腾太多分布式的东西，弱联网啥的单服承载上线也不低。绝大多数游戏用户都没到上限游戏先凉了 ，搞个稳定易用，有时间的话能再支持下脚本语言做逻辑和客户端 sdk ，就很猛了
现在方向越来越明确了，集群部署，玩家跨实例匹配，动态切换玩家直连实例，估计再有半个月能上demo
实例间通信，原本的设计是初始化时全实例建立通信网，
现在改了，改成玩家无法通过亲和性Id水平切换实例时，才让玩家直连实例与房间实例建立通信。
房间实例的创建，可以由房主再次通过负载均衡器请求集群，让集群选择建立房间的实例，这样能避免玩家水平切换实例导致的负载均衡某些特定场景的失效现象。
上了容器编排docker compose，可以一键启动集群服务了，本地开发、测试环境搭建非常方便。
容器编排不适合上生产，因为它是单机多容器，但是如果只有一台服务器，且懒得单独部署中间件（目前只有MySQL），也可以直接用容器编排，毕竟是一键启动整套服务。
正确的使用方式是在k8s或者云托管平台上部署，数据库使用外部，云托管平台都提供关系型数据库功能，这种方式是自动扩容的。
如果是单机服务器，不想用容器编排和docker，可以自行部署好所需中间件（目前是MySQL），然后直接启动二进制可执行程序。
不过nginx的负载均衡和云托管负载均衡的粘性会话功能有点不太一样，云托管平台可以在header中下发亲和性ID，后续请求在header中携带亲和性ID即可指定请求实例。而nginx不是这样，水平切换直连实例这个功能受限，正在研究攻克。
大佬们可否支招？
有方案了，是我着相了。
docker-compose中使用nginx实现负载均衡，既然可以根据header参数实现粘性请求，那就让游戏端随机生存粘性ID。
看来所有问题都解决了，就差落实功能了。
你的colseus用rust用ai重写一次就可以了
colseus依赖redis实现不同实例玩家的消息同步，我的想法是消息同步不使用中间件，而是把同一对局的所有玩家移动到同一实例下。
一样的镜像，腾讯云上正常，抖音云上就启动不了，怀疑是它用bash启动脚本，而不是sh。
还得再看看
淦，抖音云的负载均衡没有会话亲和性功能，无法指定连接实例，而且实例无法通过内网ip互相通信，它们不在一个内网。看来还是得参考colseus实现一个备选方案——让实例通过redis通信，否则在抖音云这种平台无法集群部署。
这么看来还是腾讯云的云托管方便啊，真正的一站式服务，不像其他平台那样，服务是散装的，你得挨个开通配置。