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

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框架出来的话，我想编程能力至少应该能算是登堂入室了。

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