RPC的未来在哪里？

虽有这些问题，但RPC并未消失。在编码基础上构建了各种RPC框架：

• Thrift和Avro带有RPC支持
• gRPC使用Protocol Buffers的RPC实现
• Finagle也使用Thrift
• Rest.li使用JSON over HTTP

这种新一代RPC框架更加明确远程请求和本地方法调用是不同的。如：

• Finagle和Rest.li 使用Futures（Promises）封装可能失败的异步操作。Futures还可简化需并行请求多服务并将结果合并的场景
• gRPC支持流，其中一个调用不仅包括一个请求和一个响应，还可以是随时间的一系列请求和响应

一些框架还提供服务发现：允许客户端找出在哪个IP地址和端口可找到特定服务。

使用二进制编码格式的自定义RPC协议可实现如REST上的JSON之类的通用协议更好的性能。但RESTful API还有其他优点：方便实验和调试（只需使用Web浏览器或命令行工具curl，无需代码生成或软件安装），能被所有主流语言和平台支持，还有丰富工具（服务器，缓存，负载平衡器，代理，防火墙，监控，调试工具，测试工具等）生态系统。

由于这些原因，REST似乎是公共API的主流风格。 RPC框架的主要侧重于同一组织内多个服务之间的请求，通常在同一IDC。

RPC 的数据编码与演化

可演化性，重要的是独立更改和部署RPC客户端和服务器。与基于DB的数据流相比，可做个简化假设：假定所有服务器都先被更新，其次是所有客户端。因此，只需在请求上具有向后兼容性，且对响应具有前向兼容性。

RPC方案的向前和向后兼容性属性取决于它具体编码：

• Thrift，gRPC（Protobuf）和Avro RPC可根据相应编码格式的兼容性规则进行演变
• SOAP，请求和响应是使用XML模式指定。这些可以演变，但有一些微妙陷阱
• RESTful API通常使用JSON用于响应，请求则使用JSON或URI编码/表单编码的请求参数。为保持兼容性，一般考虑添加可选的请求参数、向响应对象添加新字段

若RPC经常用于跨组织边界的通信，则服务兼容性会更困难，因此服务的提供者经常无法控制其客户，也不能强迫他们升级。因此，需长期保持兼容性，也许无限期。若不得不进行一些破坏兼容性的更改，则服务提供者通常会同时维护多个版本的服务API。

对API版本管理应该如何工作（即客户端如何指示它想要使用哪个版本API）没有统一方案：

• 对RESTful API，一般在URL或HTTP Accept头使用版本号
• 使用API密钥来标识特定客户端的服务，另一种选择是将客户端请求的API版本存储在服务器，并允许通过单独的管理界面更新该版本选项