目录
1,上层应用开发者,与rpc框架的分工
浅蓝色的部分是由普通开发者,现阶段的我们所做的事情
深蓝色的由rpc框架内部来完成,如果公司自研框架则是由资深开发工程师来完成
2,RPC中的高级特性
2.1 注册中心
客户端与服务端进行通讯的前提的是,需要建立底层的tcp通讯链路,那么建立底层的tcp通讯首先要知道对端的ip,跟端口比如我们的客户端要调服务提供者的订单接口,那么客户端就要知道服务提供者的订单接口的地址信息是什么因此客户端就需要建立服务提供者的地址映射信息,那么服务提供者的地址映射信息要怎么存贮呢,配置文件的方式是否可以解决这个问题?
我们的服务提供者有可能是个集群,同一个接口有多个提供者,那么客服端这边就要维护多个服务提供者的地址信息集群有一个特点就是动态伸缩的能力,特别是在微服务,容器化的时代下,动态伸缩是很普遍的,流量大时就动态的增加服务提供者的节点,流量小时为了缩减资源就动态的缩减服务提供者的节点因此客户端就需要对服务提供者的地址信息进行不断的调配,这显然通过配置文件的方式,去维护服务提供者的地址信息是比较困难的。
我们希望的是服务提供者,地址信息发生变更之后,我们的消费者这边客户端这边是可以动态的感知到,服务提供者的地址变化,并且自动切换,不需要我们人工的去进行切换
因此需要引入第三者插件注册中心,在编程的世界中,两个人解决不了的问题,往往引入第三者就可以得到解决在注册中心中只要能满足存贮,可以存储 接口到服务提供者之间的映射关系,当然了有其他的需求我们也可以存储其他的信息及动态通知的能力,满足此类注册中心的插件有很多,我们根据具体的场景来选择即可。
一般由rpc框架提供
2.2 容错策略
消费者向提供者发起了请求,那么请求中发生了一些问题,比如请求超时或 者服务出错了,那我们这时候的rpc框架应该怎么办?将错误向上抛的话 那最后错误就会抛到客户端这显然是不合理的,另外作为rpc 框架第一 次出现错误就不管了,明显这个框架做的就不够健壮 因此在rpc框架中要有他的容错策略,出现错误后想办法做出相应的补 救,你这个服务不行了,换其他的服务呢,因此针对不同的错误,有 不同的容错策略,总之rpc框架要有自己的集群容错措施在里面。
2.3 路由策略
比如接口提供者的版本v1更新了,上了一些新的特性,接口提供者的服务端 又上线了该接口的v2版本,因为他们都是同一个接口的两个不同版本可以理解为同一个接口的两个不同实现因为是不同的实现因此内部逻辑就不同但是接口的方法名称是一样的
此时rpc调用的时候该怎么去选择接口服务提供者的版本去调用?
此时rpc框架需要对当前的rpc请求的调用对可用提供者的一个过滤的一 个过程,针对可用提供者的过滤的这个功能我们称之为路由路由就是决定我有哪一些接口的提供者是对当前的这次请求是可用的。
2.4 负载均衡
当接口的服务提供者有多个的时候,rpc框架该去调用哪个服务提供者呢?
对可用服务提供者的负载均衡。
2.5 熔断限流
针对流量的一个管理
比如我们在消费者端请求远程调用太频繁了,我们就需要对请求进行限流
2.6 rpc中的其他高级特性
3 总结
作为RPC框架的设计者,以上因素都是我们要充分考虑的功能点