云服务 为什么用 RPC

betterthornbird · 2016年07月13日 · 最后由 adamshen 回复于 2016年08月03日 · 10424 次阅读

也不知道放云服务节点对不对。

目前项目组准备做微服务,微服务之间的沟通可以使用 RPC 或者 Rest,于是开始花时间研究。

昨天 Ruby Tuesday 跟人聊,RPC 的好处可以包括使用简洁,像用本地方法一样调用远程。第二是一切接口按照 interface file 来,不太会出问题。 相比 Rest,我个人认为,Rest apis 调用在日常代码中使用很多,写起来也没有觉得烦,有了文档,调用也不太会出错,API 版本管理也简单。

我自己觉得 RPC 比 Rest 看不出明显优势。

著名的Building Microservices里面反而是列了 RPC 好多坑和缺点。包括:

  1. Marshal and unmarshal cost could be significant.
  2. Remote call does not like local call, network could be not reliable.
  3. Need to regenerate interfaces/stubs, and deploy both server/client changes, if there is any change of interface file.

昨天问一个小哥跟我聊,为什么用 RPC,他说,老大喜欢😲 各位用了 RPC 来说说为什么用 RPC,来反驳反驳我吧。

试试这个,公司打算用 https://github.com/micro/go-micro

如果是用 Java 开发的话,用 RPC 挺好的,Java 有 RMI。

rpc 也没有问题啊,thrift 就算 rpc 架构吧

其实用 grape 直接生成 swagger 也很不错,就是坑挺多,我以后会尝试 grpc

#1 楼 @fate 其实我还是想知道你们选用 RPC 的时候为什么选这个

这两年热

热的是 micro service

@vincent 可以就这个事情说下你当时技术选型时候的想法吗?谢谢。

Marshal and unmarshal cost could be significant.

REST 的 JSON 序列化性能消耗才更加明显,除非都是 string

Remote call does not like local call, network could be not reliable.

REST 也不能解决这个问题

Need to regenerate interfaces/stubs, and deploy both server/client changes, if there is any change of interface file.

REST 也存在接口升级的问题,现在 REST 也会从 raml/swagger 生成 stub code。

REST 的好处在于接口的可读性,但是也有接口粒度过细的缺点。RPC 则是牺牲了灵活性增强了性能。两者各有千秋,总之听领导的。

RESTful 不就是一种 RPC 的实现方式么...

#9 楼 @nouse 多谢。我在想前两个缺点是在指出 RPC 绝对做不到 Local Call,第三个的话是指说改动的时候麻烦。

来说说性能增加,我能想到的,第一是 RPC 可以基于其他的 protocol 不走 HTTP;第二是可以使用类似 proto buffer 来打包和解包数据,比纯 Json 的要好。其他还有增加性能的点吗?不过用其他协议实现以及不用 Json 做数据格式,是要花额外的开发时间。

#10 楼 @jasl 哈哈是可以这么理解。从更高层次,就是网络上传输数据嘛。不过从我的理解,不管是观念还是实现方式,大家还是区分这两个的。

上面说的 network 问题,我猜是指基于长连接 TCP 的 RPC 吧,要考虑重连的机制,虽然一般框架会考虑到,但能否支持常见语言就难说了,那么对异构系统的友好度就差点。

基于 HTTP 好处:水平扩展性,异构支持,测试便利性(curl, postman),debug 的便利性 基于 JSON 的好处:可读性,相关的生态好,数据不需转换便可被第三方消费

@betterthornbird 支持你,如果不用 RESTful,我觉得要有很强烈的理由。REST 的话推荐一个 jsonapi http://jsonapi.org/implementations/ 已经有很多实现了,另外,GraphQL 也是一个可选项。

#14 楼 @qianthinking 谢谢。参考下。你们那拆微服务了嘛?

按 微服务 那书上的说的,优先用 RESTful

#17 楼 @vincent 可以单独开一遍文章具体说说怎么样做好 ” 应用拆分和微服务化改造,最初完全是以 RESTful API 完成不同微服务之间通信 “ 很多公司其实这步还未迈出哈。。。

#15 楼 @betterthornbird 小帅哥刚在 AWS 上折腾上 kubernetes,微服务在规划,正好跟着基础架构一步步上。

21楼 已删除

#17 楼 @vincent 基于 MQ 的 RPC 对事务支持咋样?

#19 楼 @jayliud 其实去年做过两次的 topic 分享,都是关于这个主题的,:)

#23 楼 @wangder 没有事务支持,分布式事务都比较复杂,如果真的需要,需要自己做接口支持,也就是说提供恢复操作接口,由自己控制。

#24 楼 @vincent 有 ppt 吗?好像没有找到。。。

#26 楼 @jayliud 今年打算在 RubyConf China 做一个 Rails 微服务化的主题演讲,敬请期待!

Coding 已经在生产环境大量使用 grpc + protobuf 作为内部通信的框架和协议,我们最初的 rpc 实现也是构建在 protobuf 上的,但只支持 java,后面发现项目越大使用的语言越多,跨语言通信成了一个问题,刚好那时候 grpc 也开源了,我们就慢慢的从一些小的服务开始切换到 grpc 上,目前大部分内部组件通信已经是通过 grpc 进行了。

我们最初采用 grpc 的目的就是为了规范接口代码和多语言支持,还有它的社区和开发也比较活跃。

简单列举一些优缺点和对比:

  • 使用 protobuf 作为序列化库, 专门的 IDL 语法也使得接口定义更加简洁规范了,protobuf 内置支持兼容性处理,proto3 支持 json 序列化,更容易和其它系统交互;
  • 原生支持各种编程语言,加上自动生成 rpc 的服务器端和客户端代码框架,省去了自己编写的麻烦,把更多精力放到业务逻辑实现上;
  • 底层数据传输基于 HTTP/2,所以也会带来 flow control, header compression 等 HTTP/2 特性,数据传输还支持压缩、加密、重试(支持 Backoff)等,性能相应该会有一定提升(没有做测试);
  • 原生的 负载均衡 支持,更加方便扩容(此功能目前已设计完毕,并不是所有语言都已完全实现,所以我们目前使用的还是是自己的实现);
  • 开发调试就不像 REST 接口那样有很多现成的命令行或图形界面工具可以使用,grpc 的数据通信传输的是二进制的 protobuf 数据,不利于调试,而且 grpc 的 cli 还不够完善,所以我们测试基本上都是通过写代码进行的;
  • 作为吃螃蟹的人,肯定是会踩到一些坑的,我们在使用过程中也遇到了一些问题,但没有特别严重的。

grpc 目前还处于 Beta 阶段,但对外的 API 已经稳定,而且已经有很多知名项目在采用了,比如 etcd v3 和 docker containerd

#28 楼 @tsl0922 谢谢分享,让我也了解到 gRPC 慢慢成熟和被采纳。

gPRC 看起来很不错哦!

靠 rpc 去推动服务化容易掉进服务分层的坑里,如果拆分不谨慎,后期会发现做需求调整时需要一调调三层,出问题要挨个去定位

#28 楼 @tsl0922 rpc 用 protobuf 序列化深受其害啊,bug 定位,调试都好难

可以用在同一个 host 下多个 worker 之间的 routing

35楼 已删除
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册