Dubbo

小雀小吕

已于 2023-09-29 10:47:36 修改

阅读量35

点赞数

文章标签： dubbo

于 2023-09-27 23:49:07 首次发布

本文链接：https://blog.csdn.net/m0_57468283/article/details/133353909

版权

Dubbo是什么，有哪些核心功能

Dubbo是一款高性能分布式的服务调用框架

由十层模型构成

Dubbo的核心功能

1.远程通信：提供多种基于长连接的NIO框架抽象封装，包括多线程模型，序列化，以及请求-响应模式的信息交换消息，透明化的远程方法调用。使调用远程方法就像调用本地方法一样简单。只需要简单的配置。

2.集群容错：提供基于接口方法的透明远程调用，包括多协议支持，负载均衡，集群容错，服务降级，地址路由，动态配置等集群设置，实现高可用

3.自动发现：基于注册中心服务，服务自动注册与发现，不用手动添加服务地址，注册中心基于接口名查询服务地址，并自动删除和添加服务。

Dubbo 核心的服务治理功能

Dubbo 抽象了一套微服务治理模式并发布了对应的官方实现，服务治理可帮助简化微服务开发与运维，让开发者更专注在微服务业务本身。

地址发现

Dubbo 服务发现具备高性能、支持大规模集群、服务级元数据配置等优势，默认提供 Nacos、Zookeeper、Consul 等多种注册中心适配，与 Spring Cloud、Kubernetes Service 模型打通，支持自定义扩展。

负载均衡

Dubbo 默认提供加权随机、加权轮询、最少活跃请求数优先、最短响应时间优先、一致性哈希和自适应负载等策略

流量路由

Dubbo 支持通过一系列流量规则控制服务调用的流量分布与行为，基于这些规则可以实现基于权重的比例流量分发、灰度验证、金丝雀发布、按请求参数的路由、同区域优先、超时配置、重试、限流降级等能力。

链路追踪

Dubbo 官方通过适配 OpenTelemetry 提供了对 Tracing 全链路追踪支持，用户可以接入支持 OpenTelemetry 标准的产品如 Skywalking、Zipkin 等。另外，很多社区如 Skywalking、Zipkin 等在官方也提供了对 Dubbo 的适配。

可观测性

Dubbo 实例通过 Prometheus 等上报 QPS、RT、请求次数、成功率、异常次数等多维度的可观测指标帮助了解服务运行状态，通过接入 Grafana、Admin 控制台帮助实现数据指标可视化展示。

Dubbo 服务治理生态还提供了对 API 网关、限流降级、数据一致性、认证鉴权等场景的适配支持。

Dubbo常用的5种负载均衡策略

第一种是加权随机(默认)：假设我们有一组服务器 servers = [A, B, C]，他们对应的权重为 weights = [5, 3, 2]，权重总和为 10。现在把这些权重值平铺在一维坐标值上，[0, 5) 区间属于服务器 A，[5, 8) 区间属于服务器 B，[8, 10) 区间属于服务器 C。接下来通过随机数生成器生成一个范围在 [0, 10) 之间的随机数，然后计算这个随机数会落到哪个区间上就可以了。

第二种是最小活跃数：每个服务提供者对应一个活跃数 active，初始情况下，所有服务提供者活跃数均为 0。每收到一个请求，活跃数加 1，完成请求后则将活跃数减 1。在服务运行一段时间后，性能好的服务提供者处理请求的速度更快，因此活跃数下降的也越快，此时这样的服务提供者能够优先获取到新的服务请求。

第三种是一致性 hash：通过 hash 算法，把 provider 的 invoke 和随机节点生成 hash，并将这个 hash 投射到 [0, 2^32 - 1] 的圆环上，查询的时候根据 key 进行 md5 然后进行 hash，得到第一个节点的值大于等于当前 hash 的 invoker。

第四种是加权轮询：比如服务器 A、B、C 权重比为 5:2:1，那么在 8 次请求中，服务器 A 将收到其中的 5 次请求，服务器 B 会收到其中的 2 次请求，服务器 C 则收到其中的 1 次请求。

第五种是最短响应时间权重随机：计算目标服务的请求的响应时间，根据响应时间最短的服务，配置更高的权重进行随机访问。

Dubbo的工作原理

1.服务启动的时候，provider 和 consumer 根据配置信息，连接到注册中心 register，分别向注册中心注册和订阅服务

2.register 根据服务订阅关系，返回 provider 信息到 consumer，同时 consumer 会把 provider 信息缓存到本地。如果信息有变更，consumer 会收到来自 register 的推送

3.consumer 生成代理对象，同时根据负载均衡策略，选择一台 provider，同时定时向 monitor 记录接口的调用次数和时间信息

4.拿到代理对象之后，consumer 通过代理对象发起接口调用

5.provider 收到请求后对数据进行反序列化，然后通过代理调用具体的接口实现

Dubbo和SpringCloud的区别

Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。而 Spring Cloud 诞生于微服务架构时代，考虑的是微服务治理的方方面面，另外由于依托了 Spirng、Spirng Boot 的优势之上，两个框架在开始目标就不一致，Dubbo 定位服务治理、Spirng Cloud 是一个生态。

两者最大的区别是 Dubbo 底层是使用 Netty 这样的 NIO 框架，是基于 TCP 协议传输的，配合以 Hession 序列化完成 RPC 通信。而 SpringCloud 是基于 Http 协议+Rest 接口调用远程过程的通信，相对来说，Http 请求会有更大的报文，占的带宽也会更多。但是 REST 相比 RPC 更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖。