RPC出现之前，服务之间是如何实现通信的？

一、三者的核心差异 #

先把基础概念掰清楚：

• HTTP：这是底层的传输协议，相当于服务间通信的"高速公路"，负责定义数据在网络上的传输、拆包解包规则，是网络API通信的基础之一（RPC也可基于TCP等其他协议，你提到的是HTTP场景）。
• RPC（远程过程调用）：是一种API设计架构/调用模式，核心目标是让开发者像调用本地函数一样调用远程服务。比如代码里写getUser(1)，背后实际调用远程服务器方法，它会把方法名、参数打包后通过HTTP（或TCP）发送，拿到结果再返回，数据格式常用Protobuf这类紧凑高效的格式。
• REST：同样是API架构风格，完全基于HTTP语义设计——核心是"资源"，每个HTTP请求对应对某个资源的操作。比如用GET /users/1获取ID为1的用户资源，POST /users创建新用户，数据格式常用JSON、XML，强调URL可读性和HTTP方法的语义化。

二、RPC出现前，服务间的通信方式 #

在RPC这种便捷调用模式普及之前，服务间通信主要靠这些原始手段：

• 手动构造HTTP请求：开发者自己写代码拼接HTTP请求的URL、请求头、请求体，发送后再手动解析响应内容，没有统一封装，全靠自己处理参数序列化、响应解析，繁琐且易出错。
• TCP套接字直接通信：基于TCP协议编写套接字程序，自己定义消息格式（比如规定前4字节是消息长度，后面是具体内容），手动处理连接、粘包、拆包、异常等问题。这种方式性能高，但开发成本极高，仅适合性能要求极致的场景。
• 消息队列异步通信：通过早期MQ中间件传递消息，服务A把数据打包成消息发送到队列，服务B从队列取消息处理，属于异步通信，适合不需要即时响应的场景。
• 文件共享：早期局域网或单机场景下，服务通过读写共享文件传递数据，比如服务A把数据写入共享目录文件，服务B定时读取处理。这种方式效率低、实时性差，仅适合低频率场景。
• CORBA、DCOM等早期分布式框架：这些是比RPC更早的分布式通信规范，比如CORBA是跨语言分布式对象调用标准，DCOM是微软组件对象模型。但它们配置复杂、学习成本高，还存在兼容性问题，后来逐渐被更轻量灵活的RPC框架替代。

内容的提问来源于stack exchange，提问作者Ritvik Joshi