架构解密从分布式到微服务：古老又有生命力的 RPC

本文链接：https://blog.youkuaiyun.com/stone_tmp/article/details/117855191

本文介绍了RPC（远程过程调用）的概念及其在分布式到微服务架构中的作用。RPC旨在简化Socket通信，提供通用框架，减少分布式系统开发难度。文中对比了Socket与RPC在编程上的差异，并探讨了RPC的发展历程，包括CORBA的失败、SOAP的兴起与衰落，以及现代RPC框架如Thrift和gRPC的特点。RPC技术因其高性能和跨语言支持，在互联网时代仍然具有重要地位。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

古老又有生命力的RPC

RPC (Remote Procedure Call，远程过程调用）是建立在Socket之上的一种多进程间的通信机制。不同于复杂的Socket通信方式，RPC的初心是设计一套远程通信的通用框架，这个框架能够自动处理通信协议、对象序列化、网络传输等复杂细节，并且希望开发者在使用这个框架以后，调用一个远程机器上的接口的代码与以本地方法调用的代码“看起来没什么区别”，从而大大减小分布式系统的开发难度，使得比较容易开发分布式系统。

为了便于理解Socket通信与RPC通信在编程方面的区别，我们举个简单的例子来解释:假设目前在B机器上有一个进程，可以简单地实现四则运算，比如我们输入 1+1让它计算并返回计算结果，那么用Socket开发时，客户端的伪代码大致如下:

client =new Socket (B);
client.write("plus(1,1)");
result=client.read();
client.close(）;

而服务端的伪代码大致如下:

socketServer server=new ServerSocket (）;
server.listen (）;
while(true)
{
cmd-server.read();
if(cmd .startwith("plus("))
{
··
client.write(result);
}
}

上述代码仅为大量简化后的伪代码，如果要达到生产质量的要求，则还需要考虑如下复杂问题。

网络异常问题:在调用过程中如果发生网络异常，则调用失败，客户端需要明确知道发生了异常，然后有针对性地进行处理。
复杂数据传输过程中的编码和解码问题:当输入参数或者输出参数很复杂时，参数编码及解码过程中的复杂性经常会让思维不够严密的程序员头脑“短路”。
客户端的连接复用问题，如果每次调用都建立一个TCP连接，用完关闭，那么调用性会很低，因为将大量时间都用在TCP建立连接的过程中了，因此客户端需要一种连接保持及连接复用的机制,还涉及服务端与客户端连接心跳检测及超时机制等相关的复杂问题。
服务端需要有多线程机制来应对客户端的并发请求，以提升性能。

所以你会发现，即使我们有了Socket，有了好的NIO框架，也基本上没有多少人能开发出一个基于Socket的高质量的远程通信模块,而随便一个分布式系统就