文章目录
本文源自一次面试官的提问：说说你对于RPC框架的了解，你知道哪些RPC框架，以及为什么RPC历经几十年还能不断推出新的框架。
我觉得这个问题很有意思。在IT界RPC真的是一个"奇葩"，奇葩在每过一段时间都会有新的RPC框架出现，网络上仍然在不断争论哪个RPC框架更好，而这些RPC框架还有很多还是大厂的杰作，大厂们仿佛乐此不疲。
要知道RPC的历史可以追溯到1990年代初期，那时候"开放软件基金会"(Open Software Foundation，OSF)和业界主流的计算机厂商一期指定了名为分布式计算环境（Distributed Computing Environment）的分布式技术体系，当时就定出了一个远程服务调用的规范(Remote Procedure Call,RPC)，这个规定被称为DCE/RPC，后来Sun公司又开发出来一个ONC RPC,在这个时期基本上确定了RPC的很多概念和技术关注点，其中有很多解决思路，即使到了今天仍然有巨大的借鉴意义。
和RPC同期的很多技术或者框架很多都已经淹没在历史之中了，连当初盛极一时的EJB，现在已经几乎没人使用了，但是RPC却焕发了新的活力。
为什么历经三十多年，RPC还能不断推陈出新，被抽推崇呢？我认真思考这个问题的原因，有了一些不知是否成熟的想法，于是便记录下来。
再谈谈RPC的理解
RPC（Remote Procedure Call，远程过程调用），是一种通信协议，用于不同计算机之间的远程通信。它允许应用程序通过网络调用远程计算机上的服务或函数，并获取返回结果。RPC隐藏了底层网络通信的细节，使得远程调用就像本地调用一样简单和透明。
在RPC中，通常有一个客户端和一个服务器端。客户端发起远程调用请求，服务器端接收请求并执行相应的操作，然后将结果返回给客户端。RPC可以跨越不同的编程语言和操作系统，使得分布式系统中的不同组件能够进行相互通信和协作。
RPC的实现通常包括以下关键组件：
- **定义接口：**RPC通过定义接口描述远程服务的方法和参数，通常使用IDL（Interface Definition Language）来定义接口规范，例如使用Protocol Buffers、Thrift或gRPC等。
- **序列化与反序列化：**在远程调用过程中，需要将方法参数和返回值序列化为字节流进行传输，然后在对端进行反序列化。这样可以确保跨网络传输的数据能够被正确地重建和解析。
- **通信协议：**RPC使用不同的通信协议进行数据传输，如HTTP、TCP、UDP等。通信协议负责在客户端和服务器之间建立连接，并进行数据的可靠传输。
- **远程调用管理：**RPC框架通常提供远程调用的管理功能，包括请求的路由、负载均衡、故障恢复等。这些功能确保请求能够被正确地路由到相应的服务节点，并能够应对节点故障或网络中断的情况。
- **安全性和认证：**由于RPC涉及跨网络通信，安全性和认证是重要考虑因素。RPC框架通常提供身份验证、加密传输和访问控制等机制，以保护数据的机密性和完整性。
于是乎，你可以看到接口定义的方式可以不同、序列化和反序列化的机制可以不同、通信的协议可以不同、路由和安全方面的建设可以不同，这就给了各类RPC框架有非常大的想象空间，每个RPC框架都可以有自己独特的方面。
所以我们看到有各种各样我们所熟知的框架出现：
- CORBA（Common Object Request Broker Architecture，OMG）
- Java RMI（Sun/Oracle）
- Thrift（Facebook/Apache）
- Dubbo（阿里巴巴/Apache）
- gRPC（Google）
- Motan1/2（新浪）
- Finagle（Twitter）
- brpc（百度/Apache）
- .NET Remoting（微软）
- Arvo（Hadoop）
他们有的主要支持C++，有的主要支持Java，有的支持各类语言，有的以简单见长，有的则以性能取胜，各有特色。
要深入了解RPC，需要追溯一下RPC的发展史。
RPC的发展史
RPC的发展历史可以追溯到上世纪80年代，主要分为以下阶段：
- 早期阶段： 在早期阶段，RPC的概念开始出现并得到了实践。最早的RPC实现包括Sun Microsystems的NFS（Network File System）和Apollo Systems的NCS（Network Computing System），它们都是为了在分布式系统中实现远程调用而设计的，这个阶段是分布式技术的萌芽时期。
- 基于传统协议的RPC出现： 随着网络技术的发展，RPC的概念开始在不同的领域得到应用。许多基于传统协议的RPC实现出现，如DCE RPC（Distributed Computing Environment RPC）和CORBA（Common Object Request Broker Architecture）。这些实现使用了自定义的IDL（Interface Definition Language）和协议，以实现跨平台、跨语言的远程调用，这个时期的RPC协议应用还不广泛 ，性能存在较大的问题。
- Web服务和SOAP： 随着Web的兴起，RPC的关注点逐渐转向Web服务。Web服务使用SOAP（Simple Object Access Protocol）作为通信协议，通过XML进行数据传输。SOAP基于HTTP和XML，使得跨网络的远程调用更加方便。SOAP提供了基于WSDL（Web Services Description Language）的接口定义和基于UDDI（Universal Description, Discovery, and Integration）的服务发现，SOAP可以认为是RPC的一种案例，这阶段还出现了XML-RPC，后来也渐渐淘汰了。
- REST和Web API时代： 随着Web的演进，基于REST（Representational State Transfer）的Web API成为了一种更简洁、轻量级的远程调用方式。RESTful API使用HTTP协议，通过URL和HTTP方法（如GET、POST、PUT、DELETE）来表达资源的操作。RESTful API的普及使得基于HTTP的RPC变得更加流行，并广泛应用于Web开发和移动应用程序。
- 现代RPC框架： 进入21世纪，出现了许多现代化的RPC框架，如gRPC、Apache Thrift、Apache Dubbo等。这些框架提供了更高效、更强大的RPC能力，并支持多种编程语言和平台。它们通常采用二进制协议（如Protocol Buffers）和高性能的网络通信技术（如HTTP/2、TCP）来提升性能和效率。
随着技术的不断演进和需求的变化，RPC的发展也在不断推进，协议在变化，通信网络技术也在变化，发展到现代RPC框架则提供了更多的功能和特性，使得分布式系统的开发更加便捷和高效。
RPC历经数十年而不衰的原因?
现在可以尝试回答这个问题了，首先第一点我觉得应该是分布式系统的需求。
1、分布式系统的需求
单体应用时代，摩尔定律盛行，单个应用就能大部分解决业务需求，压根不涉及RPC，随着互联网的迅速发展和应用的扩大，单体应用无法满足业务需要，对于分布式系统的需求越来越强烈。
分布式系统中的各个组件需要进行跨网络的通信和协作，RPC作为一种重要的通信协议，能够满足分布式系统的需求，提供高效、可靠的远程调用机制。随着分布式系统规模的不断扩大和复杂性的增加，新的RPC框架不断涌现，以满足不同场景下的需求。
SOA、微服务、service mesh这些技术相继出现，这些分布式架构都少不了RPC这个重要的组件，于是产生了各种各样，适配不同场景的RPC框架。
2、RPC相关技术的演进
随着计算机技术和网络技术的不断进步，RPC的实现方式和性能也在不断提升。新的RPC框架往往借鉴和采用了先进的技术，如高性能的网络通信协议（如HTTP/2、gRPC的基于HTTP/2的传输），高效的序列化和反序列化机制（如Protocol Buffers），以及负载均衡、故障恢复等机制的优化。这些新技术的应用使得RPC框架更加高效、可靠，并具备更好的可扩展性和弹性。
一旦协议、网络、安全、故障恢复能机制有新的进展，势必就会带来RPC框架的更新。
3、多语言的支持
RPC框架通常支持多种编程语言，使得不同语言编写的应用程序能够进行跨语言的远程调用。这对于大型分布式系统的开发非常重要，因为不同的团队和组织可能使用不同的编程语言开发各自的组件,新的RPC框架通常会扩展语言支持，以满足多样化的开发需求。
我们发现每个时代都会迸发出一些新的开发语言，比如现在云原生时代，Go和Rust语言就大受欢迎，那么支持Go语言和Rust语言的RPC框架就会出现，这也是RPC的一个活力源头所在。
4、不同场景的需求
不同的应用场景对RPC框架提出了各种需求，例如高并发、低延迟、可扩展性、安全性等。新的RPC框架通常会根据不同场景的需求进行针对性的优化和功能扩展，以满足特定的应用需求。
特别是一些大厂，内部业务复杂，对于RPC有一些独特的需求，另外也需要匹配内部的技术栈，这样子就常常造出了新轮子。
其实RPC确实挺有意思的，展现了技术的持久生命力，另外别看RPC就那几个组件，实际自己编写一个就知道了，需要注意的技术细节实在是太多了，也是一个非常锻炼人的活计，如果能够自己独立写一个功能比较丰富、高性能的RPC框架出来的话，我想编程能力至少应该能算是登堂入室了。