关于dubbo:一篇文章带你对dubbo-admin知根知底

本篇次要介绍一下 dubbo admin 的应用，应用之前咱们须要先进行搭建，对于如何搭建，参考 dubbo admin 搭建。

如何应用

登录胜利之后咱们会看到如下界面，下面的服务就是咱们注册核心注册下来的服务

在对应的服务上点击详情

此时咱们就能看到对应服务的相干信息，很多时候如果你配置有问题是看不到这么多信息的，这里须要重点阐明一下这个页面怎么进去元数据信息的。

元数据信息怎么显示

1）application.properties 配置文件要配置好配置核心

也就是上图中的 admin.config-center，其余两个就间接正文掉不配了，这一点 dubbo 官网也提到了

官网这里提到一点，须要在配置核心配置注册核心以及元数据中心地址，这点怎么做呢？我这里也阐明一下（用的 zookeeper）
1）进入 zookeeper 装置目录的命令目录下，执行 ./zkCli.sh，登录到 zookeeper（如果你不是在本机的则须要制订 ip 和端口）
2）创立 /dubbo/config/dubbo/dubbo.properties 节点，执行命令
create /dubbo/config/dubbo/dubbo.properties ""，如果上一层目录不存在的，则一层层创立。
3）ctrl + c 或者执行quit 退出 zookeeper 命令窗口，再执行

./zkCli.sh -server 127.0.0.1:2181 set /dubbo/config/dubbo/dubbo.properties "dubbo.registry.address=zookeeper://192.168.10.118:2181
dubbo.metadata-report.address=zookeeper://192.168.10.118:2181"

这里须要留神的是 dubbo.registry.address 和 dubbo.metadata-report.address 之间是要换行的，不然前面 dubbo-admin 是无奈解析胜利的。实现这几步，元数据信息如果还不显示，那还有一种可能：你应用的 dubbo 版本太低，咱们这里介绍的 dubbo-admin 是基于 dubbo 2.7.12 版本的，去注册核心获取元数据信息的节点是 /dubbo/metadata/com.example.dubboprovider.rpc.CityService/provider/provider，如果你服务援用的版本是 2.7.2 之前的版本，它注册到的节点门路是 /dubbo/metadata/com.example.dubboprovider.rpc.CityService/provider/provider/service.data，这样就导致 dubbo-admin 获取不到元数据信息了。别问我怎么晓得的，调进去的。

接口测试

有了元数据信息之后，咱们就能够应用这个测试的性能了，尽管咱们在 测试工具 这篇文章讲过其余的测试工具，然而其实 dubbo-admin 自带了测试性能。
找到对应的服务之后点击测试按钮

而后就会显示所有的接口

点击对应的接口进行测试

当然你也能够在这边进入测试页

接口文档（dubbo-api-docs）

在界面中，咱们能够看到有一个接口文档的项

这个其实就是 dubbo-admin 应用了 dubbo-api-docs 的性能，这里说的应用并不是说间接引入对应的包，而是依据 dubbo-api-docs 裸露服务的规定来调用服务。
简略的介绍一下 dubbo-api-docs 原理：
其实就是裸露一个 org.apache.dubbo.apidocs.core.providers.IDubboDocProvider 接口，看下源码

对于应用 dubbo-api-docs（基于 2.7.8.1 版本），这里须要留神几点：

• dubbo 版本须要在 2.7.7 以上，不然不反对 DubboService 注解

