http://img1.tuicool.com/mUrY737.png!web

http://img1.tuicool.com/u2e6VjE.png!web

相比于当前流行的HTTP/JSON开发，RPC等同于在实现相同功能的前提下将服务和传输等细节封装好，实现一种业务代码对特定服务开箱即用的效果。

https://github.com/tencent-wechat/phxrpc

http://blog.csdn.net/shanshanpt/article/details/55213287

  • 使用Protobuf作为IDL用于描述RPC接口以及通信数据结构。
  • 基于Protobuf文件自动生成Client以及Server接口，用于Client的构建，以及Server的实现。
  • 半同步半异步模式，采用独立多IO线程，通过Epoll管理请求的接入以及读写，工作线程采用固定线程池。IO线程与工作线程通过内存队列进行交互。
  • New: 支持协程Worker，可配置多个线程，每个线程多个协程。
  • 提供完善的过载保护，无需配置阈值，支持动态自适应拒绝请求。
  • 提供简易的Client/Server配置读入方式。
  • 基于lambda函数实现并发访问Server，可以非常方便地实现Google提出的 Backup Requests 模式。

我感觉RPC的最大优势就是简单易用(所以常常这点会作为RPC框架评价的重要指标)，程序开发充斥着无数函数调用，能把远程服务作为像函数调用一样使用真是让程序员再开心不过了。还有，比如RPC->RPC->RPC这样的嵌套调用场景，其中任何一个步骤发生了问题，调用过程都可以失败方式返回，业务上的错误处理和回滚等操作也直接明了一些吧，但是如果在异步模式下的开发，除非记录相关状态，否则这种回溯是很麻烦的！