dubbo admin源码

Dubbo Admin源码来自Apache Dubbo官方，是一套可视化管理平台的源代码，用于管理、监控和配置Dubbo服务。开发人员借助这套源码，能够搭建属于自己的Dubbo管理后台，从而便捷地查看服务注册情况、服务提供者与消费者的相关信息，以及应用运行状态等内容。

Dubbo Admin以Java语言构建，面向分布式服务架构提供可视化管理能力，涵盖服务治理、配置管理、路由规则管理以及元数据查看等模块。开发团队可借助Web控制台执行部分运维与管理操作，从而减轻服务排查和配置维护的负担。

这份Dubbo Admin源码包面向正在钻研Dubbo框架、着手搭建微服务系统，或有二次开发管理平台需求的开发者。拿到源码后，可以按照项目实际情况自行编译并部署，再配合注册中心与Dubbo服务环境，把整套服务治理体系搭建起来。

主要核心部件

网络通信框架Remoting，支持sync-over-async与request-response两种消息机制。

RPC 是对远程过程调用的抽象封装，具备负载均衡、容灾以及集群能力

服务注册与事件发布订阅机制由服务目录框架承载，Registry 正是这一框架的实现。

更新日志

v0.7.0版本

新功能

支持存储的资源级隔离。

集成 informer 框架，为服务发现与引擎功能提供支撑。

在 client-go 里，缓存式存储内存类型同样得到了支持。

Kubernetes 版本的 Engine 实现。

在本地缓存里完成 Counter 的构建。

来自：1、建立统一的错误处理流程，让错误提示以更清晰的方式呈现。

可对控制台中的多个注册中心进行管理。

Nacos 所提供的服务发现能力，正是这一版本中落地的具体方案。

组件启动遵循依赖先后次序。

Zookeeper 可用于实现服务发现机制。

错误修复

修复编译错误。

修复计数器注册漏洞。

修正了索引器初始化顺序不当所引发的空指针异常问题。

未登录用户会被引导至登录页。

增强功能

基础项目已从 dubbo-kubernetes 迁移到当前仓库。

整理工程目录，把不再使用的旧代码一并清除。

文档与 CI

修复 CI 问题。

工作原理

Provider

提供服务的一方被称为“服务提供者”。

Consumer

发起远程服务调用的那一方，被称作“服务消费者”。

Registry

服务注册中心是一种中心化的目录服务，承担服务注册与发现的功能。

Monitor

服务监控中心是一种日志服务，用于记录各服务被调用的频次与耗时情况。

(1) 连通性：

注册中心承担服务地址的登记与查询职责，作用类似于目录服务；服务提供方与消费方仅在启动阶段同注册中心进行交互，该中心并不转发请求，因此承载的压力相对有限。

监控中心承担各服务调用次数与调用时间的统计工作。数据先在内存中完成汇总，随后每分钟向监控中心服务器发送一次，最终通过报表形式呈现。

服务方将自身可提供的服务登记至注册中心，同时把调用耗时上报给监控中心，该耗时不含网络传输开销。

服务消费者从注册中心拉取服务提供者的地址清单，依据负载算法直接向提供者发起调用，并将调用耗时上报至监控中心，该耗时涵盖网络传输开销。

注册中心、服务消费者与服务提供者彼此之间都保持长连接，监控中心不在此列。

注册中心借助长连接实时掌握服务提供者的在线状态；一旦服务提供者发生宕机，注册中心会立刻向消费者推送事件通知。

注册中心与监控中心即使整体不可用，也不会波及正在运行中的提供者和消费者；原因在于消费者已在本地保存了提供者列表的缓存。

注册中心与监控中心均非必选项，服务消费者也能直接连接服务提供者。

(2) 健壮性：

监控中心发生故障时，软件本身仍可正常操作，仅会造成部分采样数据的丢失。

服务注册中心在数据库失效的情况下，依然可以借助缓存返回服务列表供查询使用，只是新服务的注册操作将无法进行。

注册中心采用对等集群架构，当其中任一节点发生故障时，系统会自动切换至其他可用节点继续运作。

服务注册中心即使全线失效，服务提供方与消费方之间依然可以借助本地缓存完成通信。

服务端采用无状态设计，单台节点发生故障时不会波及正常使用

一旦所有服务提供方都停止运行，服务消费方应用便会陷入不可用状态，并持续不断地尝试重连，直到服务提供方重新恢复为止。

(3) 伸缩性：

注册中心采用对等集群架构，支持动态扩充部署实例，新增节点后所有客户端能够自动感知到注册中心的变化

服务实例本身不保存状态，因此可以根据需要随时扩充部署的节点数量；注册中心会把新增提供者的相关信息推送给调用方。