为什么RPC框架数十年还在造轮子？EJB骨灰都快找不到了！ _框架

本文源自一次面试官的提问：说说你对于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框架都可以有自己独特的方面。
所以我们看到有各种各样我们所熟知的框架出现：