RSF 分布式 RPC 服务框架的分层设计

RSF 是个什么东西?

一个高可用、高性能、轻量级的分布式服务框架。支持容灾、负载均衡、集群。一个典型的应用场景是,将同一个服务部署在多个Server上提供 request、response 消息通知。使用RSF可以点对点调用,也可以分布式调用。部署方式上:可以搭配注册中心,也可以独立使用。

渊源

RSF 的核心思想参考了淘宝HSF、Dubbo 等优秀框架。功能上大体相似,但是实现逻辑完全不同。因此没有什么历史包袱。总的来说对比淘宝HSF少了历史包袱,相比Dubbo更加轻量化。而且还支持了虚拟机房,对于多机房部署的产品可以省下大量带宽成本,同时也降低了远程调用时间。

RSF虽然在功能上与两位前辈出入不大,使用RSF最直观的感受就是简单方便,配置少、依赖少,功能强大。

特点

RSF 的最大特点就是在强大的功能支持下,依然可以保持:最简单、最轻量。我们先轻描淡写的说一下RSF 的特点。

简单容易(三个一):1 行代码发布服务、1 行代码订阅服务、1 行代码使用服务

体积轻薄:RSF 是基于 Hasor 构建,此外还依赖了 netty 和 groovy。因此包含 RSF 在内引入的JAR包总数只有 5 个,其中 RSF 只有大约 700KB 的体积。

工作原理

RSF 是专门为集群、高可用系统进行设计的分布式 RPC 服务框架。服务提供者可以是一个集群,服务的消费者也可以是一个集群,两者混合在一个集群里也是ok的。同时为了增强融灾 RSF 的注册中心也是支持集群的。

所以基于 RSF 构建的服务系统不会存在任何单点问题。

框架分层

RSF 的架构设计上遵循了自顶而下明确的分层设计,每一层都有专注的工作职责。大体分为 9 个层次。他们如下所示:,你也可以理解这是 RSF 的架构设计。    第一层:是业务系统中的服务,一个服务的状态可以是提供者(Provider)、也可以是消费者(Customer),或者两者共存。总之在这一层,出现的不是服务接口,就是服务的接口的实现

第二层:是一个应用程序到框架的接入层。分为提供者(Provider)、消费者(Customer)两个部分。

对于提供者(Provider)来说这一层就是框架的一个交互 API ,负责将服务接口信息提取出来让 RSF 框架可以识别到。而对于消费者(Customer)来说,这一层的目的就是将服务接口进行动态代理。通过代理拦截所有远程方法调用,这一点类似于AOP。

第三层:这一层中所有来自动态代理的接口调用都会统一转换成 RsfRequest ,同时方法的返回值也会封装成为 RsfResponse。可以说这一层是专门为扩展性设计准备的,开发者在这一层中可以围绕着 RsfFilter、RsfRequest、RsfResponse 接口进行扩展。

第四层:这是一个典型的职责链,职责链的开端是承接调用请求,末端承接着方法的调用。在整个职责链中开发者几乎可以为所欲为。你可以中断整个 RPC,自己 mock 数据。也可以偷梁换柱调用其它服务然后返回结果。

第五层:这一层是也是消费者(Customer)专有的设计,这一层是一个比较重要的地方,它负责维护管理并且提供服务的IP地址。举个例子:我们有 1 个服务,这个服务拥有 10 个服务提供者。那么这 10 个服务提供者的服务地址和端口信息都是在这一层维护的。当执行远程调用的时候,这一层会提供IP地址出来。

提供IP地址这个操作,有必要稍微展开说一下。向 QoS流控,跨机房调用、服务路由。这些非常重要的功能都是由这一层来提供支持。这一层用一句话来表示:它就是地址管理器

第六层:这一层用“调度器”来总结说明是最贴切的。

对于提供者(Provider)来说,在这一层基于队列提供了一个 Server 的保护屏障。这个保护屏障可以保证当遇到 Client 疯狂的调用请求时,可以合理的进行回绝以保证 Server 自己不会被冲垮。对于消费者(Customer)来说,在这一层提供了请求管理器,并且提供了一个最大请求并发的控制器。

