How to choose an appropriate RPC framework

作者：禅与计算机程序设计艺术

1.简介

RPC被称为远程过程调用技术，在分布式计算领域中占据重要地位。它旨在通过网络服务实现各服务间便捷通信，并且无需深入了解网络通信机制即可完成功能部署与协作。通过简单的配置即可建立高效的通信通道

尽管RPC具有极强的功能性和广泛的适用性,但各框架之间仍存在显著差异。例如,在性能、稳定性、可用性和扩展性等方面表现各异。以下将详细介绍7种流行的RPC框架:基于TCP/IP协议实现的RPC、gRPC、Apache Thrift、Hessian（支持多线程与消息队列）、Dubbo（Java面向服务架构扩展版）以及基于HTTP协议的RESTful RPC等。

希望这篇文章能促进大家深入理解并选择合适的RPC框架，并从而完成相应的技术选型工作。

2.Basic Concepts and Terms

2.1 什么是RPC？

首先要明确的是什么是RPC。RPC，Remote Procedure Call，中文译作“远程过程调用”，是分布式系统间远程通信的一种技术。其目的是通过在远程服务端暴露一个特定的接口，然后客户端可以通过该接口与服务端进行交互。因此，客户端无需显式地直接与服务端通讯，通过调用本地的远程过程，即可达到与服务端的交互目的。RPC框架通常基于以下几点实现：

• 服务发现：使客户端可以在服务注册中心查找服务端信息，从而减少硬编码的服务端地址；
• 负载均衡：通过负载均衡策略将请求均匀分派至多个服务器上，提高系统的处理能力；
• 认证授权：保证客户端访问安全，避免非法或未经授权的访问；
• 传输协议：支持多种协议，如TCP/IP、HTTP等；
• 序列化协议：支持多种数据格式，如XML、JSON、Protobuf等。
  在RPC框架中，客户端向远程服务端发送一个调用请求消息，该请求消息包含了方法名、参数列表及其他一些调用信息，其中参数列表可能包含了序列化后的数据。服务端收到请求消息后，会根据方法名找到对应的方法执行，并返回结果给客户端。
  RPC主要解决的问题是分布式系统间如何通信。由于分布式系统由不同的计算机组成，这些计算机之间只能通过网络进行通信。因此，如果要让不同计算机上的服务相互调用，就需要借助RPC这种技术。
  目前，已经有很多开源的RPC框架。本文介绍了7种流行的RPC框架，分别基于TCP/IP协议、基于HTTP协议的RESTful RPC、gRPC、Apache Thrift、Hessian、Dubbo、RMI。对于每种RPC框架，我都提供了它们的基本特性、优缺点以及适用场景。读者可以依据自己的业务需求以及对各框架特性的理解，选择最合适的RPC框架。

2.2 为什么要用RPC？

2.2.1 分布式系统

大型分布式系统通常由多个计算节点构成，在实际运行中不仅要求各节点之间具备良好的通信能力，并且还需要具备高度的协调能力以确保系统的稳定运行。若要实现高效的分布式计算功能，则必须依靠诸如分布式事务管理机制或消息队列等基础功能的支持；否则的话，在缺乏这些关键组件的情况下进行大规模的数据传输很可能导致通信过程中的各种错误与性能瓶颈。
此外，在实际应用中为了提高系统的整体性能与开发效率往往会选择采用远程过程调用技术；这种技术不仅可以有效降低各系统之间的耦合程度还能使整个系统的架构更加模块化和易于扩展；而RPC技术则允许跨进程、跨设备甚至跨数据中心进行高效的分布式数据访问与通信；这种设计无疑大大降低了系统的复杂度和开发难度。

2.2.2 性能优化

当前互联网系统承载着庞大的用户群体，在线服务需求也呈现爆发式增长。为了应对日益激增的访问量带来的压力挑战，在服务器集群上实现显著提升了整体处理能力的同时也确保了后端服务能够持续稳定运行。通过采用RPC技术不仅能够充分利用服务器集群资源还能通过异步调用缓存技术和智能流量控制等手段进一步增强了系统的吞吐量和抗压能力

2.2.3 微服务

