给 skynet.call 加上超时
不断的有人问在 skynet 里怎么给跨服务调用加上超时处理。我不太想再解释为什么在 skynet 这样的系统中,加入超时机制会使得在其上构建的系统增加不必要的复杂度。那只是为了想不到更好的方法而做的一点变通。
你应把 skynet 视为一个整体,正如你平常所写的程序,大多数 api 调用的时候不会设置超时一样。只有在明确的特殊需求时,才在上层在封装一层带超时参数的调用(而不是直接使用 skynet.call )。
当昨天再次收到这个特性请求时,我仔细考虑了一下。发现了一个有趣的方案,可以非入侵性的在现在的框架下加上超时返回这个特性,下面做一个记录:
修改 skynet.lua 这个基础库很不划算,会改变很多基础的调度代码。另外写一套带超时的 call 又会和已有代码大量重复。其实,如果我们单独做一个代理隧道服务,专门转发请求,超时处理就会简单的多。
我们可以实现一个代理服务,它的作用仅仅是将外部请求转发给指定的服务,并将回应包转发回去就够了。在这个代理服务中可以设定一个超时值,一旦转发的请求在指定时间内没有响应,则给调用者一个 error ,并在真正收到回应时忽略掉就可以了。
我们甚至可以在这个代理服务中做许多额外的监测和统计工作,易于发现系统中有问题的设计。而代理服务将实际的服务包裹起来后,对调用者来说,是完全透明的。超时设置只在启动时(或写在配置文件中)设置,使用时,完全不需要修改原有的代码。
担心加一层额外的代理会损失性能是完全没必要的。代理服务几乎没有状态,可以直接用 C 语言编写。主要工作只是做消息转发,甚至不需要额外拷贝消息,而只需要传递指针。用 C 语言编写意味着内存开销可以忽略不计(没有额外的 lua vm ),而纯消息转发的时间开销也是 O(1) 的。
对于超时计时,如果需要不是那么精确的话,以秒为单位即可。我们不需要为每次调用都向系统索取一个 timer ,而可以做成一个时间轮结构。用一个低频心跳工作,我认为 10Hz 甚至 2 Hz 都够。每个心跳检查一下有没有调用超时了,若有,就抛处一个 error 。
暂时我不打算将这个特性加入 skynet 现在的版本(毕竟已经快发布正式版了),除非在我们自己的项目或有人大量使用它证明是有用的,可以考虑在以后的版本中收录。
我用 lua 做了一个简单的实现,放在 gist 上,有兴趣的同学可以玩玩。
https://gist.github.com/cloudwu/63c08b7d6f9be1d0950f
这里有两个文件,totun.lua 是我写的这个代理服务;而 testtun.lua 是一个简单的测试程序。
注意,我特地使用的 skynet 的核心 api 实现的 totun ,而没有使用高层的封装。这使得它可以很容易的翻译成 C 版本(如果有必要)。没有任何 coroutine ,只有对 C 函数的调用。
对 skynet 的基础部分工作原理有兴趣的同学,也可以阅读这份实现。搞清楚仅靠设置一个消息回调函数,skynet 服务是怎样工作的。
由于没有使用上层框架,它虽然是一个 lua 服务,但不能直接使用 skynet.newservice 启动。在 debug console 里也看不到状态,无法用 debug 控制指令控制。如果期望实用的话,还可以进一步做封装。
实际上这个代理服务并不要求一对一,而可以多对一的。即多个调用者对一个服务。它内部重排了 session 号以支持这一点。(如果是一对一设计,可以简单的转发 session 号即可)所以你可以按 service mgr 那样对所有需要代理的服务做统一管理,同一个服务只生成唯一一份代理,而不是在每个使用使用的地方都生成独立的代理。
Comments
Posted by: Dean | (4) March 29, 2016 02:26 PM
Posted by: jxlczjp77 | (3) October 19, 2015 10:24 AM
Posted by: wudao | (2) October 14, 2015 02:15 PM
Posted by: fangxin | (1) October 14, 2015 11:56 AM