在 skynet 中，有时候为一个服务实现一个前置的代理服务是很有必要的。 比如，你希望对这个服务发起的请求是支持超时的，就不必在功能实现的服务中实现，那样会增加无谓的复杂性。你可以在功能实现的服务前加一个代理服务，当超时发生时，通知请求方。关于这个实现，我在 blog 中给过一个示例。 同理，当你需要做一些负载均衡的处理的时候，也可以做一个代理服务，让请求分摊到多个可以完成类似功能的服务中去，实现比较简单，本文就不展开了。 今天想谈一下怎么利用代理服务更好的为一些热点服务提供过载保护。

    skynet 提供了一个 lua 库 netpack ，用来把 tcp 流中的数据解析成 长度 + 内容的包。虽然使用 skynet 的同学可以不使用它，而自己另外实现一套解析协议来解析外部 TCP 数据流(比如 skynet 中的 redis driver 解析 redis server 的数据流就是用的换行符分割包)，但依然有很多同学询问，能不能自定义包头长度。

    经过一个月， 我基本完成了 skynet 的 C 版本的编写。中间又反复重构了几个模块，精简下来的代码并不多：只有六千余行 C 代码，以及一千多 Lua 代码。虽然部分代码写的比较匆促，但我觉得还是基本符合我的质量要求的。Bug 虽不可避免，但这样小篇幅的项目，应该足够清晰方便修正了吧。 花在 Github 上的这个开源项目上的实际开发实现远小于一个月。我的大部分时间花了和过去大半年的 Erlang 框架的兼容，以及移植那些不兼容代码和重写曾经用 Erlang 写的服务模块上面了。这些和我们的实际游戏相关，所以就没有开源了。况且，把多出这个几倍的相关代码堆砌出来，未必能增加这个开源项目的正面意义。感兴趣的同学会迷失在那些并不重要，且有许多接口受限于历史的糟糕设计中。 在整合完我们自己项目的老代码后，确定移植无误，我又动手修改了 skynet 的部分底层设计。

    今天发现 Skynet 消息处理的一个 bug ，是由多线程并发引起的。又一次觉得完全把多线程程序写对是件很不容易的事。我这方面经验还是不太够，特记录一下，备日后回顾。 Skynet 的消息分发是这样做的： 所有的服务对象叫做 ctx ，是一个 C 结构。每个 ctx 拥有一个唯一的 handle 是一个整数。 每个 ctx 有一个私有的消息队列 mq ，当一个本地消息产生时，消息内记录的是接收者的 handle ，skynet 利用 handle 查到 ctx ，并把消息压入 ctx 的 mq 。 ctx 可以被 skynet 清除。为了可以安全的清除，这里对 ctx 做了线程安全的引用计数。每次从 handle 获取对应的 ctx 时，都会对其计数加一，保证不会在操作 ctx 时，没有人释放 ctx 对象。

    最近我的工作都围绕 skynet 的开发展开。 因为这个项目是继承的 Erlang 老版本的设计来重新用 C 编写的。 再一些接口定义上也存在一些历史遗留问题. 我需要尽量兼容老版本, 这样才能把上层代码较容易的迁移过来。 最近的开发已经涉及具体业务流程了， 搬迁了不少老代码过来。 我不想污染放在外面的开源版本。 所以在开发机上同时维护了两个分支， 同时对应到 github 的公开仓库, 以及我们项目的开发仓库。 btw, 我想把自己的开发机上一个分支版本对应到办公室仓库的 master 分支， 遇到了许多麻烦。 应该是我对 git 的工作流不熟悉导致的。我的开发机的 master 对应着 github 上的 master , 但我大多数时间在一个叫 ejoy 的分支上开发。 这个分支对应到办公室服务器的 master 分支上。

    今天把 Skynet 的集群部分，以及 RPC 协议设计实现完。 先谈谈集群的设计。 最终，我们希望整个 skynet 系统可以部署到多台物理机上。这样，单进程的 skynet 节点是不够满足需求的。我希望 skynet 单节点是围绕单进程运作的，这样服务间才可以以接近零成本的交换数据。这样，进程和进程间(通常部署到不同的物理机上)通讯就做成一个比较外围的设置就好了。 为了定位方便，我希望整个系统里，所有服务节点都有唯一 id 。那么最简单的方案就是限制有限的机器数量、同时设置中心服务器来协调。我用 32bit 的 id 来标识 skynet 上的服务节点。其中高 8 位是机器标识，低 24 位是同一台机器上的服务节点 id 。我们用简单的判断算法就可以知道一个 id 是远程 id 还是本地 id (只需要比较高 8 位就可以了)。