问个概念问题，服务之间 feign 调用 算不算 rpc

[hsymlg]

https://en.wikipedia.org/wiki/Remote_procedure_call

[a22271001]

@zachlhb ChatGPT ？

[dcsuibian]

个人觉得吧，可以算是
毕竟普通的 http 请求也确实可以算是把参数传过去，把结果传回来，跟调函数一样

但大部分时候，如果说 rpc 框架，更多地是想强调“在调一个远程的服务时，代码方面表现地像在调用一个本地的函数一样”，就像 grpc 做的
而如果是普通的 http ，你可能还得考虑 get/put/post/delete ，content-type ，以及需要显式地注意 request 、response 等概念

所以我也觉得这东西应该不需要过度讨论

[wangxiaoaer]

广义的 RPC 包含 HTTP 。

狭义的 RPC 指的是本地调用（函数）背后是通过调用远程服务实现，这个调用方式可以是 HTTP ，也可以是 TCP 、UDP 。

[xy90321]

rpc 的精髓是远程服务的本地化调用，应该用起来像本地函数调用一样丝滑（不是指处理执行、响应的速度，而是单纯指调用方式）

用现成框架 /实现也好，你自己通过各种包装造轮子也好，只要能实现让调用端仿佛是在调用一个本地处理 /函数一样，那就是 rpc

[wm5d8b]

@a22271001 当前阶段的 ai ，看来还是可以区分的，毕竟没有情感

[jinliming2]

@alexleee #15 我觉得 HTTP 不算的原因是，HTTP 只是一个传输协议，在这个概念上可以看作是和 TCP 一个层面的东西，它本身不能算 RPC 。（注：不是按 OSI 模型去划分的
而 RPC 字面意思就是调用远程的函数就像调用本地的函数一样，那么至少得有一个“调用本地函数”这样一个动作。
所以，一个算是 传输层 的概念，一个算是 表示层 /应用层 的概念。
所以，我觉得可以基于 HTTP 这个协议来封装成 RPC ，比如写一堆 function ，然后内容就是 fetch xxx ，这可以算作是 RPC 。但至于这个 fetch 下面是 HTTP 还是 TCP UDP ，甚至你愿意的话用 ICMP ping 来传输都没啥问题。
比如 gRPC Web 也是基于 HTTP 的，但重点强调的不是基于 HTTP 传输，而是传输的内容是经过编码的“函数调用”，使用者就像调用本地函数一样。

[mmmmeme]

@zachlhb ChatRPC ？

[xlzyxxn]

RPC 比 HTTP 要年老，因为 web 和浏览器通用的需求，需要一个通用的协议；可以说 PRC 是个调用方式，HTTP 是他的其中一个实现方式；因为用的人太多了，也可以把他两放到一块做对比（服务发现、底层连接协议、序列化协议等等）；最后，用一个表情包说说我的观点：嗯......怎么不算呢

[cpszgy]

一个 RPC 的要素，协议商定，序列化，反序列化，过程调用，结果返回。feign 的工具包实现了这一过程的客户端功能。当然他欠缺了一点服务端的能力。因为服务端的使用了标准的的 http 协议。所以我感觉算是一个基于 http 协议的 rpc 客户端。