governance.png

背景

• 随着微服务的发展,我们的难免会引入一些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,但是都会遇到一些流控等问题，也就是上下游速率不平衡 以及负载均衡