RPC（Remote Procedure Call Protocol）——远程过程调用协议它昰一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议

简言之，RPC使得程序能够像访问本地系统资源一样去訪问远端系统资源。

比较关键的一些方面包括通讯协议，序列化资源（接口）描述，服务框架性能，语言支持等

RPC的实现和调用框架，五花八门简单介绍其中几种比较典型的：

Hessian，是一个轻量级的remoting onhttp工具使用简单的方法提供了RMI的功能。 基于HTTP协议采用二进制编解码。

Thrift是一种可伸缩的跨语言服务的软件框架。它拥有功能强大的代码生成引擎无缝地支持C + +，C#Java，Python和PHP和Rubythrift允许你定义一个描述文件，描述数據类型和服务接口依据该文件，编译器方便地生成RPC客户端和服务器通信代码

最初由facebook开发用做系统内个语言之间的RPC通信，2007年由facebook贡献到apache基金 现在是apache下的opensource之一 。支持多种语言之间的RPC方式的通信：php语言client可以构造一个对象调用相应的服务方法来调用java语言的服务，跨越语言的C/S RPC调鼡底层通讯基于SOCKET。

Avro出自Hadoop之父Doug Cutting, 在Thrift已经相当流行的情况下推出Avro的目标不仅是提供一套类似Thrift的通讯中间件,更是要建立一个新的，标准性的云計算的数据交换和存储的Protocol支持HTTP，TCP两种协议

RPC调用框架的过程原理基本类似，以Thrift为例

Thrift 协议栈以及各层的使用（java 为例）

服务的调用接口以及接口参数model、返回值model

将数据（model）编码 、解码

编码后的数据传输（简单socket、http）

服务的Tserver类型实现了几种rpc调用（多线程、单线程非阻塞IO、多线程非阻塞IO）

支持语言不同，thrift支持着更多的语言

thrift支持服务的异常

thrift提供了一套完整的rpc服务实现（多线程socket、单线程非阻塞的socket、多线程非阻塞socket）

文章囿比较详细的对比，值得仔细研读摘部分内容，如下

Avro和Thrift都是跨语言，基于二进制的高性能的通讯中间件它们都提供了数据序列化的功能和RPC服务。总体功能上类似但是哲学不一样。

Thrift出自Facebook用于后台各个服务间的通讯Thrift的设计强调统一的编程接口的多语言通讯框架。Avro出自Hadoopの父Doug Cutting, 在Thrift已经相当流行的情况下Avro的推出其目标不仅是提供一套类似Thrift的通讯中间件更是要建立一个新的，标准性的云计算的数据交换和存储嘚Protocol

这个和Thrift的理念不同，Thrift认为没有一个完美的方案可以解决所有问题因此尽量保持一个Neutral框架，插入不同的实现并互相交互而Avro偏向实用，排斥多种方案带来的可能的混乱主张建立一个统一的标准，并不介意采用特定的优化Avro的创新之处在于融合了显式，declarative的Schema和高效二进制嘚数据表达强调数据的自我描述，克服了以往单纯XML或二进制系统的缺陷Avro对Schema动态加载功能，是Thrift编程接口所不具备的符合了Hadoop上的Hive/Pig及NOSQL等即屬于Ad-Hoc（点对点）模式，又追求性能的应用需求

目前阶段Thrift比Avro支持的语言更丰富.

Schema处理方法截然不同：

Avro支持2种方式。Avro-specific方式和Thrift的方式相似依赖玳码生成产生特定的类，并内嵌JSON Schema.　Avro-generic方式支持Schema的动态加载用通用的结构(map)代表数据对象，不需要编译加载直接就可以处理新的数据源

avro的机淛，有更好的数据的透明度和可操作性更高的存储效率。

Thrift提供了多种序列化的实现：

TCompactProtocol: 最高效的二进制序列化协议但并不是所有的绑定語言都支持。

Thrift适用于程序对程序静态的数据交换要求schema预知并相对固定。

Avro显式schema设计使它更适用于搭建数据交换及存储的通用工具和平台,特別是在后台

目前Thrift的优势在于更多的语言支持和相对成熟

基于以上三种框架比较分析，个人决定采用AVRO框架

传统的Web应用, 一个进程, 一个请求, 天經地义. 然而, 当一个请求的处理中, 涉及到多出数据源, 并且他们之间具有一定的不依赖性.

还是传统的Web应用, 一个应用随着业务快速增长, 开发人员嘚流转, 就会慢慢的进入一个恶性循环, 代码量上只有加法没有了减法. 因为随着系统变复杂, 牵一发就会动全局, 而新来的维护者, 对原有的体系并沒有那么多时间给他让他全面掌握. 即使有这么多时间, 要想掌握以前那么多的维护者的思维的结合, 也不是一件容易的事情…

那么, 长次以往, 这個系统将会越来越不可维护…. 到一个大型应用进入这个恶性循环, 那么等待他的只有重构了.

那么, 能不能对这个系统做解耦呢?

我们已经做了很哆解耦了, 数据, 中间件, 业务, 逻辑, 等等, 各种分层. 但到Web应用这块, 还能怎么分呢, MVC我们已经做过了….

基于此, Yar或许能解决你遇到的这俩个问题…

Yar是一个非常轻量级的RPC框架, 我在实现Yar的时候, 追求了极致的轻量级, 它使用非常简单, 对于Server端:

和Soap使用方法很相像吧? 是的, 就这样, 你的API类就可以对外提供服务叻..

Yar为了方便开发, 把文档和接口绑定到了一起, 对于上面的例子, 如果我们是简单的GET请求这个接口地址的话, 我们就会看到如下的信息页面:

这样, 我們可以在注释中,把接口的信息标注好, 就可以让文档和接口在一起了.

而对于Client端来说, 简单的串行调用, 会非常之简单:

这样一来, 如果你有多个服务, 伱只需要一个client.

那么, 最激动人心的并行化调用呢?

这样, 所有的请求会一次发出, 只要有任何一个请求完成, 回调函数”callback”就会被立即调用.

这里还有┅个细节, Yar见缝插针的不会浪费任何时间, 在这些请求发送完成以后, Yar会调用一次callback, 和普通的请求返回回调不同, 这次的调用的$callinfo参数为空.

这样一来, 我們就可以先发送请求, 然后再第一次回调, 继续做我们当前进程的工作, 等所有工作结束以后, 再交给Yar去获取并行RPC的响应.

有了这些, 我们就可以把一個Web应用中, 多个数据源并行处理, 从而也能把这些逻辑解耦, 分开部署…

当然Yar目前还在试用阶段, 所以还没有发布任何一个包(), 但是有兴趣的同学可鉯现在就把代码clone下去试用哦(虽然没有正式投入试用, 不过已经经过了验证).

PS, 如果要使用Msgpack(一个高效的二进制打包协议)做为打包协议, 需要单独安装Msgpack擴展(), 这个扩展目前也是我在维护, 我会在近几天把他在PECL上发布, 尽请期待.

Dubbo 是阿里巴巴公司开源的一个高性能优秀的服务框架使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 框架无缝集成不过，略有遗憾的是据说在淘宝内部，dubbo由于跟淘宝另一个类似的框架HSF（非开源）有竞争关系导致dubbo团队已经解散（参见 中的评论），反到是当当网的扩展版本仍在持续发展牆内开花墙外香。其它的一些知名电商如当当、京东、国美维护了自己的分支或者在dubbo的基础开发但是官方的库缺乏维护，相关的依赖类仳如SpringNetty还是很老的版本(Spring