RPC英文全称Remote Procedure Call, 即远程过程调用. 是计算机的一种通信的协议, 能够使不同进程相互之间调用别的进程的函数就像在调用本地函数一样.
RPC内部通常使用高效的自定义的序列化协议, 可以减少报文数据的冗余, 使传输效率更高, 同时RPC具有较强的扩展性.
例如GRPC一般使用protobuf作为序列化协议, protobuf可以使数据更加紧凑, 减少冗余, 同时序列化和反序列化的性能极佳.
为什么需要RPC这种技术? 或者说它是用来解决什么问题的?
回答这个问题之前, 先思考一下单体项目的局限性和难以解决的难题. 当单体项目的业务不断扩张, 访问量过大时, 因为大量的业务代码耦合在一起, 使项目的可维护性, 稳定性, 性能大大降低, 此时最好想的方法就是提高机器的配置, 但是这种方法不是最佳的解决方式, 因为配置达到一定数值之后, 增加配置的成本大于增加机器的成本. 这时为了解决这个问题, RPC就派上用场了, 因为当增加机器的成本小于增加配置的成本时, 选择增加机器这种方式无疑明智的, 而RPC好像就是为了解决这个问题而生, 通过调用不同机器注册服务函数, 实现和单体项目一样的效果, 这种的在服务端负载过大时具有无与伦比的优势, 使大量的代码模块化, 充分解耦, 使开发者不用太关注整体的细节.
如果当服务端的实例过多或者会进行动态变换时, 客户端就会实现起来就会非常繁琐, 那该怎么办? 别慌, 有一句话叫"计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决", 为了让开发变得更加清晰, 易于实现和开发, 这时注册中心就出现了, 服务端将自己提供的服务上报给注册中心, 由注册中心统一管理服务端节点, 客户端只需要从注册中心拉取自己需要的服务就行了, 通过注册中心这种方式屏蔽了客户端和服务端. 但是还有一个问题, 如果服务端的提供的某一个服务的负载过大, 单台机器很难承受时, 我们怎么办? 相信你已经想到解决方式了, 一台不够, 那我再加一台, 还不够, 我就继续加, 一直加到够为止. 对, 就是这种感觉, 但是当某一个服务配置了多个服务端节点时, 注册中心该怎么完成对该服务的管理, 保证能充分发挥多台相同服务的机器的性能? 这个时候, 负载均衡就来了, 通过某种算法将客户端的请求的某种服务命中不同的服务端节点, 常见的方式有轮循负载, 随机负载, 加权轮循负载, hash负载.
少年估计此时你已经了解RPC技术使用的大致流程, 想去大干一场. 快去吧, 趁热打铁, 做一个小实例加深你对RPC的了解.
