dubbo系列之-qos运维-2021-01-17

dubbo自带的运维工具dubbo-admin，主要面向开发人员去管理服务，携带很多管理、控制等功能，然后在dubbo新版本又推出了qos（Quality of Service），主要面向运维管理。我在之前公司有用到次功能，在和k8s结合时，通过>

dubbo原理和机制：应用可通过高性能的RPC实现服务的输出和输入功能，可以和Spring框架无缝集成。

注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小。

监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示。

服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销。

服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销。

扩展资料：

Dubbo是使用AtomicLong从0开始累计数字的，将打包的方法调用信息（如调用的接口名称，方法名称，参数值列表等），和处理结果的回调对象callback，全部封装在一起，组成一个对象object向专门存放调用信息的全局ConcurrentHashMap里面put(ID, object)将ID和打包的方法调用信息封装成一对象connRequest，使用IoSessionwrite(connRequest)异步发送出去。

当前线程再使用callback的get()方法试图获取远程返回的结果，在get()内部，则使用synchronized获取回调对象callback的锁， 再先检测是否已经获取到结果，如果没有，然后调用callback的wait()方法，释放callback上的锁，让当前线程处于等待状态。

参考资料来源：百度百科-Dubbo

1 Dubbo出现的背景

随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。

· 我们传统的网站结构为单一应用架构，也就是把所有的功能都放在一个项目工程里，部署在一台服务器上。

· 当访问量越来越大，我们需要通过不断添加服务器的方式来应对越来越大的访问量，或是将应用拆分成几个不相干的应用部署在不同的服务器上。

· 随着用户数的增加及业务的发展，拆分的应用越来越多，应用之间的交互及数据传输不可避免，则将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。

· 当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。

2 系统发展进化理论

系统发展经历过两个阶段：

· 集中式系统

就是把所有的程序、功能、模块集中到一个项目中，部署在一台服务器上，从而对外提供服务。

· 分布式系统

分布：在一定范围内分散开

分布式系统就是把所有的程序、功能拆分成不同的子系统，部署在多台不同的服务器上，这些子系统相互协作共同对外提供服务，对于用户而言并不知道后台是如何交互的，使用上和集中式系统一样。

3 认识集群及分布式

· 什么是集群？

就是将相同的程序、功能部署在两台或是多台服务器上，这些服务器对外提供的功能是完全一样的，集群就是通过不同横向扩展增加服务器的方式，以提高服务的能力。

· 什么是分布式？

就是将两个或多个程序、功能分别运行在两台或多台主机服务器上，这些服务对外提供的功能并不一样，它们通过相互协作最终完成某一服务或是功能。

简单来讲：如果两台服务器部署的程序完全一样则是集群，不一样就是分布式；分布式中的每一个节点都可以做成集群，而集群并不一定就是分布式。

4 Dubbo简介

Dubbo是一个分布式、高性能、透明化的RPC服务架构，提供服务自动注册、自动发现等高效服务治理方案。

Dubbo是阿里巴巴公司开源的一个高性能优秀的。

Dubbo官方网站：>

dubbo 是一款开源的 RPC 框架，主要有3个角色： 提供者（provider） 、 消费者（consumer） 、 注册中心（registry）

提供者启动时向注册中心注册服务地址，消费者启动时订阅服务，并通过获取到的提供者地址发起调用，当提供者地址变更时，通过注册中心向消费者推送变更。这就是 dubbo 主要的工作流程。

在275之前，dubbo 只支持接口级服务发现模型，>=275的版本提供了接口级与应用级两种服务发现模型，30之后的版本应用级服务发现更是非常重要的一个功能。

本文将从为什么需要引入应用级服务发现，dubbo 实现应用级服务发现的难点以及dubbo3 是如何解决这些问题这三个部分进行讲解。

开始前，我们先了解下 dubbo 最初提供的接口级服务发现是怎样的。

