云风的 BLOG: 开发笔记 (7) : 服务器底层框架及 RPC

很久没有写工作笔记了，如果不在这里写，我连写周报的习惯都没有。所以太长时间不写就会忘记到底做了些啥了。

这半个多月其实做了不少工作，回想起来又因为太琐碎记不太清。干脆最近这几天完成的这部分工作来写写吧。

我在开发笔记第四篇谈到了 agent 的处理流程。但实际操作下来还是觉得概念显得复杂。推而广之，对于不是 agent 的服务，我需要一个通用的消息处理框架。

对于每个服务器，可以看成是对一组约定的服务协议进行处理。对于协议分组，之前我有许多想法，可做下来又发现了若干问题。本来我希望定义出一个完整的 session 概念，同一个 session 下，可以分不同的步骤，每个步骤都有一个激活的协议组。协议组之间可以共享状态，同时限制并发。做下来发现，很难定义出完整的事务处理流程并描述清楚。可能需要设计一个 DSL 来解决这个问题更好一些。一开始我也是计划设置这个小语言的。可一是时间紧迫，二是经验不足，很难把 DSL 设计好。

而之前的若干项目证明，其实没有良好的事务描述机制，并不是不可用。实现一个简单的 RPC 机制，一问一答的服务提供方式也能解决问题。程序员只要用足够多经验，是可以用各种土法模拟长流程的事务处理流。只是没有严格约束，容易写出问题罢了。那么这个问题的最小化需求定义就是：可以响应发起请求人的请求，解析协议，匹配到对应的处理函数。所有请求都应该可以并发，这样就可以了。至于并发引起的问题，可以不放在这个层次解决。

我谨慎的选择了 RPC 这种工作方式。实现了一个简单的 RPC 调用。因为大多数服务用 Lua 来实现，利用 coroutine 可以工作的很好。不需要利用 callback 机制。在每条请求/回应的数据流上，都创建了独立的环境让工作串行进行。相比之前，我设计的方案是允许并发的 RPC 调用的。这个修改简化了需求定义，也简化的实现。

举例来说，如果 Client 发起登陆验证请求，那么由给这个 Client 服务的 Agent 首先获知 Client 的需求。然后它把这个请求经过加工，发送到认证服务器等待回应（代码上看起来就是一次函数调用），一直等到认证服务器响应发回结果，才继续跑下面的逻辑。所以处理 Client 登陆请求这单条处理流程上，所有的一切都仅限于串行工作。当然，Agent 同时还可以相应 Client 别的一些请求。

如果用 callback 机制来表达这种处理逻辑，那就是在发起一个 RPC 调用后，不能做任何其它事情，后续流程严格在 callback 函数中写。

每个 RPC 调用看起来是这样的：

  local salt = service.call(addr ,
     "login.salt" , { username = username }).salt
  local response = md5(username .. ":" .. password .. ":" .. salt)
  local ok = service.call(addr, "login.challenge" ,
     { username = username , response = response }).ok
  print(ok)

而 service 编写是这样的：

-- login.lua
function salt(username)
  local salt = gen_salt(username)
  return { salt = salt }
end

