设计一个灵活的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加载某个接口实现类的时候,会遍历全部获取,接口的实现类全部载入并实例化一遍,会造成不必要的浪费,扩展性比较差。

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

相关推荐
赖龙1 天前
记录SSL部署,链路不完整问题
网络·网络协议·ssl
Xの哲學1 天前
Linux RCU (Read-Copy-Update) 机制深度分析
linux·网络·算法·架构·边缘计算
吐个泡泡v1 天前
网络编程基础:一文搞懂 Socket、HTTP、HTTPS、TCP/IP、SSL 的关系
网络·网络协议·http·https·socket·ssl·tcp
Blurpath1 天前
如何利用静态代理IP优化爬虫策略?从基础到实战的完整指南
爬虫·网络协议·ip代理·住宅代理
Tadas-Gao1 天前
阿里云通义MoE全局均衡技术:突破专家负载失衡的革新之道
人工智能·架构·大模型·llm·云计算
liulilittle1 天前
HTTP简易客户端实现
开发语言·网络·c++·网络协议·http·编程语言
听风同学1 天前
RAG的灵魂-向量数据库技术深度解析
后端·架构
luoganttcc1 天前
黑芝麻芯片 架构分析
架构·硬件架构
喵叔哟1 天前
52.【.NET8 实战--孢子记账--从单体到微服务--转向微服务】--解决客户端调用接口404问题
微服务·架构·.net
板鸭〈小号〉1 天前
UDP-Server(2)词典功能
网络·网络协议·udp