随着网站业务规模的增长, 系统逐渐被细分为若干个独立的服务模块. 这种拆分使得整个应用架构逐渐变得复杂而庞大. 采用RPC协议作为基础, 应用系统实现了与其他服务之间的灵活调用, 显著提升了系统的复用能力和扩展性. 为了进一步优化系统性能, 我们通过建立完善的治理机制、实施服务注册与发现机制, 有效降低了各服务之间的相互依赖关系, 增强了系统的容错能力和整体稳定性.

2.2.4 易编程

在技术交流中跨越语言障碍，在线沟通不再受阻。通过集成RPC技术, 开发者能够更加专注于业务逻辑的设计, 而无需深入关注远程服务调用的具体实现细节, 这一创新方法显著提高了编程效率和系统响应速度。

3.Introduction of Commonly Used RPC Frameworks

下面介绍7种常用的RPC框架。

3.1 gRPC

gRPC是由Google提供的一个高性能且通用的消息传递协议（protocol），其核心功能是基于Protocol Buffers实现服务接口定义（Interface Definition Language, IDL）。

3.1.1 特征

• 采用HTTP/2协议作为底层传输介质，并展现出优异的传输性能；
  • 系统具备双向流式通信能力，并可容许长尾延迟的实时通信连接；
  • 基于IDL语言定义服务接口，并提供完善的类型校验机制及代码自动生成功能；
  • 系统集成内置身份验证机制、权限控制功能以及加密通信技术，并配备负载均衡模块。

3.1.2 优点

• 基于协议buffers技术的IDL框架能够自动实现Stub和客户端接口。
  • 通过内置的代码生成器能够自动生成所需代码框架，并有效降低开发者的编写负担。
  • 系统完全兼容多种编程语言（如C++、Java、Python、Go和JavaScript）。这使得开发者能够在不同平台上轻松部署应用。
  • 系统具有良好的兼容性特性，并可无缝集成现有基于TCP的消息传递系统的架构。
  • 系统能够实现客户端与服务端之间的双向数据流传输。
  • HTTP/2传输层在处理高延迟和大规模并发请求方面表现出色。

3.1.3 缺点

*gRPC是Google主导者之一，在其起源团队源自谷歌的情况下仍可能面临技术挑战；
该技术在内部工程实践上存在一定的局限性；
不适宜用于对高性能需求较高的实时通信系统。

3.2 Apache Thrift

Apache Thrift是一种高效率且具备良好扩展性的跨编程语言服务开发平台，并提供多种编程语言的客户端应用程序。

3.2.1 特征

• 跨平台兼容性；
  • 具备良好的扩展性；
  • 支持多种编解码格式（如JSON、Binary、Compact Binary等）；
  • 提供两种服务定义语言选项：一种是.thrift（旧版本），另一种是.proto（新版本）。

3.2.2 优点

• 提高编译效率；
  • 该代码生成器支持多种编程语言（如C++、Python），从而使得开发者可以选择最熟悉的语言来构建服务；
  • 支持多种数据存储方式（如表单、列表），满足不同场景的需求；
  • 允许选择不同的通信协议（如TCP/IP、HTTP/2），以适应不同的网络环境需求。

3.2.3 缺点

• 生成的代码存在较高程度的冗余，并涉及构建模块中使用了模板文件以及数据组织方式；
  • 学习曲线较为陡峭，并且主要适用于具备丰富开发经验的应用场景。

3.3 Hessian

Hessian遵循二进制Web Services标准作为远程调用协议。该协议由Facebook开发，并于2001年被选定为JavaScience论坛（JSF）的推荐标准。

3.3.1 特征

• 使用二进制协议进行数据传输。
  • 兼容Java语言的应用开发。
  • 采用一种精简高效的数据编码方案，在保证数据完整性的同时占据存储空间较少。
  • 系统支持基于SSL的安全通信机制。

3.3.2 优点

• 基于采用二进制通信协议的方式运行, 该方法的运行效率显著提升;
  • 多种语言支持包括Java、PHP和Python等;
  • 通过SSL认证机制实施的数据传输能够有效抵御中间人攻击.

3.3.3 缺点

• 只支持 Java语言，不能用于其他语言；
• 不支持浏览器环境下的Java Applet。

3.4 Dubbo

Dubbo 是 Alibaba 开发的一款开源的服务框架, 其特点包括高性能与透明化. 该框架允许应用程序利用高性能 RPC, 动态代理以及自动注册与发现功能实现无缝接入分布式环境.

