云风的 BLOG: RPC 之恶

起因是最近有人在 skynet 邮件列表里贴了段错误 log ，从 log 显示，他在 table.sort 的比较函数里调用了 skynet 的 snax rpc 去获取远程数据。然后被 lua 无情的报了 attempt to yield across a C-call boundary 。

就 table.sort 不能 yieldable 的问题，其实在 lua 邮件列表里讨论过。老大的说法是，这个 C 实现是递归的，想要在 C 层面保留上下文非常困难，如果勉强实现，也会大大降低正常不需要 yield 的 case 的性能，非常不划算。

通过这件事，我反而觉得 none-yieldable 的限制反而提前阻止了一个错误的实现，其实是应该庆幸的。

最容易发现的是性能问题。

在《Unix 编程艺术》一书 7.3.2 节讨论 RPC 时，这样批评道：

“ a. 无法准确预估出一个指定调用会涉及多少数据的列集和散集，b. RPC 模型往往鼓励程序员把网络交易视为无成本行为。即使在某个事务处理接口上只额外增加一个来回，往往也增加足够多的网络延迟，完全抵消了解析或列集的开销。”

这段话的语境是把 RPC 和传统的消息通讯方式相比较，针对那些认为 RPC 的效率更高的观点说的。

即使不看效率，单看 RPC 给编程实现带来的方便性，其实最终是增加了，而不是减少了系统的复杂度。原文引用：

“支持 RPC 的主要理由同时恰恰证明了 RPC 增加了，而不是降低了程序的全局复杂度。”……(那些基于 RPC 的框架) “随着人们使用经验的增长，都已经从 Unix 世界的视野中消失了。这完全可能是因为这些方法能够解决的问题还不如它们引发的问题多。”

关于 RPC 的批评，还可以看这篇 paper A Critique of the Remote Procedure Call Paradigm

snax 是对 skynet api 做的一个 rpc 封装，原意是让使用的人门槛更低。但做完我就后悔了，rpc 只是表面上简单而已，但我自己却直觉的排斥这种做法，所以也没有把它作为 skynet 其它基础组件的基础。当用户开始以 RPC 方式调用时，他真的有一种不就是调了个函数的错觉。

针对 table.sort 这个比较函数里做 RPC 调用这件事说，对 n 个数据排序，table.sort 使用的是传统的快速排序，一种内部排序算法。它注重的是减少比较次数，而视获得数据的成本为 0 。在排序过程中，每个元素都不只一次的取出来比较。而 RPC 获取元素的成本显然是很高的，所以初看来，这里造成了严重的性能问题。

但如果仅仅是性能问题倒还好，可这样做其实正确性也无法保证。

如果要排序的元素在远程，也就是在另一个地方变化（如果是不变量也不必储远程获取了）。那么显然排序过程中，这些量是易变的，也就是你多次取同一个元素是可能不一样的。这样，sort 算法无法避免出现 a > b , b > c , 而 c > a 的情况出现。排序算法是无法正常工作的。

用一个通俗点的例子：如果你想按全国所有中学的学生人数对学校做一个排序。你是先把所有学校的人数都做一个调研，记在一起再排序；还是对这些信息一无所知的情况下，先按排序算法流程走，算法要求比较某两个学校人数的时候，再去调查这两个学校的数据？

Comments

你自己不是老大吗，你还有老大？

Posted by: ab先生 | (11) December 9, 2015 08:15 PM

忘记加双引号了 skynet.newservice(“function(...) ... end”, par1,par2...)

Posted by: scakerki | (10) December 9, 2015 10:40 AM

希望增加一种skynet.newservice 启动的方式：使用function(...) ... end 来启动例如： skynet.newservice(function(...) ... end, par1,par2...)

Posted by: scakerki | (9) December 9, 2015 10:27 AM

愿意是让使用的人门槛更低，原意吧？

Posted by: jack | (8) December 4, 2015 06:31 PM

告诉你我是人类。、

Posted by: 纪涛 | (7) December 4, 2015 02:15 PM

以前我们的rpc接口是同步的时候，确实没有考虑过rpc会导致的逻辑错误而滥用，现在我自己写服务器通信的时候，一直把需要远程调用的地方特例出来，让每一个调用者都知道，这个操作是需要从远端执行的。不过在table.sort里面写这样的函数，明显是使用rpc者逻辑上的错误。

Posted by: 菜鸟浮出水 | (6) December 4, 2015 01:36 PM

如果仅仅将RPC作为一种消息收发的机制也没什么，而且倒也提供了不少便利（更简单的现场保存，参数化消息的内容）。但如果当作普通函数调用，那结果肯定是灾难性的。尤其是在提高给其他模块调用的方法，调用层次里面有RPC方法的，对使用者来说绝对是一个陷阱；层次越深这个陷阱就隐藏得越深。更可怕的是很多使用RPC的人根本没意识到这个调用会引起什么问题。

Posted by: ShaneYao | (5) December 4, 2015 12:33 PM

这是约定问题吧，只是感觉snax比skynet服务好写了些，若要说rpc，skynet.call也算吧

Posted by: dpull | (4) December 3, 2015 10:03 PM

增加程序复杂度的难道不是这种员工？

Posted by: isaf | (3) December 3, 2015 11:11 AM

这种员工怎么招进来的。。。

Posted by: rubick | (2) December 2, 2015 08:58 AM

RPC: 怪我咯

Posted by: 十元够不够 | (1) December 1, 2015 07:24 PM