Skynet 作为网游服务器的焦点在于单进程内的任务调度和消息分发，而非分布式计算。文章讨论了 Skynet 的设计选择，如不直接提供超时机制以降低复杂性，以及采用 Lua 作为事实上的标准语言。作者指出，Skynet 的简单线程池设计适合处理网络游戏的高实时需求，而新的socket库改进了低负载环境下的响应速度，但牺牲了高负载下的处理能力。未来的计划包括移除底层的分布式支持和名字服务，加强服务生命周期管理等。
其实，对于我们的网游服务器来说，分布式运算，以及分布式运算的稳定性并不是第一位的。我们更需要的是充分挖掘多核处理器的单机性能以达到高实时的相应速度。分布式运算和并行运算显然不是同一类问题。skynet 只要专注于并行处理就可以了，顺带支持一下分布式可以说是为以前的设计做的兼容。
事实上，即使在过去基于 erlang 的版本，我们依然编写了两个独立的系统间通讯的模块，而不全部依赖于 erlang 自己的分布式设计。这个模块一直沿袭到现在依然存在于我们的项目中，让 skynet 自己的分布式节点管理显得有点多余。
skynet 专注点应该是一个单进程内的任务调度器，以及消息分发器。虽然理论上 skynet 可以嵌入各种不同的虚拟机，比如更多人爱用的 python 。但限于它目前的用户量太小，主要开发工作也是我一个人在做，我只能按我自己的喜好单维护 Lua 的版本。经过一年多的开发，我发现即使为了性能考虑，我也很少再自己直接用 C 去开发 skynet 的服务了。我可以写一个 Lua 的 C 模块挂在一个 Lua 服务上嵌入 skynet 中使用。Lua 就成了 skynet 事实上的标配。
Lua VM 所占用的额外空间小，以及启动新的 Lua VM 速度快就成了 Lua 最大的优势。虽然它在共享只读数据方面还比不上 Erlang ，但命令式语言这点很受我们的开发人员欢迎。Lua 的 coroutine 有很小的内存开销，对于 Lua 5.2 来说，不到 300 字节，这比 Golang 的 goroutine 还要小的多，而功能上甚至更超一筹。
很多同学问我，为什么 skynet 默认的 RPC 机制没有超时处理。我的回答是，如果你非要做超时，可以用现有机制模拟出来。现在的 skynet lua api 可以 sleep ，可以 wakeup 一个 sleep 的 coroutine ，可以 fork 一个 coroutine ，这些加起来足够实现一个带超时机制的 RPC 调用来。但我选择不直接提供，因为，如果每次 RPC 调用都考虑超时失败的情况的话，其带来的复杂度远远超过了 RPC 带来的便捷。
如果我们把 skyne
最低0.47元/天 解锁文章
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
