一、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修改:
@Override
public 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中也修改一下即可