开发接口时经常会听到这样的问题“我们用 HTTP还是用 RPC”这句话在团队里通常能被理解但严格来说比较的双方并不在同一个层面。HTTP 是一种应用层通信协议RPC 是 Remote Procedure Call 的缩写中文叫“远程过程调用”描述的是调用另一台机器上某个功能的方式。RPC 可以通过 HTTP 实现。常见的 gRPC 就建立在 HTTP/2 之上。理解了这一点再看它们的区别就不容易绕进去。一、先从一次点餐说起假设你坐在餐厅里想点一碗牛肉面。你不用走进后厨只需要告诉服务员“来一碗牛肉面少放辣。”服务员把要求交给后厨再把做好的面端给你。用RPC理解你提出一个明确的操作要求由另一处的人完成再把结果交回来。对应到程序里就是调用远程服务的一个方法比如点餐(牛肉面, 少辣)。服务员则像 RPC 框架负责传递要求和返回结果让你不必亲自处理这些细节。HTTP 可以类比为餐厅统一使用的订单和回单规则订单上如何写明要做什么、附带哪些要求回单上如何表示“已接收”或“菜品售罄”。它让传递信息的双方知道该怎样表达和理解请求、响应。因此一次点餐可以同时包含这两件事你通过服务员请后厨做面体现了 RPC 的调用思路服务员和后厨按照统一的订单规则沟通类似于使用 HTTP。一个描述“怎样调用远处的功能”一个规定“请求和响应怎样表达”可以用在同一次交互中。二、HTTP把请求和响应说清楚HTTP 的全称是 Hypertext Transfer Protocol中文叫“超文本传输协议”。名字里虽然有“超文本”但它能传递的内容远不止网页还包括 JSON、图片、文件和二进制数据。例如查询编号为 42 的用户可以发送下面的请求。这里用 HTTP/1.1 的文本形式展示方便阅读GET /users/42 HTTP/1.1Host: api.example.comAccept: application/json服务端可能返回HTTP/1.1 200 OKContent-Type: application/json{id:42,name:小林}这里的几个部分各有用途GET表示请求获取资源的方式。/users/42指向要访问的资源。200 OK表示请求成功。Content-Type说明响应正文是什么格式。HTTP 提供了方法、状态码、字段等通用语义但不会替你决定“用户有哪些字段”“订单能否取消”。这些仍然需要业务接口自己约定。也别把 HTTP 和 REST 当成同义词。REST 是一种架构风格很多 HTTP API 会借鉴它以资源为中心设计接口使用了 HTTP并不意味着接口就符合 REST。三、RPC让远程服务像一个可调用的方法如果用户查询逻辑就在当前程序里你可能这样写user getUser(42)后来用户数据交给独立的用户服务管理。查询需要跨网络完成RPC 框架通常会提供一个客户端让调用代码保持相近的形状# 示意代码具体写法取决于所用框架user user_client.getUser(userId42)这一行代码背后实际发生了不少事情客户端把方法名和参数编码成可传输的数据发给远程服务服务端解码后执行相应逻辑再把结果编码返回。把内存中的数据转换成可传输格式叫“序列化”收到数据后还原叫“反序列化”一般像我们常用的JSON。许多 RPC 框架还会根据接口定义生成客户端和服务端骨架。调用方不必为每个接口重复编写组装请求、解析响应的代码。各框架提供的功能不同不能把某一种框架的能力看成所有 RPC 实现都具备的特性。四、用同一个需求看两种接口思路继续以“查询用户”为例偏资源风格的 HTTP API通常会设计成GET /users/42偏 RPC 风格的接口则更直接地表达动作UserService.GetUser(userId42)前者让你围绕“用户这个资源”思考后者让你围绕“查询用户这个操作”思考。RPC 也可以装进普通 HTTP 请求里例如POST /rpc HTTP/1.1Host: api.example.comContent-Type: application/json{method:UserService.GetUser,params:{user_id:42}}这是一个简化的自定义示例不代表某项 RPC 标准。它说明同一个请求可以同时具有两种属性通信使用 HTTP业务接口采用 RPC 风格。五、RPC 一定比 HTTP 快吗不能这样下结论。RPC 可能本来就在使用 HTTP而且性能取决于具体实现。如果拿“HTTP/1.1 JSON”的接口和“gRPC Protocol Buffers”的接口比较结果里会混合很多因素编码后的数据大小、序列化开销、连接复用方式以及框架本身的处理成本。业务代码和数据库查询也可能占掉大部分时间。HTTP/2 本身支持多路复用这并不是 RPC 独有的能力。普通 HTTP API 也不必只用 JSON。把这些条件换掉结果可能跟着变化。那么实际项目应该如何选择你的需求可以优先考虑的方向浏览器直接访问、外部开发者接入、方便查看请求常规 HTTP/JSON API多个内部服务需要共享明确的接口定义、自动生成调用代码gRPC 等 RPC 框架需要持续传递消息或双向流式通信根据客户端和部署条件评估 gRPC 等流式方案已有系统运行稳定没有明确的性能或维护问题优先沿用现有方案避免为了换技术而改造当然一个系统同时使用多种方案很常见浏览器通过 HTTP/JSON 访问业务入口后端服务之间通过 gRPC 协作外部合作方则使用公开的 HTTP API。不同边界有不同需求不必强求整套系统只用一种方式。六、小结HTTP 让通信双方对请求和响应有共同的理解RPC 让调用方以“调用远程方法”的方式使用另一个服务的能力。