RPC发展脉络整理

最近看了些rpc相关的背景知识，为了响应coolshell对技术的态度一文，试图将知识点串起来，推导出发展脉络。

涉及的关键字有：

• rpc
• xml-rpc/soap -> web service -> SOA -> 分布式服务的实现
• 标记语言之间的衍生关系：sgml/html/xml
• xml的配套设施：xsd/xpath/xslt
• json-rpc
• 轻量的rpc架构风格：rest/restful api

综上，大致的脉络如下：

远程过程调用（rpc）是个古老的议题（自70年代）,目的是为了解决程序远程交互的问题（如调用数据库的存储过程？）。由于是远程交互，不可控的因素增多了（像分布式事务之类的就没有单机事务处理起来容易，另外还要考虑异构系统间通信、如何跨平台等），导致rpc的完备实现具有较高门槛。

rpc根据序列化的载体不同出现了两个方向，且各自优缺点也很明显。

• 纯文本序列化载体（跨平台、人机可读性等）
• 二进制序列化载体（时空两个维度的高效等）

微软和IBM为什么要推xml和web service？（接下来是我的yy…）

最早用得起大型机、数据库的都是银行、电信这样的大亨（大多IBM的客户），所以IBM在这方面肯定有些积累；后来微软也开始给有钱的中小企业做信息化解决方案（所以才会有跑在pc 和windows上的sql server）。随着信息化的普及，大中小企业之间会有业务往来，需要打通各自的系统，于是面临异构系统交互的问题。一方面这决定了只能以纯文本作为序列化载体，另一方面，反正都是给这些有钱的主服务，微软和IBM一拍即合，开始推xml和以xml为主要载体的web service以承载企业间rpc。（注意到xml是IBM自60年代开始研发的GML标准化后的简化版，它和html是同源的，在简化的过程中还借鉴了html的发展经验。）由于IBM的服务的是银行这样数据量大且精度要求很高的对象，其rpc实现方案必然完备，且不可避免的重量级；好处是xml还有许多完善的配套设施：如用于查询的xpath；用于规范和验证的xsd；用于转换格式的xslt等等。

xml成为w3c标准是98年的事，也正好是google发迹的年代。此后google实现了用海量pc取代小型机提供服务的思路，互联网业界纷纷效仿。再后来，pc集群越堆越大，其粒度也切细到了提供某项服务（如memcached集群，专门提供缓存服务），以适应分工细化、各自伸缩的需求。越来越多这样的服务催生了SOA，随着服务化的推进，一方面开发人员希望能由rpc框架封装掉交互的细节，使得代码看起来就像本地调用一样简单；另一方面，互联网企业内部可以统一接口，采用二进制作为序列化载体显然更划算，因此hession等有了市场。

近几年，由于sns化和open平台交互的需要，各大网站纷纷推出自己的open api。ajax已经普及，大家自然想到了用json作为载体，在浏览器这头好歹比用xml要和谐得多。另外，互联网业务不同于传统金融电信业务，在业界大佬亚马逊等的示范下，简单、直观、轻量且能自然契合http的restful api受到追捧，于是形成了现在的局面……