目前参与的分布式项目中会写一些 RPC 接口供其他服务调用,但是我发现这些方法也可以以打包部署到远程仓库的方式供给其他服务导入使用,但为什么不使用后者方式呢?
目前参与的分布式项目中会写一些 RPC 接口供其他服务调用,但是我发现这些方法也可以以打包部署到远程仓库的方式供给其他服务导入使用,但为什么不使用后者方式呢?
RPC(Remote Procedure Call)方法调用与本地调用的主要差异在于调用发生的位置、网络通信的开销、以及如何处理调用失败和异常。这些差异使得RPC在某些场景下比本地调用更为复杂,但并不意味着RPC不适用于本地调用,而是说在某些情况下使用本地调用可能更为高效。
实际上,RPC可以用于本地调用,但通常不是最佳选择。原因如下:
RPC和本地调用各有优缺点,适用于不同的场景。在大多数情况下,本地调用是最高效和最简单的选择。然而,在需要跨进程或跨机器通信的场景中,RPC是不可或缺的。选择哪种方式取决于具体的需求和约束条件。
“但是我发现这些接口也可以以 sdk 的方式提供给其他服务调用” 这句话就证明了你的场景最佳做法是SDK提供,而不是API提供! 走TCP的socket三次握手,四次挥手,序列化,反序列化,网络传输这么绕一大圈,除非有特殊要求有这个必要,否则优先考虑SDK提供!
在微服务架构项目中选择使用 RPC 而非 SDK 方式提供相关能力,我认为最大的考虑是充分利用微服务架构的快速迭代优势,那么这个问题可以从微服务架构应用(和单体应用比较)和面向接口编程的优势两方面回答。
在说微服务架构应用优势之前,先说说单体应用的痛点。以Java单体应用为例,随着业务迭代发展,项目逐渐庞大,每一次上线后的白名单验证、回归测试一旦有问题就得回炉重造,可谓"牵一发而动全身",效率非常低下,无法达到快速迭代的目的。微服务框架将一个大型应用拆分成了更细粒度且边界清晰的服务模块,每个服务独立测试、部署,因此能够实现快速迭代、快速回滚。如果在迭代过程中出现线上 bug,也可以在最短时间内做线上回滚,并且不会影响到其他应用的正常发布。而在微服务架构使用 sdk 方式提供相关能力,相当于又回到了单体应用,并没有利用到微服务架构的快速迭代、回滚的优势。
其次是面向接口编程的优势,使用 RPC 时,一般的做法是先找服务提供方要接口,通过 Maven 导入依赖,在编写业务代码过程中,如果需要调用提供方的接口,只需通过依赖注入把接口注入到项目中,然后直接调用接口的方法即可。而使用 sdk 方式时,一般是直接调用具体实现类方法,这通常会导致代码高度耦合,缺乏灵活性和可扩展性,如修改实现时需要修改所有依赖代码、不能轻易替换不同的实现等。在微服务架构中,基于接口编程尤为重要,因为微服务强调服务之间的独立性和松耦合。通过使用接口定义,服务的实现可以灵活变动,而不影响其他服务。这种方式不仅提高了服务的可维护性,还增强了系统的扩展性和容错能力。
从上面两方面分析来看,在微服务架构中使用 sdk 方式提供相关能力在迭代速度、项目可扩展性灵活性以及性能方面不合理,也就会被 RPC 方式取代。
感觉理解不是太到位。
RPC
是进程间调用的一种方式,本质是本地程序调用远程计算机上过程/函数的机制。SDK
是软件开发工具包,它是将一组功能相对完整的工具封装在一起的一个工具包。所谓
RPC
与本地调用
:猜测你想表达的应该是进程间调用与进程内调用。进程内调用,因为进程内资源共享,即可以访问相同的内存地址,其实就是堆内存数据。而
SDK
则是为了方便适配某种特定语言,开发的工具包。举例如开源软件
MinIO
。它提供基于HTTP API接口,兼容亚马逊S3协议。
如 获取Object接口
很多语言对这个HTTP协议做了封装,方便不同的语言进行使用。其实就是SDK
这些SDK的本质就是将函数调用转化为HTTP API的调用。