RPC、HTTP、DSF、Dubbo,每个都眼熟,就是不知道有什么联系?

发布时间:2024年01月22日

?一、HTTP 和 RPC

首先,http 与 rpc 有什么区别这个问题不太严谨,因为这俩就不是一个层级的东西。

HTTP

这个大家太熟悉了吧?日常接触最多的恐怕就是各种http协议的接口了。

没错,http它是一个协议。

其他在这里就不打算铺开了,以前整理过一些内容,有需要的可以跳转翻翻看:

RPC

RPC 是一种技术的代名词,全称是远程过程调用

远程?那是不是也有本地过程调用

没错,举个例子说明一下:

  • 本地过程调用:你的电脑上启动了一个服务A,运行程序的时候服务A里的各种方法的互相调用,就是本地了。
  • 远程过程调用:而隔壁小王也启动了一个服务B,他还说他里面提供了一个功能非常劲爆的方法,你也想去调用,这就是远程了。

而至于你怎么调用到小王服务器里的方法,那就是个实现方式的问题了。你为了简单,直接走http协议也行。如果觉得http满足不了需求,那么也可以基于tcp自定义一个协议。

远程调用过程

远程调用过程大概就是下图所示:

二、DSF

在工作中我发现公司有不少应用的名字是 DSF 打头的,DSF(Distributed Service Framework)其实就是指分布式服务框架

简单介绍 2 个点:为什么要用到分布式、这套DSF的包含的内容。

为什么要用到分布式

为什么要用到分布式服务?换个方式问那就是:分布式解决了什么问题。

首先,分布式架构是由单体架构演进而来,我司的业务系统也不例外。业务早期为了降低开发成本,实现快速上线,通常使用单体架构,所有的业务模块都在同一个应用里。

随着业务规模的扩张,单体应用的缺点就暴露出来,比如:

  • 系统耦合性高,当后面增加的功能越来越多,代码量巨增的时候,之前某个主程脑海中划分好的模块边界可能越来越模糊,导致调用关系混乱。
  • 改一赠二出现越来越多,经常存在开发修改了某个功能,而导致其他的功能有问题。
  • 某个功能有问题,整个一起回滚。
  • 语言单一,不能根据场景选择更合适的语言。比如其中有个模块系统主要是大数据分析,用 python 自然更加合适,因为它有丰富的类库。
  • 系统不易于拓展部署,比如系统中有一个功能流量很大,顶不住了就要加机器,那么在新机器上还是部署整个应用,不能单独的部署这个大流量的服务,会造成一定的资源浪费。 。。。

为了解决这些问题,于是把之前的业务进行垂直拆分成多个系统。系统与系统之间通过网络交互来完成各项业务处理,每个系统互相独立,可以单独部署。这种多个组件合作对外提供服务的形式,就是分布式了。

但是分布式同样也有它的缺点

  • 从之前的单应用调用,现在变成了多个应用直接的交互,调用链路变长,带来了网络开销,同时也给定位问题增加了难度。
  • 为了让你的应用更可靠,还有考虑其他的异常情况,比如调用失败、因某些问题导致的高频调用,对此还得做些 限流、熔断之类的措施。
  • 出现问题,可能会涉及多个服务的回滚,互相之间会有影响。
  • 环境变复杂了,增加了测试的复杂度。 。。。

简单来说,分布式帮我们克服了单体带来的瓶颈,但是为了分布式服务的稳定性,我们需要考虑更多的东西。

DSF包含的内容

那么一套分布式服务平台都有哪些内容,这里简单列举一下(以我司自研为例):

  • 服务注册:服务提供方上传契约信息,契约中包含服务组信息、服务信息、API信息等。
  • 服务发现:服务消费方寻址,基于某种粒度可以找到需要。
  • 服务调用:自定义超时时间、失败重试次数等,支持同步、异步调用等。
  • 负载均衡:比如支持轮询策略。
  • 网关:还可以通过网关对外提供一些rest api调用。
  • 健康检查:对服务提供方实例进行健康检查。
  • 服务拓扑:应用调用的上下游链路拓扑图。
  • 服务监控:展示服务运行状态、调用指标等。
  • 报警:当某个服务的实例异常数超过阈值,触发报警。
  • 限流:用于保护系统。
  • web前台:方便查看各种信息,各种常用功能的入口。 ...

三、Dubbo

对于分布式服务框架,如果有自研能力的话,可以结合公司业务实际情况进行高度定制化。如果初期不具备这样的条件,很多公司会选择成熟的开源框架直接使用,dubbo 就是这样的框架。

Dubbo 是阿里巴巴 2011年开源的一个基于 Java 的 RPC 框架,它实现了面向接口的代理 RPC 调用,并且可以配合 ZooKeeper 等组件实现服务注册和发现功能,并且拥有负载均衡、容错机制等。

dubbo 架构

这是官方文档的架构图,描述了 Dubbo 微服务组件与各个中心的交互过程。

  • Registry 注册中心:协调 Consumer 与 Provider 之间的地址注册与发现。
  • ConfigCenter 配置中心:存储 Dubbo 启动阶段的全局配置,保证配置的跨环境共享与全局一致性;负责服务治理规则(路由规则、动态配置等)的存储与推送。
  • Metadata 元数据中心:接收 Provider 上报的服务接口元数据,为 Admin 等控制台提供运维能力(如服务测试、接口文档等);作为服务发现机制的补充,提供额外的接口/方法级别配置信息的同步能力,相当于注册中心的额外扩展。

以上三个中心并不是运行 Dubbo 的必要条件,用户完全可以根据自身业务情况决定只启用其中一个或多个,以达到简化部署的目的。通常情况下,所有用户都会以独立的注册中心 开始 Dubbo 服务开发,而配置中心、元数据中心则会在微服务演进的过程中逐步的按需被引入进来。

所以,如果想快速实现一个分布式服务框架,就可以基于dubbo的方案来进行开发,既可以拿来就用,后续也可以进行二次开发。

最后感谢每一个认真阅读我文章的人,礼尚往来总是要有的,这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:

这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!?

文章来源:https://blog.csdn.net/2301_78843735/article/details/135756369
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。