rpc - RPC方法调用与本地调用差异在何处，为何不适用于本地？

Question

目前参与的项目中会写一些 RPC 接口供其他服务调用，但是我发现这些接口也可以以 sdk 的方式提供给其他服务调用，但是为什么不用 sdk 的方式提供呢？

Answer 1

假设一个是php系统,一个java系统,他们是由两个团队维护,这时候如果使用RPC调用就不需要使用其他方案来引入依赖了

Answer 2

RPC（Remote Procedure Call）方法调用与本地调用的主要差异在于调用发生的位置、网络通信的开销、以及如何处理调用失败和异常。这些差异使得RPC在某些场景下比本地调用更为复杂，但并不意味着RPC不适用于本地调用，而是说在某些情况下使用本地调用可能更为高效。

RPC与本地调用的主要差异：

1. 位置：本地调用发生在同一进程内，而RPC调用通常发生在不同的进程或不同的机器上。
2. 网络通信：RPC涉及网络通信，这可能会引入延迟、带宽限制和潜在的失败点（如网络中断）。本地调用则没有这些问题。
3. 序列化/反序列化：RPC需要将参数和返回值序列化为字节流以便在网络上传输，然后在目标端反序列化。这可能会引入额外的开销和复杂性。本地调用则直接传递内存中的对象，无需序列化和反序列化。
4. 异常处理：RPC调用失败时，需要一种机制来通知调用方（通常是抛出异常或返回错误代码）。这种机制可能需要额外的协议和复杂性来确保错误信息的准确传递。本地调用则可以直接使用语言的异常处理机制。
5. 负载均衡和容错：对于RPC，可能需要实现负载均衡和容错机制，以确保服务的高可用性和可扩展性。本地调用则无需考虑这些问题。

为何RPC不适用于本地调用？

实际上，RPC可以用于本地调用，但通常不是最佳选择。原因如下：

• 性能开销：本地调用通常比RPC调用更快，因为避免了网络通信和序列化/反序列化的开销。
• 复杂性：引入RPC框架会增加系统的复杂性和维护成本，特别是当只需要本地调用时。
• 调试难度：RPC调用失败时，调试可能会更加困难，因为需要考虑网络问题和序列化/反序列化错误等因素。
• 依赖关系：使用RPC框架会增加对外部库的依赖，这可能会增加部署和管理的复杂性。

使用RPC的场景：

• 分布式系统：当需要在不同的进程或机器上调用方法时，RPC是首选的解决方案。
• 微服务架构：在微服务架构中，服务之间的通信通常通过RPC实现。
• 跨语言调用：当需要在不同的编程语言之间调用方法时，RPC提供了一种通用的解决方案。

总结：

RPC和本地调用各有优缺点，适用于不同的场景。在大多数情况下，本地调用是最高效和最简单的选择。然而，在需要跨进程或跨机器通信的场景中，RPC是不可或缺的。选择哪种方式取决于具体的需求和约束条件。