3.4.1 特征

• 采用了高性能的NIO网络架构；
  • 支持多种分布式系统框架如Zookeeper、Redis和Multicast等；
  • 提供多样化的通信协议支持包括Dubbo、RMI、Hessian和HTTP；
  • 官方文档明确表示'已在实际生产环境中得到广泛应用'。

3.4.2 优点

• 该产品在全方位、便捷的功能设计与多样化的配置方案上表现突出，并且官方配备了多种功能完善的支持工具；
• 在微服务架构环境下, 服务治理能力的重要性不可忽视。
• Spring Cloud Alibaba采用了Dubbo协议进行开发。

3.4.3 缺点

• 该算法仅适用于特定场景，例如游戏服务器这样的领域；
  • Zookeeper在读写性能方面表现显著。

3.5 RMI

RMI（即Java Remote Method Invocation, Java远程方法调用）是遵循JDK API设计的一种标准分布式计算模式方案。该模式通过规范化的接口定义确保客户端程序能够通过特定协议与外部服务实现通信与数据交互功能。

3.5.1 特征

• 建立服务识别机制，通过该机制，客户端能够依据服务标识定位所需服务；
• 采用Java内置的序列化机制用于实现参数与结果的数据转换过程；
• 作为默认配置，系统仅允许配置RMI-IIOP相关参数。

3.5.2 优点

易于使用且无需额外安装配置

易于使用且无需额外安装配置

3.5.3 缺点

• 不支持多语言；
• 无法利用多核CPU资源。

3.6 RESTful RPC

RESTful RPC遵循基于HTTP协议的远程过程调用规范。该技术依靠URI指定远程服务，并利用HTTP方法执行相关操作。其中GET用于资源获取, POST用于提交请求, PUT用于更新资源, DELETE用于删除资源等操作。

3.6.1 特征

• RESTful URI可用于描述资源的位置及其相应的操作；
  • 该系统可提供不同类型的请求方式；
  • 该系统采用一系列HTTP方法进行通信操作。

3.6.2 优点

• 简易操作界面无需额外安装配置步骤；
  • 遵循标准HTTP协议规范并支持多种平台环境；
  • 客户端和服务端通信的内容直接映射到HTTP请求与响应流程中

3.6.3 缺点

• 请求的地址暴露给客户端，容易造成安全隐患。

4.A Comparison of the Seven Popular RPC Frameworks

基于功能特点及适用场景之下, 本章进行了7种常见RPC框架的概述.在前文的基础上, 本章着重介绍了Apache Thrift、gRPC以及Thief这三大框架.

4.1 Performance

RPC框架的性能是一个关键指标。为了更清晰地展示不同协议的表现差异，在下文将提供一个表格对比Apache Thrift、gRPC以及Thrift在性能方面的具体表现。

Feature	Apache Thrift	gRPC	Thrift
Average qps	50K+	90k+	25K+
Latency p99	ms	ms	us
Concurrency	Higher	Higher	Lower
从表格中可以看出，Apache Thrift、gRPC和Thrift三种框架的性能差距不是很大。Apache Thrift的平均QPS超过50K，gRPC的平均QPS超过90K，而Thrift的平均QPS只有25K左右。另外，Apache Thrift和gRPC的p99延迟在毫秒级别，而Thrift的延迟在微妙级。此外，Apache Thrift的并发性要比gRPC高一些。

4.2 Scalability

另一个关键的评估维度则是系统的可扩展性。为了直观比较各服务的表现，我们采用了图形化展示方式。通过观察图形数据可以看出，在处理请求数量增加时，Apache Thrift和gRPC能够维持较高的吞吐量水平。然而，在这种模式下（即基于线程的竞争模型），当请求量激增时，系统性能可能会显著下降。

4.3 Flexibility

第三项重要指标主要体现在系统的开发者的使用体验。为了更好地对比这些协议的特点及其适用场景，在对比分析表格中的各项指标时采用了统一的评价标准。

