很少这么用的，没必要较真这个。
这刁图还是给你拿出来了
这是rust？没用过rust，还以为和C++差不多呢 这不就是JS吗
是 js 啊，我用 php、js 这些判空总感觉不放心，， 
感谢@花心大萝卜 的提醒，我决定支持全球同服功能了。
打算同时支持单体模式和全球同服模式。
纯单体模式：扩容后就是独立小服务器，这种模式下尽量避免扩容，如果就想这么用，也是可以的。
匹配中心模式：用同一个docker地址部署两个服务，用环境变量区分服务的类型：匹配中心服务、房间服务
对于匹配中心服务，需要给他配置房间服务的内网地址；对于房间服务，需要给他配置匹配中心服务的内网地址，房间服务需要在匹配中心服务中注册；
匹配中心可以有多个实例，可以借助数据库、redis实现所有玩家的匹配；匹配成功后，匹配中心通过内网地址与房间服务通信创建房间，这个内网通信环节有会话亲和性功能，可以指定房间服务实例id进行通信。
其实这里改成“全实例同服”比较符合我的需求，只是解决扩容后的匹配问题 
终极方案：只需部署一个服务，再加一个数据库(mysql或者redis)，就可以实现一个弹性伸缩、无单点故障(所有实例对等)、全实例同服的联机对战服务器。
场景描述：
- 当多个用户通过唯一的外网服务地址(后面有负载均衡)发起连接时，可能是不同的实例接收连接，它们通过数据库实现玩家的匹配，此时可能是来自不同实例的几名玩家匹配成一局游戏；
- 通过数据库实现只让其中某一个实例通过唯一的内网服务地址(后面有负载均衡)请求建立房间，实际建立房间的实例可以是任何一个实例，可能是它自身，然后把会话亲和性ID保存在数据库中；
- 这局游戏的其他玩家所在的实例可以通过亲和性ID主动和那个房间实例进行通信。
瓶颈只在数据库了，如果达到瓶颈，再优化不迟，比如分层存储方案、采用消息队列等中间件。
我现在用 微信云托管 开发微信小程序，也是这种方案，多实例加 MySQL 和 Redis，，
感觉可以先不用折腾太多分布式的东西，弱联网啥的单服承载上线也不低。绝大多数游戏用户都没到上限游戏先凉了 ，搞个稳定易用，有时间的话能再支持下脚本语言做逻辑和客户端 sdk ，就很猛了