背景
- 随着微服务的发展,我们的难免会引入一些rpc框架去帮我处理远程调用,今天简单介绍一下背后的实现和发展
rpc
-
因为服务化的出现,我们调用其他服务的方法可能就不再是本地调用方法那么简单,之前一个简单的方法调用,如今变成了远程调用,最直白的方法就是在本地创建一个远程服务的动态代理,现在我们一般都是基于spring框架开发的,所以一般这个远程服务的动态代理是在spring容器启动的时候基于远程接口生成的,然后注册到spring 容器中,当我们调用远程服务方法时,其实调用的是本地的动态代理,然后本地动态代理里面去做调用远程的服务,比如通过netty 调用远程某个端口,或者通过http等等。
rpc.png -
但是上面的rpc调用有很多问题,因为是分布式系统间的调用,所以可能会有很多问题 , 比如
- 对方服务挂
- 我们这边流量太大对方扛不住
- 我们一直请求对方的某个节点服务造成流量不均衡
- 对方的服务ip地址变了
- 我们请求超时了(是失败了还是成功了 未知)
等等很多很多问题;那么如果按照上面那个最原始的rpc调用可能会出很多问题,因此分布式系统中引入了一些服务治理的方案
- 引入了服务注册和发现(一般是基于分布式服务注册中心)
- 引入了熔断限流 方便服务降级
- 引入了重试 解决了可能会出现的网络超时、抖动等问题(需要接口支持幂等)
-
引入了负载均衡策略(解决了可能会出现的流量不均衡)
rpc_with_governance.png
总结
- 分布式系统中的通信都需要rpc框架的支持,比如服务和很多中间件的通信底层的都需要rpc的支持,比如kafka broker 和 producer、consumer的通信 , redis client 和 redis cluster 的通信、elasticsearch client 和对应集群的通信、配置中心client 和 集群的通信 ,有些需要高性能 在netty上做了一些开发作为节点间的通信,有的为了简单直接用http,但是都会遇到一些流控等问题,也就是上下游速率不平衡 以及负载均衡
网友评论