一、dubbo-admin搭建及其一些bug的修改(持续更新bug的修改)

1、dubbo-admin的简述

dubbo-admin是dubbo的控制台开源项目，其提供了可视化的服务查询、治理及配置中心等功能，由2.7版本开始就采用了前后端分离，项目地址：https://github.com/apache/dubbo-admin，把源码下载到本地，就可以开始启动项目。

2、dubbo-admin搭建

项目结构：

??

由上面可以看出，项目主要分为三块，distribution(分布式部署)，server(后端服务)，ui(前端工程)，那我们主要来看server和ui(因为distribution我还没研究)。

server工程主要修改application.properties：

admin.registry.address=zookeeper://192.168.146.120:2181
admin.config-center=zookeeper://192.168.146.120:2181
admin.metadata-report.address=zookeeper://192.168.146.120:2181

解释一下上面配置的含义：我是用zk昨晚注册中心
registry.address表示注册中心的地址
config-center表示配置中心地址
meradata-report-address表示元数据是否要上传到注册中心
至此，dubbo-admin的配置结束，这里默认的端口是8080，当然你也可以配置项目的端口号，不过同时要修改ui工程访问后端的端口，修改的地方在ui/config/index.js中，不展开说了

3、dubbo-admin运行

先启动zk
再启动前后端工程，访问http://localhost:8081，界面如下：

至此dubbo-admin的搭建结束

4、dubbo-admin的一些bug

这里说的bug都是要启动dubbo的providers和consumers才能看得出来，有兴趣的童鞋可以去dubbo-admin上面我提的bug，这里我就简单说一下
一、配置中心创建应用级配置的路径错误
这是一个非常低级的bug，我就不知道为什么竟然一直都没发现，估计配置中心一般都不用它来创建吧
按照dubbo官方文档的路径说明：

由上面可以看出global级和应用级的路径应该是在同一级，但是dubbo-admin创建应用级配置时，会把应用级的文件夹放在global下(也就是dubbo下)，这就导致了dubbo项目启动时读不到相应应用级的配置。
bug修改：更改dubbo-admin创建应用级配置的路径
1、找到controller
其实dubbo-admin的项目也挺清晰的，对于配置的controller是ManagementController
2、一层层地找下去，就可以找到ManagementServiceImpl.getPath(String key)方法，然后把路径修改一下即可：

2、使用了配置中心，结果项目报错
其实就是在配置中心中不能有下面的配置

dubbo.registry.address=zookeeper://192.168.146.120:2181

有这个配置的话，server启动会报错，就是配置解析错误，把这个配置写到具体的dubbo应用上即可。
我估计这个也是bug，因为报的错是解析配置导致的
3、配置管理中输入*查询所有的配置，结果查不到consumer的应用级配置
由代码可见：

@RequestMapping(value = "/config/{key}", method = RequestMethod.GET)public List<ConfigDTO> getConfig(@PathVariable String key, @PathVariable String env) {
    Set<String> query = new HashSet<>();List<ConfigDTO> configDTOs = new ArrayList<>();if (key.equals(Constants.ANY_VALUE)) {
    query = providerService.findApplications();query.add(Constants.GLOBAL_CONFIG);} else {
    query.add(key);}for (String q : query) {
    String config = managementService.getConfig(q);if (config == null) {
    continue;}ConfigDTO configDTO = new ConfigDTO();configDTO.setKey(q);configDTO.setConfig(config);configDTO.setPath(managementService.getConfigPath(q));if (Constants.GLOBAL_CONFIG.equals(q)) {
    configDTO.setScope(Constants.GLOBAL_CONFIG);} else if(CLASS_NAME_PATTERN.matcher(q).matches()){
    configDTO.setScope(Constants.SERVICE);} else {
    configDTO.setScope(Constants.APPLICATION);}configDTOs.add(configDTO);}return configDTOs;}

输入*时只有providers和global的配置查出来，查阅源码你就会发现consumer的查询根本就没有实现，因此加上consumer的即可
ConsumerServiceImpl.java修改：

@Overridepublic Set<String> findApplications() {
    Set<String> ret = new HashSet<>();ConcurrentMap<String, Map<String, URL>> consumerUrls = getRegistryCache().get(Constants.CONSUMERS_CATEGORY);if (consumerUrls == null){
    return ret;}setApplications(ret,consumerUrls);return ret;}

其中setApplications(ret,consumerUrls);因为跟provider是相同的，所以我移到AbstractService上
controller的修改：

@RequestMapping(value = "/config/{key}", method = RequestMethod.GET)public List<ConfigDTO> getConfig(@PathVariable String key, @PathVariable String env) {
    Set<String> query = new HashSet<>();List<ConfigDTO> configDTOs = new ArrayList<>();if (key.equals(Constants.ANY_VALUE)) {
    query = providerService.findApplications();query.addAll(consumerService.findApplications());query.add(Constants.GLOBAL_CONFIG);} else {
    query.add(key);}for (String q : query) {
    String config = managementService.getConfig(q);if (config == null) {
    continue;}ConfigDTO configDTO = new ConfigDTO();configDTO.setKey(q);configDTO.setConfig(config);configDTO.setPath(managementService.getConfigPath(q));if (Constants.GLOBAL_CONFIG.equals(q)) {
    configDTO.setScope(Constants.GLOBAL_CONFIG);} else if(CLASS_NAME_PATTERN.matcher(q).matches()){
    configDTO.setScope(Constants.SERVICE);} else {
    configDTO.setScope(Constants.APPLICATION);}configDTOs.add(configDTO);}return configDTOs;}

这个查询*就可以了
4、关于登录失效时长的修改
这个其实也挺简单
在UserController.clearExpiredToken方法，这个就是一个定时器，修改一下
还有在拦截器AuthInterceptor.preHandle中也修改一下即可