项目提供 RPC 接口和第三方类库方法有什么区别？

Question

目前参与的分布式项目中会写一些 RPC 接口供其他服务调用，但是我发现这些方法也可以以打包部署到远程仓库的方式供给其他服务导入使用，但为什么不使用后者方式呢？

Answer 1

感觉理解不是太到位。

RPC是进程间调用的一种方式，本质是本地程序调用远程计算机上过程/函数的机制。
SDK是软件开发工具包，它是将一组功能相对完整的工具封装在一起的一个工具包。

所谓RPC与本地调用：猜测你想表达的应该是进程间调用与进程内调用。进程内调用，因为进程内资源共享，即可以访问相同的内存地址，其实就是堆内存数据。

而SDK则是为了方便适配某种特定语言，开发的工具包。

---

举例如开源软件MinIO。
它提供基于HTTP API接口，兼容亚马逊S3协议。

如 获取Object接口

很多语言对这个HTTP协议做了封装，方便不同的语言进行使用。其实就是SDK

这些SDK的本质就是将函数调用转化为HTTP API的调用。

Answer 2

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

Answer 3

“但是我发现这些接口也可以以 sdk 的方式提供给其他服务调用” 这句话就证明了你的场景最佳做法是SDK提供，而不是API提供! 走TCP的socket三次握手，四次挥手，序列化，反序列化，网络传输这么绕一大圈，除非有特殊要求有这个必要，否则优先考虑SDK提供!

Answer 4

在微服务架构项目中选择使用 RPC 而非 SDK 方式提供相关能力，我认为最大的考虑是充分利用微服务架构的快速迭代优势，那么这个问题可以从微服务架构应用（和单体应用比较）和面向接口编程的优势两方面回答。
在说微服务架构应用优势之前，先说说单体应用的痛点。以Java单体应用为例，随着业务迭代发展，项目逐渐庞大，每一次上线后的白名单验证、回归测试一旦有问题就得回炉重造，可谓"牵一发而动全身"，效率非常低下，无法达到快速迭代的目的。微服务框架将一个大型应用拆分成了更细粒度且边界清晰的服务模块，每个服务独立测试、部署，因此能够实现快速迭代、快速回滚。如果在迭代过程中出现线上 bug，也可以在最短时间内做线上回滚，并且不会影响到其他应用的正常发布。而在微服务架构使用 sdk 方式提供相关能力，相当于又回到了单体应用，并没有利用到微服务架构的快速迭代、回滚的优势。
其次是面向接口编程的优势，使用 RPC 时，一般的做法是先找服务提供方要接口，通过 Maven 导入依赖，在编写业务代码过程中，如果需要调用提供方的接口，只需通过依赖注入把接口注入到项目中，然后直接调用接口的方法即可。而使用 sdk 方式时，一般是直接调用具体实现类方法，这通常会导致代码高度耦合，缺乏灵活性和可扩展性，如修改实现时需要修改所有依赖代码、不能轻易替换不同的实现等。在微服务架构中，基于接口编程尤为重要，因为微服务强调服务之间的独立性和松耦合。通过使用接口定义，服务的实现可以灵活变动，而不影响其他服务。这种方式不仅提高了服务的可维护性，还增强了系统的扩展性和容错能力。
从上面两方面分析来看，在微服务架构中使用 sdk 方式提供相关能力在迭代速度、项目可扩展性灵活性以及性能方面不合理，也就会被 RPC 方式取代。