这种架构有点不好，中心分发器如果挂了，或者满连了怎么办呢？？

[ice-ice]

最少破坏了分布式一半以上的优雅性

[xiaonanln]

挂了不是问题，因为go程序本身非常稳定 满连也不会出现，因为中心分发器只和game和gate连接，而不是和玩家的客户端连接，因此连接数目有限。 之所以加入中心分发器是因为游戏服务器中对象（Entity）会频繁得在Game之间迁移，在迁移的过程中还需要保证RPC的时序的正确性。 目前我碰到的最大问题是所有的位置同步数据都需要经过中心分发器的时候有较大的开销，目前正在优化中。如果优化效果没有达到所期待的性能要求，我就考虑让gate可以直连game，然后使用这条链路发送所有的位置同步数据。 相信到时候中心分发器不会成为瓶颈，因为游戏服务器真正的瓶颈一般都在角色、怪物的行为和战斗逻辑等方面。

[ice-ice]

中心分发器本来就废掉了分布式。。因为所有数据都要过。。

正确的设计 应该是 网关 - > server 即可。。

网关承担负载均衡选优的责任。

客户端通过HTTP请求网关 获取服务器的IP地址。

之后在server层面，互相内部转发处理。

中心转发器是最不合理的。如果你看过hadoop等一些经典分布式 你会感觉你这种分布式是伪分布式。。 因为好不容易分开了。又用中心分发器聚集在一起了。。

[ice-ice]

而且你加了个中心分发器，这样做耦合性很大。。。 互相都有耦合。

如果用以上我说的这种，你可以想想有没有耦合。

只是在server层面加一些内部转发通讯的逻辑即可

[ice-ice]

另外有个作品和你这个架构一样。这也是我没用他们的原因。。 cellnet 应该叫这个。。

只要这种架构 必然出现这种问题。因为中心分发器绕不过。必过。而且它承上启下，在高速公路上也是个最拥堵的堵点

[ice-ice]

网关的作用是健康检查 负载均衡 选最优服务器IP 返回给客户端。

服务端server的作用是 内部通讯 处理消息。即可。

服务端和网关无任何耦合

[xiaonanln]

多谢宝贵意见。一开始设计中心分发器注意是因为游戏服务器和通用的服务器之间的一些不同点。 另外一方面，一开始就是想好了如果一个中心分发器不够，我可以扩展出多个中心分发器，不过这个不在第一版的目标里。

[ice-ice]

之前看cellnet 编程架构挺好。但是通信架构就跟你这样、感觉很可惜。。。。 写个程序不容易挺费劲，希望思路走对。。谢谢

[xiaonanln]

最新优化了位置同步数据，做了个测试

模拟玩家数目：3000 客户端位置同步频率：100毫秒一次 玩家视野内平均邻居个数：10个

这种情况下，平均每秒中心分发器要转发30万+条位置同步信息，占用CPU 6%。所以在多核高性能服务器上跑一个中心分发器支持个几万人在线应该是没问题的。