服务器设计的一些思考

[name5566]

以下是一些思考的记录，并不完全，有待深入。

客户端和服务器直接使用消息交互的原因：

1. 对客户端要求少（很容易就能连接上）
2. 方式灵活（替换协议很容易，增加功能很容易）
3. 满足现有需求

服务器内部使用 RPC 的原因：

1. 避免 callback hell
2. 易用

接口的具体形式：

1. 每个服务器有唯一的 ID
2. Leaf(ID).Go
3. Leaf(ID).Call
4. Leaf(ID).AsynCall
5. 选择类 chanrpc 接口

网络协议选择 TCP：

1. 需要异步发送的支持
2. 需要推送的支持
3. 为了接口的简洁

拓扑结构的构建：

1. 无中心
2. 两两互联

[15951836388]

大佬，是不是要搞分布式啦？等很久了啊。好激动

[chiuan]

请问大哥。什么时候出来

[name5566]

如果是分布式的服务器，无论如何也没有办法避免服务器之间的通讯问题，而这个问题并非一个容易做好的问题。为解决这个问题，提供一个通用的解决方案是合适的，不过实现确实有一些复杂。服务器两两互联并非一种设计，而是一种基础设施。这种基础设施提供了一种通讯的可能，但是实际每个游戏服务器的设计可以按需要使用这种通讯通道。比如说，某个设计中有 4 个服务器，它们之间只有一台服务器可以和其他服务器通讯，再比如说，某个设计中有 5 个服务器，它们之间可以相互通讯，无论是哪一种服务器的设计，无论服务器之间是什么样的规则，底层的框架都可以通过轻松的配置来支持这种框架设计的实现。Leaf 希望为框架设计者提供帮助，而本身 Leaf 应该是比框架更加低层级的工具。

[name5566]

如果是分布式的服务器，无论如何也没有办法避免服务器之间的通讯问题，而这个问题并非一个容易做好的问题。为解决这个问题，提供一个通用的解决方案是合适的，不过实现确实有一些复杂。服务器两两互联并非一种设计，而是一种基础设施。这种基础设施提供了一种通讯的可能，但是实际每个游戏服务器的设计可以按需要使用这种通讯通道。比如说，某个设计中有 4 个服务器，它们之间只有一台服务器可以和其他服务器通讯，再比如说，某个设计中有 5 个服务器，它们之间可以相互通讯，无论是哪一种服务器的设计，无论服务器之间是什么样的规则，底层的框架都可以通过轻松的配置来支持这种框架设计的实现。Leaf 希望为框架设计者提供帮助，而本身 Leaf 应该是比框架更加低层级的工具。

无中心是没什么必要的。因为你说无中心，我还以为你是想每两个服务器都互联，类似做paxos、raft这种，这就太复杂了，而且这些一致性协议性能损失也比较大，引入游戏内是不太划算的；
看你的解释，应该只是需要互通的两个服务之间的互联吧？这个分布式的基本都有的，没问题

嗯，你可以这样理解。Leaf 希望提供基础设施，基于这个设施搭建各种服务器架构。而 Leaf 本身不是架构。但 Leaf 希望提供的基础设施又不同于简单通讯协议之类的，而是直接可用的，高度封装的，正如上面说的接口形式。

[cupen]

低延迟服务做无中心化太难了。
一般的游戏项目体量很小， 2～5 台低配机器就能摆平 dau 1w~100w ，MMO 重些，但其核心服务的伸缩启停通常会用老土但稳妥的办法——预估容量 & 停机维护，顶多加一个中心节点作为 超级仲裁 来控制复杂度。现在情况好多了，可以用 consul 和 etcd 之类的外部集群，不必自己实现 paxos,raft 之类的。当然，多上几台高配机降低集群规模以避开分布式领域那些要命问题总是划算的，精巧又复杂的技术并不容易实施。

p.s.: 感觉这个方向比较牛 X 的是 actor/erlang，值得参考(chao) :D