Feature	Apache Thrift	gRPC	Thrift
Programming model	Imperative	Declarative	Both
Interface definition language	IDL (Thrift)	ProtoBuf	Thrift, Protobuf, XML
从表格中可以看出，Apache Thrift和gRPC都属于声明式编程模型，它们通过IDL来定义服务接口。而Thrift是一种混合式的编程模型，它既支持IDL定义服务接口，也支持一种静态的IDL文件。
此外，Apache Thrift和gRPC都默认采用Protocol Buffer作为序列化格式，而Thrift除了支持Protocol Buffer还有JSON和XML格式。

4.4 Interoperability

第四项关键标准是跨平台互操作性。采用表格形式对Apache Thrift、gRPC和Thrift的跨平台互操作性进行对比分析。

Feature	Apache Thrift	gRPC	Thrift
Cross platform support	Yes	Yes	Partial
Client libraries for other languages	Java only	Many	Many
从表格中可以看出，Apache Thrift、gRPC和Thrift都是支持跨平台互操作的。gRPC提供了多种语言的客户端库，包括Java、Go、Nodejs、Python等。但是，由于其协议较新的缘故，Apache Thrift客户端的支持还不够广泛。Thrift客户端支持多种语言，包括Java、Ruby、Perl、PHP等。

4.5 Ease of use

第五个关键指标是易用性。为了直观对比不同协议的表现差异,本部分将通过详细表格对比分析Apache Thrift、gRPC以及thrift在易用性方面的具体表现

Feature	Apache Thrift	gRPC	Thrift
Documentation	Good	Good	Excellent
Getting started	Easy	Easy	Medium
Support	Commercial	Open source	Community
从表格中可以看出，Apache Thrift和gRPC的文档质量都比较好。Apache Thrift的文档详细，并且提供了很多使用示例。gRPC的文档也比较齐全，但仍处于不断完善的阶段。而Thrift的文档不太全面，但是其社区及生态圈比较活跃，并且有很多活跃的项目。
此外，Apache Thrift提供了大量的工具和辅助类，可以简化开发工作。gRPC提供了丰富的工具和组件，可以帮助开发者快速构建微服务应用。

4.6 Deployment Model

第六项关键指标代表了当前技术趋势的前沿方向。为了更好地对比不同协议的部署效率和性能特点，我们采用了表格形式进行了详细比较。

Feature	Apache Thrift	gRPC	Thrift
Server side deployment	Any process that runs on a JVM	Runs in any containerized environment such as Docker	Same server with multiple services
Service discovery	ZooKeeper or Consul	Google’s internal service registry	None
Load balancing	Round robin load balancing	Built-in load balancer	Custom implementation required
Security / Authentication	TLS	mTLS	SASL
Tunneling	No built-in tunneling functionality available	Using Istio	No built-in tunneling functionality available
Tracing	Built-in tracing tools provided by Zipkin	Based on opentracing API	Trace logging tool included
Metrics collection & visualization	Built-in metrics collection system	Prometheus	Built-in metrics collection system
Monitoring	Built-in monitoring solution based on Prometheus	Grafana	None
Distributed transaction management systems	Trivial	Google’s Saga pattern + MySQL distributed transactions	Built-in XA distributed transactions
从表格中可以看出，Apache Thrift、gRPC和Thrift都属于RPC的一种形式，即服务间的远程过程调用。Apache Thrift支持各种语言的客户端，包括Java、C++、PHP等，并且支持多种序列化格式，包括Protocol Buffer和JSON。gRPC也支持多种语言的客户端，包括Java、Go、Python、JavaScript等。Thrift客户端支持多种语言，包括Java、Ruby、Perl、PHP等。
另外，Apache Thrift支持多种注册中心、负载均衡策略和认证授权组件。而gRPC和Thrift都内置了负载均衡策略和认证授权组件。Thrift还支持分布式事务管理系统。

Summary

本文综述了七种流行的RPC架构方案。每个方案都具有独特的优势与不足。从性能与扩展性角度来看，Apache Thrift与gRPC均展现出良好的特性。两者均采用Thrift作为接口定义语言，并支持与其他如Protocol Buffers等IDL的兼容。就企业应用需求而言，在开发复杂业务逻辑时 RESTful-RPC 方式往往能提供更为便捷的选择。相比之下，在实现上仅限于Java生态系统的RMI技术。本文通过对这些主流RPC技术的分析对比及深入探讨, 希望能够为企业选择合适的API解决方案提供参考依据