云服务 为什么用 RPC
也不知道放云服务节点对不对。
目前项目组准备做微服务，微服务之间的沟通可以使用 RPC 或者 Rest，于是开始花时间研究。
昨天 Ruby Tuesday 跟人聊，RPC 的好处可以包括使用简洁，像用本地方法一样调用远程。第二是一切接口按照 interface file 来，不太会出问题。 相比 Rest，我个人认为，Rest apis 调用在日常代码中使用很多，写起来也没有觉得烦，有了文档，调用也不太会出错，API 版本管理也简单。
我自己觉得 RPC 比 Rest 看不出明显优势。
著名的Building Microservices里面反而是列了 RPC 好多坑和缺点。包括：
- Marshal and unmarshal cost could be significant.
- Remote call does not like local call, network could be not reliable.
- Need to regenerate interfaces/stubs, and deploy both server/client changes, if there is any change of interface file.
昨天问一个小哥跟我聊，为什么用 RPC，他说，老大喜欢
各位用了 RPC 来说说为什么用 RPC，来反驳反驳我吧。
rpc 也没有问题啊，thrift 就算 rpc 架构吧
其实用 grape 直接生成 swagger 也很不错，就是坑挺多，我以后会尝试 grpc
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 则是牺牲了灵活性增强了性能。两者各有千秋，总之听领导的。
上面说的 network 问题，我猜是指基于长连接 TCP 的 RPC 吧，要考虑重连的机制，虽然一般框架会考虑到，但能否支持常见语言就难说了，那么对异构系统的友好度就差点。
基于 HTTP 好处：水平扩展性，异构支持，测试便利性（curl, postman），debug 的便利性 基于 JSON 的好处：可读性，相关的生态好，数据不需转换便可被第三方消费
@betterthornbird 支持你，如果不用 RESTful，我觉得要有很强烈的理由。REST 的话推荐一个 jsonapi http://jsonapi.org/implementations/ 已经有很多实现了，另外，GraphQL 也是一个可选项。
薄荷是很早（4 年前）就开始进行应用拆分和微服务化改造，最初完全是以 RESTful API 完成不同微服务之间通信的。 在一年前开始引入 RPC，但用的不是传统的 RPC，而是基于消息中间件 RabbitMQ 的 RPC , 这样做的主要的原因有：
- 1.安全，内部 API 和外部 API 完全隔离，避免混淆；
- 2.统一，统一处理异步任务，广播和同步调用三类最常见消息模式，都走 MQ；
- 3.性能，有一些改善。
没有用传统 RPC 是因为：和 Java 比起来 Ruby RPC 这块的基础组件弱爆了，即使看似最成熟的 Apache Thift rubygem 都象是玩具，其它就更不用提了。用 Ruby 实现传统 RPC 麻烦的地方不在于消息协议处理，而在于一系列配套基础设施，比如服务并发，高可用，部署和监控一堆东西都没有现成的，需要自己造。
我刚开始原本打算用 sidekiq 更改出一套支持三类消息通信的方案，后来发觉这样做的话服务间耦合太紧了，另外过于绑定在 Ruby 语言上，所以放弃了。后来发现一个叫 Sneakers 的东东，其实和 Sidekiq 非常类似，提供完整的异步任务处理机制，只不过把 Redis 换成了 RabbitMQ，因为用了专业的消息中间件，增强处理广播和 RPC 变得比较简单。我就在它的基础上开发了 SneakersPacker 完成一套统一异步任务，广播和同步调用（RPC）的方案。
这个组件是开源的，项目代码在 http://github.com/xiewenwei/sneakers_packer，目前已经在我们生产跑了比较长时间，还是比较稳定的。
虽然我们现在用的方案中有 RPC，但是依然认为绝大部分情况用 RESTful API 就够了的，这样简单方便，除非有充分理由才用，才需要引入更复杂的方案。
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。