function challenge(username , response)
    local salt = gen_salt(username)
    local password = service.call("authdb",
       "query" , { username = username }).password
    local result = md5(username .. ":" .. password .. ":" .. salt
    return { ok = (result == response) }
end

大家需要约定中间的协议，采用 protobuf 格式描述：

package login;

message salt {
  optional string username = 1;
  message response {
    optional bool salt = 1;
  }
}

message challenge {
  optional string username = 1;
  optional string response = 2;
  message response {
    optional bool ok = 1;
  }
}

btw, 我没有用 protobuf 的 serivce 特性。觉得不太方便，而且也没有太多必要引入过多特性。

当然这只是 RPC 范例代码，不设计认证协议的具体设计。实际应用中，校验过程会比这个更完备一些。

在 login 服务中，收到用户来的请求，会去向 authdb 服务索取密码信息。这个 RPC 调用是阻塞的，直到 authdb 返回结果。但是，login 服务并不被阻塞，可以接受其它请求。每个不同请求的回应对应关系，是在低一个层次上的 session id 来区分。这些隐藏在框架实现中了。

设计细节今天先不列了，也没太多难度。

最后，我对 RPC 的使用是谨慎的。必须留意 RPC 会带来的问题。这些在《Unix 编程艺术》7.3.2 有论述，我再说多少次也超不出这个范畴。

做这套东西，我和蜗牛是有一些分工的。服务器数据流框架并不是我来实现。蜗牛用 erlang 做的。

这些东西我们折腾了好久，这里面有我的很多工作失误。最终，我觉得应该把工作严格划分开，需要有一个清晰的模块需求定义。

本来是初步定好了，每个服务工作在一个独立的 Lua State 中（并不一定在独立进程/线程中），包括为每个 Client 服务的 Agent 。一开始是在 Lua 的层次来划分工作的。蜗牛写了一部分的 Lua 驱动代码。我觉得是我在分工问题上的错误。这个需求很难稳定下来。后来，我整理了一下思路，决定定义明确的 C 接口，然后我来做 Lua 封装。

服务器的大框架主要解决玩家的接入问题，各个服务间的数据流向问题，服务的启动和停止等等。我设想，每个服务都有单一的输入输出流，只面对框架。实现上可能框架并不是在做复制转发，有可能直接对接两个服务的输入输出。尤其是两个服务可能是在同一个线程中，以 coroutine 的形式工作。这个优化空间可以留下来。

我在做后面的工作之前，先写了一份文档，描述需求：

向 skynet 发送一条指令, 并立刻获得一个结果. 目前提供以下三条指令:
- 注册自己到 skynet , 可以给出一个 well-known 的名字 (name), 也可以不给出. skynet 返回一个 unique 名字 (uid)
- 向 skynet 查询系统时间
- 设置 timer , skynet 会在 timeout 时回调
向 skynet 发送数据, 由 skynet 决定把数据送达何处.
注册一个 callback , 当 skynet 有消息送达的时候触发.

注：skynet 是框架的开发代号。

然后是接口的 C 定义

void * skynet_context(void); void skynet_exit(void * context); void skynet_step(void * ud); const char * skynet_command(void * context, const char * cmd , const char * parm); void skynet_send(void * context, const char * addr , const char * msg, size_t sz); typedef void (*skynet_cb)(void *context, void *ud, const char * uid , const char * msg, size_t sz); void skynet_callback(void * context, skynet_cb cb);

注: command 我选取了最简单的字符串风格。是因为考虑到字符串的知识依赖最小，很容易 binding 到任何语言中。也最容易实现网络传输。不同 command 的协议定义也写了文档，包括文本协议的定义。这里就不一一列出了。

有了文档之后，我开始编写 skynet 的黑盒。基本上就是一个本地单一进程，用来调度同一进程下的不同服务。这个很好写，大约两三小时，不到 300 行 C 代码就搞定了。虽然限制很多，性能也很低下，但可以实现以上的接口。

之后的代码就不再是假盒子了。是把这几个 C 接口 binding 到 lua 里，然后在 lua 层面写真实的应用。工作量比较大，但也好做。一旦蜗牛那边真正的 skynet 工作正确，整合工作只是替换前面几个接口的实现库而已。

Blog 写这种系列，不太方便整理。这点还是 wiki 比较好。我把这个系列整理出一个列表了。

ps. 这段时间还做了许多琐碎的工作，包括帮客户端解决一些问题。中间闲了两天，想玩一下 LaTeX ，结果就写了这个：Lua 源码欣赏。结果工作一忙就没时间写下去了。估计这个半拉子工程会这么太监掉的。

Comments

Posted by: Anonymous | (21) June 7, 2013 10:29 AM

https://github.com/bketelsen/skynet

Posted by: Anonymous | (20) May 15, 2012 06:34 PM

@steve 重新写一个.

Posted by: Cloud | (19) February 21, 2012 03:36 PM

这个验证码插件是我自己写的，只有一行 perl 代码。就是判断输入是不是 '7' 如果答案一直不变，那只能说明SPAM的是所有的WP的系统，而不是针对你。假如有专门针对你的呢？如何处理？

Posted by: steve | (18) February 21, 2012 02:10 PM

ps. 这段时间还做了许多琐碎的工作，包括帮客户端解决一些问题。中间闲了两天，想玩一下 LaTeX ，结果就写了这个：Lua 源码欣赏。结果工作一忙就没时间写下去了。估计这个半拉子工程会这么太监掉的。 =================== 这个看了一下，很受启发，希望云风能继续写完哈~~

Posted by: anders | (17) January 13, 2012 09:17 AM

能把那个LaTeX文档里的链接的框框去掉么..看着怪怪的~

Posted by: R | (16) January 12, 2012 10:19 AM

那个LaTeX文档,能把链接的框框去掉么..在Foxit里面看着怪怪的..

Posted by: R | (15) January 12, 2012 10:16 AM

同顶，云风大哥的《Lua源码赏析》确实很不错！Fans们有福了。

Posted by: 涛 | (14) January 11, 2012 09:52 PM

Lua 源码欣赏写的深入浅出，非常不错，希望坚持下去

Posted by: 靳超 | (13) January 11, 2012 02:16 PM

我现在对网游服务器架构难点的理解就是在保证“高性能”前提下，做到游戏逻辑编写最容易。这个对于架构者不仅仅是技术上的挑战，至少有一半依赖于对业务的熟悉。其他如稳定性撒的是对服务器的基本要求。当然对于“高性能”这个永恒主题，不同的游戏有不同的追求，不同的游戏有不同的挑战。

Posted by: 涛 | (12) January 10, 2012 09:46 PM

用什么语言不重要,每个人的智商和思维习惯都不同,只要有自信能达到目标就好,目标包括可维护可扩展,方便和其它程序的交互,以及足够的性能.

Posted by: dwing | (11) January 10, 2012 10:25 AM

用erlang=失败。

Posted by: tigerdx | (10) January 9, 2012 10:55 PM

都是你俩在谈论，我写过服务程序，但是，涉及到并发量这么高，连接请求这么多的应用，还没接触过。读起来有点吃力。不过，感觉云风的工作日志非常非常具有学习和参考意义，有待以后会过头来读。

Posted by: starshine | (9) January 9, 2012 10:15 AM

牛B。 ====== 反复去看了您的几篇开发笔记；还是不能理解skynet是如何解决IPC 服务定位的问题。貌似erlang做了些关键的事情；作为一个不懂erlang的人，决定默默的去学习erlang。

Posted by: Wuvist | (8) January 9, 2012 02:34 AM

只要能解决问题，就采用最简单的设计。这个验证码插件是我自己写的，只有一行 perl 代码。就是判断输入是不是 '7' 。结果它很管用。从后台 log 看，拦截了几万条 spam 。

Posted by: Cloud | (7) January 9, 2012 02:30 AM

嗯，是偶先入为主了；不好意思。 PS：“为了验证您是人类”，这个问题好像不会变？

Posted by: Wuvist | (6) January 9, 2012 02:03 AM

原文我已经写了. 既然是 C 接口，就有可能是直接对接的。框架理论是可以作到一个 send 调用直接到对方的 callback 的。这个属于优化。只是看起来是通过了框架。另外，原文我完全没有提到依赖网络连接层，是你的先入为主的观念吧？事实上，我们的实现的大多数情况是和网络连接层无关的。

Posted by: Cloud | (5) January 9, 2012 01:57 AM

@Cloud intranet环境，应该可以视为稳定吧？ “需求明确，文档化接口”这点我是非常赞同的。但是否有必要让Service都依赖于同一个网络连接层？ Service A/B之间为何不能直接通讯？而需要经过XXNet做中转？如果说，服务“仅仅是 lua 的 coroutine ，所以需要调度。包括 core 的管理。”；那么，我能否将这样的调度、管理理解成为一个单机，或者说单进程内的程序架构解决方案？这个层面我觉得应该是独立的问题。 ===== 而IPC，不同进程、物理机器上的不同服务如何通讯，我觉得是另一个层面的问题。而这个层面，是我原来公司才用XXnet去解决的；刚刚，我就直接认为同样也是skynet所要解决的问题。我个人认为这个问题归根到底就是一个服务定位的问题。同样是考虑优化，上万个客户端与上万个服务通讯，所有包均经过一个XXnet中转，效率应该会比客户端通过某种机制定位到服务，然后直接通讯效率低一些。当然，客户端如果是经过外网间接进来，中转是必须的。但如果后端的上万个服务需要相互通讯呢？

Posted by: Wuvist | (4) January 9, 2012 01:49 AM

@Wuvist 当然你可理解为，我刚才说的这些只是性能问题，属于优化范畴。在 internet 上也可以把这些实现出来，而不必再自己做。但正因为以后需要这种优化(可能会跑上万个服务，比如每个 client 都有对应的处理服务），更应该把需求明确，文档化接口。变成一个独立层次。

Posted by: Cloud | (3) January 9, 2012 01:23 AM

@Wuvist 主要解决的是服务的生存监控，启动。另外服务不一定跑在独立进程上，甚至不跑在独立线程上。可能仅仅是 lua 的 coroutine ，所以需要调度。包括 core 的管理。还有 IPC 问题。可能 IPC 的 P 不是系统的 process 。还有 timer 的驱动，时间控制。另外，internet 是个不稳定的网络。还是有区别的。

Posted by: Cloud | (2) January 9, 2012 01:19 AM

呵呵，看起来跟偶原来公司的架构非常类似，XXnet, XXAgent。 XXnet对应skynet，它负责处理各种客户端、服务的连接，负责包转发，它本身是分布式的。我个人对这样的架构感觉有点奇特。它本身不就是个internet么？按照我的理解，主要是解决service定位的问题；但这，不就是DNS做的事情么？

Posted by: Wuvist | (1) January 9, 2012 01:13 AM

云风的 BLOG

思绪来得快去得也快，偶尔会在这里停留

开发笔记 (7) : 服务器底层框架及 RPC

Comments

Post a comment