微服务之RPC框架Dubbo

RPC(远程过程调用)是实现跨服务器通信的解决方案,规定了通信协议和序列化协议。Dubbo是RPC的一种实现,支持多种通信和序列化协议,如dubbo、rmi、hessian等。Dubbo强调高并发性能,并通过Nacos进行服务注册与发现。负载均衡策略包括随机、轮询和最少活跃度等,确保服务的高效分配。
摘要由CSDN通过智能技术生成

什么是RPC?

RPC是Remote Procedure Call的缩写 翻译为:远程过程调用

目标是为了实现两台(多台)计算机\服务器,相互调用方法\通信的解决方案

RPC只是实现远程调用的一套标准

该标准主要规定了两部分内容

1.通信协议

通信协议指的就是远程调用的通信方式, 实际上这个通知的方式可以有多种, 例如:写信,飞鸽传书,闪送等等, 在程序中,通信方式也有多种

2.序列化协议

序列化协议指通信内容的格式,双方都要理解此格式, 发送信息是序列化过程,接收信息需要反序列化

序列化的方式也是多种的, RPC过程可以理解为项目内的功能的调用,类似面向对象编程实例化对象,调用方法的过程, 但是这个调用关系是远程的

什么是Dubbo?

Dubbo就是RPC概念的实现, Dubbo是SpringCloudAlibaba提供的, 能够实现微服务相互调用的功能

Dubbo对协议的支持?

Dubbo框架支持多种通信协议和序列化协议,可以通过配置文件进行修改, 

Dubbo支持的通信协议 :

  • dubbo协议(默认)

  • rmi协议

  • hessian协议

  • http协议

支持的序列化协议 : 

  • hessian2(默认)

  • java序列化

  • compactedjava

  • nativejava

  • fastjson

  • dubbo

Dubbo默认情况下,支持的协议有如下特征  

  • 采用NIO单一长链接

  • 优秀的并发性能,但是处理大型文件的能力差

Dubbo方便支持高并发和高性能  

Dubbo服务的注册与发现

在Dubbo的调用过程中,必须包含注册中心的支持, 项目调用服务的模块必须在同一个注册中心中, 注册中心推荐阿里自己的Nacos, 兼容性好, 能够发挥最大性能,  但是Dubbo也支持其它软件作为注册中心(例如Redis,zookeeper等)

服务发现,即消费端自动发现服务地址列表的能力,是微服务框架需要具备的关键能力,借助于自动化的服务发现,微服务之间可以在无需感知对端部署位置与 IP 地址的情况下实现通信

consumer服务的消费者,指服务的调用者(使用者)

provider服务的提供者,指服务的拥有者(生产者)

在Dubbo中,远程调用依据是服务的提供者在Nacos中注册的服务名称,  一个服务名称,可能有多个运行的实例,任何一个空闲的实例都可以提供服务

dubbo:
  protocol:
    # port设置-1 表示当前dubbo端口号支持自动生成
    # 生成规则是从20880开始寻找可用的端口号,如果当前端口号被占用,就会自动加1,直到找可用的为止
    port: -1
    # 设置连接的名称,一般固定为dubbo即可
    name: dubbo
  registry:
    # 声明当前dubbo的注册中心类型和位置
    address: nacos://localhost:8848
  consumer:
    # 当本项目启动时,是否检查当前项目需要的所有Dubbo服务是否可用
    # 我们设置它为false,表示启动时不检查,能够减少出错的情况
    check: false

要想实现Dubbo调用, 必须按照Dubbo规定的配置和行业标准的结构来实现

业界通用做法,是将生产者项目拆分为两个, 其中一个项目只有业务逻辑层接口, 另一个项目包含正常的配置和所有业务代码, 当消费者需要时只需要添加包含业务逻辑层接口的项目的依赖即可

实例:

创建csmall-stock-service项目

删除test\删除resources\删除SpringBoot启动类

csmall-stock升格为父项目,所以也要修改它的pom文件

<description>Demo project for Spring Boot</description>
<packaging>pom</packaging>
<modules>
    <module>csmall-stock-service</module>
</modules>

创建csmall-stock-webapi项目

webapi项目包含stock项目原有的所有配置和业务代码

创建好项目之后删除test文件夹、删除application.properties文件

然后父子相认  

Dubbo调用的好处是直接将要消费的目标(例如order模块中消费stock的方法)编写在当前消费者的业务逻辑层中,无需编写新的代码结构,开发流程不会因为Dubbo而变化

 

FAQ?

1.有哪些常见的RPC框架?

RMI, CXF/Axis2, Thrift, gRPC,

2.Dubbo的注册发现流程

1.首先服务的提供者启动服务时,将自己的具备的服务注册到注册中心,其中包括当前提供者的ip地址和端口号等信息,Dubbo会同时注册该项目提供的远程调用的方法

2.消费者(使用者)启动项目,也注册到注册中心,同时从注册中心中获得当前项目具备的所有服务列表

3.当注册中心中有新的服务出现时,会通知已经订阅发现的消费者,消费者会更新所有服务列表

4.RPC调用,消费者需要调用远程方法时,根据注册中心服务列表的信息,只需服务名称,不需要ip地址和端口号等信息,就可以利用Dubbo调用远程方法了

3.Dubbo提供了哪些负载均衡策略?

  • random loadbalance:随机分配策略(默认)
    假设我们当前3台服务器,经过测试它们的性能权重比值为5:3:1

    下面可以生成一个权重模型

    5:3:1

    随机生成随机数

    在哪个范围内让哪个服务器运行

    优点:

    算法简单,效率高,长时间运行下,任务分配比例准确

    缺点:

    偶然性高,如果连续的几个随机请求发送到性能弱的服务器,会导致异常甚至宕机

  • round Robin Loadbalance:权重平均分配
    如果几个服务器权重一致,那么就是依次运行

    但是服务器的性能权重一致的可能性很小

    所以我们需要权重平滑分配

    一个优秀的权重分配算法,应该是让每个服务器都有机会运行的

    如果一个集群服务器性能比为5:3:1服务为A,B,C

    1>A 2>A 3>A 4>A 5>A

    6>B 7>B 8>B

    9>C

    连续请求一个服务器肯定是不好的,我们希望所有的服务器都能够穿插在一起运行

    Dubbo2.7之后更新了这个算法使用"平滑加权算法"优化权重平均分配策略

    优点:

    能够尽可能的在权重要求的情况下,实现请求的穿插运行(交替运行),不会发生随机策略中的偶发情况

    缺点

    服务器较多时,可能需要减权和复权的计算,需要消耗系统资源

  • leastactive Loadbalance:活跃度自动感知分配
     

    记录每个服务器处理一次请求的时间

    按照时间比例来分配任务数,运行一次需要时间多的分配的请求数较少

  • consistanthash Loadbalance:一致性hash算法分配
     

    根据请求的参数进行hash运算

    以后每次相同参数的请求都会访问固定服务器

    因为根据参数选择服务器,不能平均分配到每台服务器上

    使用的也不

实际运行过程中,每个服务器性能不同

在负载均衡时,都会有性能权重,这些策略算法都考虑权重问题

 

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值