一、分布式系统

1.1 集群和分布式

集群:多个机器提供一样的服务(实现高性能、高可用、 可伸缩、高可扩展 )
分布式:多个机器提供不同的服务,合起来为一个大服务

1.2 架构

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

二、Dubbo

dubbo是一个高性能、轻量级的开源RPC框架,由十层模型构成。

  • 业务逻辑层:提供接口和实现
  • RPC调用核心层:封装整个RPC的调用过程、负载均衡、集群容错、代理等功能
  • remoting:对网络核心协议和数据转化的封装
    在这里插入图片描述

2.1 核心能力

面向接口代理的高性能RPC调用
智能容错和负载均衡
服务的自动注册和发现
高度可扩展能力
运行期流量调度
可视化的服务治理和运维

2.2 负载均衡算法

  • 1 随机(通过区间的随机算法获取目标服务器,可针对某一个服务器增加权重 )
@Service(weight=100)
@Service(weight=200)

@Reference(loadbalance="random")

在这里插入图片描述

  • 2 轮询(123123分配,可针对性能好的服务器增加权重)
  • 3 一致性哈希(相同参数的请求落在同一台机器上)
  • 4 最少活跃调用数(服务者活跃数,初始值为0,收到请求+1,完成请求-1,处理请求快的活跃数下降的越快。使慢的服务器收到更少的请求)
  • 5 最短响应时间(计算目标服务请求的响应时间,响应时间短的配置更高的权重,再根据区间随机算法获取目标服务器)

2.3 工作原理

在这里插入图片描述

在这里插入图片描述

  • 1 服务启动时,服务提供者和服务消费者根据配置信息连接到注册中心,分别向注册中心注册和订阅服务,
  • 2 注册中心会根据注册信息返回服务提供者的信息给服务消费者,
  • 3 服务消费者把服务提供者的信息缓存到本地(避免多次访问注册中心带来的性能消耗),如果信息发生变更,消费者会收到注册中心的推送更新本地的缓存
  • 4 服务消费者会生成代理对象, 根据负载均衡策略选择目标服务提供者定时向monitor记录接口的调用次数和时间信息,拿到代理对象后,服务消费者通过代理对象发起接口的调用
  • 5 服务提供者收到请求后,根据数据进行反序列化,通过代理调用具体的接口的一个实现

2.4 超时与重试

超时:
当消费者调用服务者发生阻塞或者等待情形时,会一直等待下去
在某一峰值时刻,大量请求同时请求消费者,会造成线程的大量堆积,造成雪崩
dubbo会设置超时时间(这个时间段内无法完成服务访问则自动断开连接)

@Service(timeout=3000)

重试:
当出现网络抖动时,一次请求就会失败
dubbo可设置重试次数

//3s超时,重试2次,一共发送3次请求
@Service(timeout=3000,retries=2)

2.5 多版本

灰度发布:当出现新功能时,让一部分用户使用新功能,用户反馈没问题时再将所有用户迁移到新功能

dubbo使用version属性设置和调用同一个接口的不同版本

@Service(version="v1.0")
@Service(version="v2.0")

@Reference(version="v1.0")
private UserService userService;

在这里插入图片描述

2.6 集群容错

  • 1 重试(读操作),
  • 2 快速失败(写操作),
  • 3 安全失败(返回null),
  • 4 定时重发(不断请求直到成功),
  • 5 并行调用(一个成功即返回),
  • 6 广播调用(一个报错及报错)
@Reference(cluster="failover")

在这里插入图片描述

2.7 服务降级

// 调用失败返回null
@Reference(mock="fail:return null")

// 不调用直接返回null
@Reference(mock="force:return null")

在这里插入图片描述

2.8 Dubbo和SpringCloud的区别

  • 1 关注点不同。
    dubbo定位服务治理,主要解决服务的远程调用、流量分发、服务治理、流量控制;
    springcloud关注微服务整个的生态的解决方案,依托于Spring和Springboot
  • 2 底层原理不同。
    dubbo底层使用netty这种nio框架,基于tcp协议传输,通过Hession等序列化方式完成RPC通信;
    springcloud是基于http协议+rest风格的接口实现远程通信,http请求会有更大的报文,占用的带宽会更多,效率低一些 ,但rest相比RPC(代码级别的强依赖)更加灵活,服务提供者和服务调用方只需要根据http协议的契约完成通信。(openFeign是一个声明式的HTTP客户端,将HTTP请求转化为Java接口方法调用)

2.9 HTTP和RPC的区别

HTTP:是超文本传输的应用层协议,服务于网页端和服务端的数据传输,适用于面向网络的通信
RPC:(remote procedure call)是远程过程调用协议,包括通信协议(如http,tpc)和序列化协议(protobuf,thrift),适用于面向应用程序的通信
RPC和HTTP的关系,前者是方法,后者是协议。
区别:

  • 传输协议
    RPC可以基于TCP,也可以基于HTTP
    HTTP只能基于HTTP
  • 传输效率
    RPC如果使用自定义的TCP协议,可以让请求的请求头信息更少
    HTTP的请求头有很多无用信息,如refer,keepalivetime,last-modified
    因此,RPC传输效率更高。
  • 性能
    RPC可以基于thrift或protobuf来实现高效的二进制传输
    HTTP也可以使用protobuf,但目前主流的浏览器大部分都是JSON实现的
    因此,RPC性能更好
  • 适用场景
    RPC用于公司内部的服务调用
    HTTP用于对外的异构环境,还有浏览器的调用APP接口调用,允许不同技术栈
Logo

瓜分20万奖金 获得内推名额 丰厚实物奖励 易参与易上手

更多推荐