dubbo 服务的注册发现是以 接口 为最小粒度的，在 dubbo 中将其抽象为一个 URL ，大概长这样：

看着很乱？捋一捋：

无论是存储还是变更推送压力都可能遇到瓶颈，数据多表现在这两个方面：

这个问题好解决： 拆！

dubbo 在 27 之后的版本支持了 元数据中心 与 配置中心 ，对于URL的参数进行分类存储。持久不变的（如application、method等）参数存储到元数据中心中，可能在运行时变化（timeout、tag）的存储到配置中心中

无论是增加一台机器还是增加一个接口，其增长都是线性的，这个问题比单条数据大更严重。

当抹去注册信息中的 interface 信息，这样数据量就大大减少

只用过 dubbo 的同学可能觉得这很主流。

但从服务发现的角度来看：

无论是用的最多的服务注册发现系统 DNS ，又或者是 SpringCloud 体系、 K8S 体系，都是以应用为维度进行服务注册发现的，只有和这些体系对齐，才能更好地与之进行打通。

在我了解的范围里，目前只有 dubbo 、 SOFARPC 、 HSF 三个阿里系的 RPC 框架支持了接口级的服务发现。

provider端暴露服务：

consumer端引用服务：

本地调用远程的方法时，只需要配置一个 reference ，然后直接使用 interface 来调用，我们不必去实现这个 interaface，dubbo 自动帮我们生成了一个代理进行 RPC 调用，屏蔽了通信的细节，让我们有种 像调用本地方法一样调用远程方法的感觉 ，这也是 dubbo 的优势。

从这里我们能看出为什么 dubbo 要设计成接口级服务发现，因为要为每一个 interface 生成一个代理，就必须定位到该 interface 对应服务暴露的服务地址，为了方便，dubbo 就这么设计了。

如果让我来设计应用级服务发现，注册不必多说，按应用名注册即可。

至于订阅，在目前 dubbo 机制下，必须得告诉消费者消费的每个接口是属于哪个应用，这样才能定位到接口部署在哪里。

实现 dubbo 应用级服务发现，难点在于

保留接口级服务发现，且默认采取双注册方式，可配置使用哪种服务发现模型，如下配置使用应用级服务发现

名词有点高大上，但道理很简单，让 dubbo 自己去匹配，提供者注册的时候把接口和应用名的映射关系存储起来，消费者消费时根据接口名获取到部署的应用名，再去做服务发现。

数据存储在哪里？显然元数据中心非常合适。该方案用户使用起来和之前接口级没有任何不同，但需要增加一个元数据中心，架构变得复杂。

且有一个问题是，如果接口在多个应用下部署了，dubbo 查找的策略是都去订阅，这可能在某些场景下不太合适。

本文从接口级服务发现讲到应用级服务发现，包含了为什么 dubbo 设计成接口级服务发现，接口级服务发现有什么痛点？基于 dubbo 现状如何设计应用级服务发现，应用级服务发现实现有什么难点等等问题进行解答，相信看完的小伙伴一定有所收获。

总结一下服务注册与发现机制：
基于注册 中心的事件通知（订阅与发布），一切支持事件订阅与发布的框架都可以作为Dubbo注册中心的选型。

1、服务提供者在暴露服务时，会向注册中心注册自己，具体就是在${service interface}/providers目录下添加 一个节点（临时），服务提供者需要与注册中心保持长连接，一旦连接断掉（重试连接）会话信息失效后，注册中心会认为该服务提供者不可用（提供者节点会被删除）。

2、消费者在启动时，首先也会向注册中心注册自己，具体在${interface interface}/consumers目录下创建一个节点。

3、消费者订阅${service interface}/ [ providers、configurators、routers ]三个目录，这些目录下的节点删除、新增事件都胡通知消费者，根据通知，重构服务调用器(Invoker)。

以上就是Dubbo服务注册与动态发现机制的原理与实现细节。

---