真正好用的RPC框架rest_rpc正式发布第一个版本

rest_rpc是由c++开源技术社区(purecpp.org)创建和发起的项目,在经过多次迭代和重构之后,终于发布第一个版本了。rest_rpc是modern c++开发的一个易用、灵活、跨平台和高性能的RPC框架。和国内外一些大公司开发的RPC框架相比,rest_rpc有哪些特色呢?

rest_rpc的特点

rest_rpc具备下面几个特点

  • 真的像本地函数一样调用
  • 使用简单,用户只需要关注业务即可
  • 灵活,RPC调用的序列化方式可以自由定制,比如支持json,支持msgpack等方式
  • 支持同步和异步调用

这几个特点也是之前的文章里提到的评价一个RPC是否好用的标准,无疑rest_rpc完全符合这些标准,是一个真正好用的RPC,并且还走得更远。

传统的网络库处理业务逻辑的过程一般分为5步:

  1. 接收网络数据;
  2. 解析网络数据;
  3. 调用业务逻辑;
  4. 打包结果;
  5. 发送数据;

如果使用rest_rpc,就只有1步了

1.只需要调用业务逻辑(其他的框架都帮你做好了)。

rest_rpc提供一站式服务,将1,2,4,5步完全省略掉,让用户只用关注第3步的业务逻辑即可,省心省力!如果用户之前用到了其他的网络库,想换成rest_rpc也很简单,不需要做任何修改,只要把业务逻辑函数注册一下就行了,可以直接复用,什么都不用改,省心省力!

rest_rpc的最主要的特点是好用,用户只需要像本地调用那样去调用RPC服务接口,无需关注框架和网络的细节既可以实现远程调用,只需要关注自己的业务逻辑即可。除了易用的特点之外,rest_rpc还具备很好的灵活性,用户可以选择RPC序列化的方式,还支持自定义的序列化方式。

rest_rpc的使用

我们以一个最简单的例子来展示如何使用rest_rpc,这个例子中,服务器提供了一个 int add(int a, int b) RPC服务接口,客户端通过RPC调用获取远程调用的结果。

  • 服务器端代码

  • 同步客户端代码

至此,一个RPC程序就完成了,无论是服务器还是客户端,代码都非常少,总共都不到10行代码,用户只需要关注业务逻辑即可,无需关注网络或者框架细节,而且和调用本地函数一样,非常好用,没有任何限制。

  • 异步客户端代码

一个更复杂的例子

这个例子将展示RPC接口中含有二进制数据的情况,有些RPC框架如果要支持二进制的话,需要将二进制做一些转换,比如base64转换之类的,rest_rpc支持原始的二进制数据,无需做任何转换。

  • 服务器端代码

  • 客户端代码

使用方式还是那么简单,自然,因为rest_rpc框架已经帮你做了绝大部分事情了。

rest_rpc编译

rest_rpc是由c++14编写的,因此需要支持C++14的编译器,windwos上需要vs2015, linux需要gcc5.0+, 除此之外还用到了boost,因此还需要boost库。

RPC调用需要注意的地方

需要注意的地方主要是就是客户端需要做异常处理,因为RPC调用可能会失败,出错的原因比较多,可能是客户端和服务器的连接断开了,也可能是服务器没有提供这个RPC服务,也可能是服务器提供的RPC服务发生了异常。总之,rest_rpc框架会将错误码和出错信息作为异常抛出来。所以更完整的做法是在call之外捕获一下异常,做异常处理。

此外,服务器在默认情况下是在io线程中执行业务函数的,如果用户需要执行一个非常耗时的操作,rest_rpc提供了一个异步执行业务函数的接口。

异步客户端

同步客户端会阻塞调用call的线程,虽然简化了逻辑但是也降低了性能。rest_rpc也实现了异步客户端,接口也很好用。

  • 异步客户端示例

  • 异步客户端同步接口
    异步客户端除了纯异步以外,还有同步接口,可以让用户选择在何时阻塞。

性能测试

rest_rpc的性能很高,下面是用异步客户端对add RPC服务接口做的性能测试结果,因为RPC是请求-响应模式,所以实际上做的是含有业务逻辑的pingpang测试,包括数据解包、业务执行、结果打包发送的过程。

上面是在一台12核(主频2.4G)24线程的服务器上测试的,qps为46万时,cpu占用63%左右。

代码质量

下面是用工具检测的代码质量图

代码的可读性较好。

如果你仅仅需要RPC的话,看到这里就可以不用往下看了

如果你还有更多期待,请往下看。

还有点其他的什么吗?

是的,还有一些特别的东西,rest_rpc不是仅仅提供了一个RPC功能而已,还提供了更有趣的功能,比如订阅-发布!是的,你没看错,rest_rpc具备pub/sub功能,也许有人会觉得奇怪,为什么RPC框架会提供订阅-发布功能呢。其实,RPC和订阅-发布是有相通的地方。RPC可以看作是一个特殊的订阅-发布模式,即订阅者和发布者都是自己,而订阅-发布模式又可以看作是一个特殊的扩展了的RPC,即发起RPC调用的人和接收RPC调用结果的人是不同的人。正是看到了这种相通性,rest_rpc顺手就实现了订阅-发布模式。订阅-发布模式用起来也很简单,和RPC调用差不多,下面来看一个订阅发布的例子。

  • 服务器端代码

  • pub客户端代码

鉴于pub和sub天然的异步属性,我们只在异步客户端实现了这个接口,同步客户端暂不支持

  • sub客户端代码

订阅发布还是那么简单。rest_rpc相比其他的RPC框架,不仅仅提供了更加易用、灵活的RPC接口,还提供了额外的订阅发布功能,而且订阅-发布可以和RPC调用随时结合起来使用,使得RPC和订阅-发布的功能更加强大。

《真正好用的RPC框架rest_rpc正式发布第一个版本》有6个想法

  1. 如何评价一个RPC框架为“好用”?我觉得“好用”的标准至少是实用和能用。为何谷歌、fb、tencent要把rpc设计成那样?我觉得作者应该好好的思考,而不是闭门造车,自己认为好用而无法实用。

    1. 呵呵,这个不是闭门造车,正式看到这些RPC的不足之处,才会出现rest_rpc,你可以参考之前rest_rpc的架构思想。也可以看看之前的一篇文章“什么样的RPC才是真正好用的RPC”,该文定义了好用的几条标准。
      另外不知道你指的实用是什么,事实上rest_rpc已经投入到生产环境中了,并且用得很好,另外工程性问题都可以持续演进变得更加完善,目前rest_rpc才出第一个版本,未来会越来越强大和完善。
      还有,并不是大公司做的东西就一定是优秀的,也不是他们做了别人就不能做,技术只论品质而不论出自哪个公司,就和技术人一样。

  2. 看了楼主设计的 rest_rpc,感觉跟 hprose 很像,最大的不同是 hprose 是跨语言的,目前支持 25种以上的常用语言。但是目前 hprose 的 C++ 版本还缺少服务器,目前急需楼主这样的 C++ 大牛来实现它,所以想问一下楼主是否愿意一起来做 hprose 这个开源项目啊?

发表评论