• 配置文件中肯定要配置 ApplicationConfig、RegistryConfig、ProtocolConfig，须要在 application.properties 中配置，其余中央比方 dubbo.properties 中配置会启动出错，临时还没找到具体起因（前面会再看下）
  对于具体的应用，官网写得比拟具体了，参考 dubbo-api-docs 应用。
  dubbo-api-docs 介绍到这，持续看接口文档性能应用，目前是直连模式间接去提供者取的，所以填入提供者的 ip 和端口（后续据说会反对去注册核心拿），点击加载接口列表
  
  这里有个点要留神：dubbo-admin 默认调 dubbo-api-docs 时会带上版本号 v1 以及 group 值 apiDocsGroup，而咱们服务提供者并没有，这样会导致调用失败，所以能够在 application.properties 中加配置设置为空值或者你本人须要的值
  
  点击服务之后就会呈现服务接口
  
  点击接口之后左边就会呈现相应的接口信息
  

  配置管理

  咱们晓得 dubbo 是反对配置核心的，这个配置管理其实就是对于配置核心的治理。
  
  默认是搜寻 global，也就是全局的配置，这里以 zookeeper 为例，对应的节点门路是 /dubbo/config/dubbo/dubbo.properties 来存全局配置。
  
  这个门路是不是很相熟？没错，就是下面介绍元数据怎么来的时候配置过的节点，这个就是对那个配置的治理，咱们看下外面的数据
  
  接着咱们来创立一个配置，大略如下
  
  这里的利用名其实就是一个节点门路的 key，存储格局为 /dubbo/config/dubbo/{key}/dubbo.properties，所以咱们这个后果最终保留到 zk 的这个节点下，咱们在 zk 中也能看到
  
  而后搜寻一下刚创立的配置信息
  

  服务统计

  服务统计其实就是一个监控的性能，会对服务的 qps、rt 等进行统计展现，这个版本目前性能还不是很欠缺
  

  服务关系

  先来看简略的服务关系，这个比较简单，就是基于服务全名（包名全门路）来关联消费者和提供者，不多做介绍。
  

  服务统计

  这里又波及到 dubbo 版本了，dubbo 在 2.7.2 开始才提供了度量指标的性能，服务统计性能在这个版本目前应该是无奈应用的，我在 github 上曾经提了 issue，其实个人感觉齐全能够将 metrics 集成到 monitor（前面会独自再介绍一下 dubbo monitor），这里再说一下 dubbo admin 其实还是须要本人保护，社区也并不沉闷，尽管目前这个性能是有问题的，还是介绍一下如何应用。
  1）dubbo 服务配置 metrics 内容，次要就是端口号和协定就行了，如果这里不配协定，默认是 dubbo
  
  2）服务配置，生产端同理
  
  3）发一次 dubbo 调用，促成生成 MetricsService
  4）在 dubbo admin 中输出 Ip 发动查问
  
  如果配置都正确的状况下，这里会提醒 service not fund 的异样，具体起因能够看下面提的 issue，然而我看网上还是有些人能用一部分服务统计性能的（除了线程池），如果你发现你能用服务统计性能，那请留言探讨。

  服务 mock

  这个性能临时也没有实现

  服务治理

  这是一个大头，放在最初压轴，这个版本的 dubbo admin 都是基于配置核心来治理的，所以前提是要配置好配置核心，内容也比拟多，咱们也一点一点介绍。

  条件路由

  先解释下什么是条件路由：基于 生产端条件 => 提供端条件 的规定对生产端的申请进行路由。具体的规定以及实现机制，举荐看下这篇 Dubbo 路由机制的实现。从代码中没看到配置和读取 rule 的逻辑，所以目前应该只能通过注册核心告诉机制来触发条件路由，这里说说怎么应用 dubbo admin 来创立
  
  下面就是创立的一个规定，对于服务级别的，dubbo admin 会记录到节点 dubbo/config/dubbo/com.example.dubboprovider.rpc.CityService::.condition-router 中，com.example.dubboprovider.rpc.CityService:: 是默认生成的 id，规定是 service: version: group。如果是利用级别，则是 dubbo/config/dubbo/consumer.condition-router，id 就是利用名。设置胜利之后，咱们能够看到 zk 中有了
  
  而后生产端会收到对应的告诉
  
  能够看到这是一个路由规定的节点告诉，当然如果你配置了配置核心，则在 org.apache.dubbo.rpc.cluster.router.condition.config.ListenableRouter#process 这里收到告诉。
  依据服务名配置路由对应代码中的 ServiceRouter，依据利用配置路由对应代码中的AppRouter，外围逻辑还是在他们的父类ListenableRouter 中触发，匹配的规定在对象的 matches 变量中寄存，不匹配的在 mismatches 中寄存。
  须要留神：2.7 版本之后须要配置配置核心才行

  标签路由

  标签路由，顾名思义就是依据标签进行路由，咱们能够通过标签给对服务节点进行分组，而后在客户端打标签，将客户端的申请限定在标签对应分组的节点之中。它的原理和条件路由一样，也是须要通过治理平台配置来回调更新客户端的 router 规定。对应的是TagRouter。来看下怎么用
  1）先给服务端打标签分组
  
  2）创立好之后，会在 dubbo/config/dubbo/provider.tag-router 门路下创立节点，能够看到曾经有了
  
  3）在消费者端打上要走的标签

    @DubboReference(tag = "don")
    CityService cityService;

  4）发申请，通过路由之后，咱们能够看到选中了对应标签的分组
  

  黑白名单

  这里所说的黑白名单并不是咱们想的在服务端对申请的 ip 进行管制，而是基于条件路由来对客户端进行管制，host = xxx => 来示意黑名单地址，host != xxx => 来示意白名单地址。这里要留神一个点：如果你有多张网卡的，则此名单要全副设置下来或者在 dubbo 端配置地址，不然过滤可能不失效。上面来试一下，创立一个 consumer 的黑白名单
  
  我本地的电脑 ip 为 10.60.45.143，发一个申请，发现被拦挡了
  

  动静配置

  Dubbo 能够通过内部化配置将配置信息托管在配置核心，这个动静配置的性能就是动静批改配置中的配置，使得在 Dubbo 中的配置实时失效。
  它是对节点 /dubbo/config/dubbo/{key}.configurators 的更新或者创立。

  权重调整

  这个比较简单，就是如果服务端有多个节点，通过调整权重，咱们能够将申请按比例进行摊派，也是保留到节点 /dubbo/config/dubbo/{key}.configurators
  
  看界面基本上曾经十分清晰，不再多做介绍。

  负载平衡

  这个也比较简单，就是如果服务端有多个节点，通过负载平衡策略制订，咱们能够将申请进行定制化散发，也是保留到节点 /dubbo/config/dubbo/{key}.configurators
  
  看界面基本上曾经十分清晰，不再多做介绍。

  总结

  Dubbo Admin 其实内容看起来不多，然而波及到的 Dubbo 知识点十分多，如果没弄懂 dubbo，应用上会有很多问题呈现并且没有那么容易解决，我感觉官网还是应该出一个具体点的操作手册。