设计一个灵活的RPC架构

RPC架构

RPC本质上就是一个远程调用 ,需要通过网络来传输数据。传输协议可以有多种选择,但考虑到可靠性,一般默认采用TCP协议 。为了屏蔽网络传输的复杂性,需要封装一个单独的数据传输模块用来收发二进制数据,这个单独模块可以叫做传输模块

网络数据传输是二进制数据,涉及对象的序列化与反序列化。数据拆分协议封装。

网络传输过程中,请求数据包在数据链路层可能会因为太大而被拆分成多个数据包进行传输,为了减少被拆分的次数 ,从而导致整个传输时间太长,在方法调用参数或者返回值的二进制数据大于某个阈值 时,可以通过压缩框架进行无损压缩,然后在另外一端用同样的压缩算法进行解压,保证数据可还原。

当一个接口有着多个服务提供者时,服务对调用方是透明的。RPC需要提供"服务发现"机制,在RPC里面维护好接口跟服务提供者地址的关系,调用方可以快速找到调用地址。

对RPC来说,每次发送请求时都需要用TCP连接,相对服务提供方IP地址,TCP连接状态是瞬息万变的,因此RPC框架里面要有连接管理器维护TCP连接的状态

有了集群之后,提供方需要管理好这些服务。RPC就需要内置一些服务治理的功能,比如服务提供方权重的设置、调用授权等一些常规治理手段。

可扩展架构

RPC框架设计之初不可能面面俱到,如何应对技术迭代呢?

插件化架构

RPC框架中,将每个功能点抽象成一个接口,接口作为插件的契约,功能的接口与功能的实现分离,并提供接口的默认实现。

JDK自带的SPI(Service Provider Interface)服务发现机制 ,可以动态地为某个接口寻找服务实现。使用SPI机制需要在Classpath下的META-INF/services目录里创建一个以服务接口命名的文件,这个文件里的内容就是这个接口的具体实现类。如下,文件名和内容都是接口和实现类全包名。

然而,JDK自带的SPI机制使用比较少,不能按需加载 ,ServiceLoader加载某个接口实现类的时候,会遍历全部获取,接口的实现类全部载入并实例化一遍,会造成不必要的浪费,扩展性比较差。

功能点抽象成一个接口,将接口作为插件的契约,功能的接口与功能的实现分离并提供接口的默认实现。可扩展性很好 ,用户可以方便地通过插件扩展实现自己的功能。无需修改核心功能本身;保持了核心包的精简,依赖外部包少。

相关推荐
茶馆大橘15 分钟前
微服务系列五:避免雪崩问题的限流、隔离、熔断措施
java·jmeter·spring cloud·微服务·云原生·架构·sentinel
点点滴滴的记录29 分钟前
RPC核心实现原理
网络·网络协议·rpc
徒步僧35 分钟前
ThingsBoard规则链节点:RPC Call Reply节点详解
qt·microsoft·rpc
coding侠客44 分钟前
揭秘!微服务架构下,Apollo 配置中心凭啥扮演关键角色?
微服务·云原生·架构
程思扬2 小时前
为什么Uptime+Kuma本地部署与远程使用是网站监控新选择?
linux·服务器·网络·经验分享·后端·网络协议·1024程序员节
lipviolet2 小时前
架构系列---高并发
架构
Phodal2 小时前
架构赋能 AI:知识工程推动下的软件架构数字化
人工智能·架构
海绵波波1073 小时前
Webserver(4.8)UDP、广播、组播
单片机·网络协议·udp
曹申阳4 小时前
2. JVM的架构模型和生命周期
jvm·架构
车载诊断技术5 小时前
电子电气架构 --- 整车控制系统
网络·架构·汽车·soa·电子电器架构