这一层可以说是 RSF 的中枢神经,因为调度器就是 RSF 线程模型的最终实现。有关线程模型在后面会有专门文章介绍一下(https://my.oschina.net/u/1166271/blog/779361)。

第七层:是提供序列化功能,开发者想自定义序列化规则。也是由这一层提供的支持。默认 RSF 采用 Hessian 4.0.7 作为默认序列化库。同时框架内置了 Java、Json 两个策略可以选用。

如果你请求时候使用的 Hessian,数据响应想要用 JSON 。也是可以被支持的。

第八层:这一层是最底层,负责网络数据的传输。因此,在这一层 RSF 内置了一套比较完整的 RSF 数据传输协议。文章在这里:https://my.oschina.net/u/1166271/blog/342091

第九层:就是计算机的 Socket 网络通信了。如果你想,这一层可以是 TCP 也可以是 UDP。不过 RSF 采用了 TCP 长链接。

时间: 2024-08-06 11:57:42

RSF 分布式 RPC 服务框架的分层设计的相关文章

基于netty轻量的高性能分布式RPC服务框架forest<下篇>

基于netty轻量的高性能分布式RPC服务框架forest<上篇> 文章已经简单介绍了forest的快速入门,本文旨在介绍forest用户指南. 基本介绍 Forest是一套基于java开发的RPC框架,除了常规的点对点调用外,Motan还提供服务治理功能,包括服务节点的自动发现.摘除.高可用和负载均衡等. 架构概述 Forest中分为服务提供方(RPC Server),服务调用方(RPC Client)和服务注册中心(Registry)三个角色. Server提供服务,向Registry注册

基于开源Dubbo分布式RPC服务框架的部署整合

一.前言 Dubbo 作为SOA服务化治理方案的核心框架,用于提高业务逻辑的复用.整合.集中管理,具有极高的可靠性(HA)和伸缩性,被应用于阿里巴巴各成员站点,同时在包括JD.当当在内的众多互联网项目中有着广泛应用.dubbo 通过高性能 RPC 实现服务的输出和输入功能,框架基于 Spring Framework 进行无缝集成,使用过程中基本看不到 Dubbo API的直接调用,Dubbo服务支持RMI.Hessian.Dubbo.WebService等众多通信协议,同时提供了对服务的监控和管

【Rpc】基于开源Dubbo分布式RPC服务框架的部署整合

一.前言 Dubbo 作为SOA服务化治理方案的核心框架,用于提高业务逻辑的复用.整合.集中管理,具有极高的可靠性(HA)和伸缩性,被应用于阿里巴巴各成员站点,同时在包括JD.当当在内的众多互联网项目中有着广泛应用.dubbo 通过高性能 RPC 实现服务的输出和输入功能,框架基于 Spring Framework 进行无缝集成,使用过程中基本看不到 Dubbo API的直接调用,Dubbo服务支持RMI.Hessian.Dubbo.WebService等众多通信协议,同时提供了对服务的监控和管

Thrift 个人实战--Thrift RPC服务框架日志的优化

前言: Thrift作为Facebook开源的RPC框架, 通过IDL中间语言, 并借助代码生成引擎生成各种主流语言的rpc框架服务端/客户端代码. 不过Thrift的实现, 简单使用离实际生产环境还是有一定距离, 本系列将对Thrift作代码解读和框架扩充, 使得它更加贴近生产环境. 本文讲述RPC服务框架中, 日志的重要性, 以及logid的引入. 日志不仅包含丰富的数据(就看是否会挖掘), 而且还是线上服务问题追踪和排查错误最好的方式. 日志级别 采用大家喜闻乐见的log4j作为该RPC服

RPC服务框架探索之Thrift

前言架构服务化后,需要实现一套方便调用各服务的框架,现在开源如日中天,优先会寻找开源实现,如果没有合适自家公司业务的,才会考虑从零开发,尤其是一切以KPI为准绳的公司,谁会跟钱过不去?N个月之前,公司大神就开始调研了,最后选中了Thrift这个RPC服务框架.使用不熟悉的技术,我会感到很恐惧,它就相当于一个黑盒,我对它一无所知,它是如何运转的?出了问题该如何解决?带着一丝不安,查阅了相关技术文档. RPC很早之前听说过soap,restful api,rpc之类的服务协议,一直都没有机会深入实践

rpc服务框架thrift介绍

rpc服务框架目前主要有 thrift, grpc, dubbo, HSF等 这里主要介绍thrift框架 git地址  :https://github.com/apache/thrift/tree/0.9.1 1. 接口定义 tutorial.thrift include "shared.thrift" /** * Thrift files can namespace, package, or prefix their output in various * target langu

唯品会RPC服务框架与容器化演进--转

原文地址:http://mp.weixin.qq.com/s?__biz=MzAwMDU1MTE1OQ==&mid=405781868&idx=1&sn=cbb10d37e25c76a1845f593a222da3c9&scene=0#wechat_redirect 编者按:本文是邱戈川在 3 月 27 日数人云"百万并发"活动的演讲,授权「高可用架构」首发.转载请注明来自高可用架构公众号「ArchNotes」.   邱戈川,唯品会分布式架构平台产品经理

分布式 RPC 系统框架 Dubbo入门介绍

Dubbo 概述 Dubbo 产生的背景 随着互联网项目用户量的急剧增长,访问并发量的陡然增加,一个应用中所有的功能都集中于一个项目中,已经完全不能满足需要了,系统性能急需提升.提升性能的最直接的方式是构建集群,构建具有负载均衡功能的集群.但仅仅依靠增加具有相同业务功能的主机来提高系统的性能,能力是有限的.需要将应用的功能进行分解,分解为多个子工程,每个子工程仅完成某一特定功能,例如,登录子工程.订单业务子工程.支付业务子工程.红包业务子工程等.即,将原来项目中的业务模块,变为了独立工程.在这种

RPC 服务框架 Dubbo 将正式得到官方维护与支持

近日,Dubbo 项目官网更新了一则公告: 在项目 GitHub 主页的 issue 中,也有阿里巴巴的工程师确认了这一消息. 看来,Dubbo 确实重新开始得到官方的维护了.不过,目前还没发现项目的最新规划图,所以暂不了解 Dubbo 后续的发展方向如何.我们将持续保持关注. Dubbo |?d?b??| 是一个分布式服务框架,致力于提供高性能和透明化的RPC远程服务调用方案,以及SOA服务治理方案. 其核心部分包含: 远程通讯: 提供对多种基于长连接的NIO框架抽象封装,包括多种线程模型,序