谈谈RPC与套接字以及信号

Rpc 的 linux 实现是很简洁的，这是有目共睹的。事实上 rpc 机制在 linux 上只是其 n 分之一而已， windows 才是 rpc 大行其道的舞台。可是为何 rpc 没有在 unix/linux 上得到大规模应用呢？这还得从 unix 的设计哲学上寻找答案。 linux 就不必说了，因为它继承了 unix 的优良基因。

     一个 rpc 几乎最少封装了一个事务，具体的数据封装在经过编码的二进制流中， rpc 二进制流中包含了太多的东西以至于它是应用相关的，比如包括过程号，程序号，版本等， rpc 接口定义的不仅仅是一个用户接口还包括了应用程序的具体数据，而且即使把它纯粹看做一个接口，那么这个接口（确切地说应该是一套接口，而不是一个）也过于复杂，因为你不能说出一个确切的接口函数来表示 rpc 接口，当你要列举 rpc 的接口时，你必须说出这次 rpc 是做什么的。当然越复杂就越容易出错。 rpc 可以将复杂的网络交易更快更方便的打包，这也许是它的优势，不像套接字那样，首先你要初始化一个套接字，然后你要自己手动的将数据进行组织，因为套接字并不知道除了传输之外的任何行为性质的东西，而 rpc 却知道约定的不下 20 种交易行为。

     unix 的哲学就是简洁，而且引导程序员用小而简单的接口组合从而实现较大的功能，这样的小接口都是最基本的，而且是正交的，对于这一点，我写都快写烦了。这样的好处在于，系统可以提供一个最小集，所有的元素都可以在这个集合里找到，这个集合里面的接口不包含任何策略性的东西，也就是说系统不限制编程者，当然这提高了编程者的技术门槛，毕竟一切都要自己来，但是这真的给了程序员极大的灵活性。可以实现 rpc 功能的套接字就是这个正交最小集合中的一员，用它来实现一个功能的话可能要自己组织数据结构，要自己发送，实在很麻烦，但是 unix 却认为这样很好；相反如果用 rpc 的话，可能仅仅需要一个函数调用就可以了，但是 unix 却很不推崇这种行为。

     在 windows 中，几乎一切都是用 rpc 实现的，这并不是说 windows 不好，而是 windows 的系统结构决定了它用 rpc 是不错的选择。在 windows 中，到处都是 c/s 模式的应用， windows 本身就是 C/S 模式架构出来的，在双方知根知底的情况下，用 rpc 是一个不错的选择，比用套接字或者其它的 IPC 机制要简洁不少，形式也比较统一，当然也有其弊端，比如不够稳定，客户端和服务器程序双向依赖等等，不过客户端和服务器同在一台机器上，依赖又如何呢？不过 windows 的 rpc 确实有很多不尽人意的地方，比如出了问题会连累很多无辜者，另外不够稳定。虽然 windows 想占 rpc 的便宜，但是天下没有免费的午餐，其对 rpc 维护的消耗加上出了问题后解决问题的繁杂带来的劣势已经掩盖了其带来的恩惠； unix 就不这样，什么也不想，一心坚持自己的哲学 -- 简单！再看看 unix 的信号，设置好信号处理函数后，信号就是一个通知，没有附带任何数据，数据和代码分来，这也是策略和机制分离的体现，数据就是策略，代码就是机制，这也是 unix 的哲学。