disconf:服务端使用总结

Posted 2020-10-30

1、服务端原理

      客户端启动，把配置文件，配置项存到仓库，等到服务端启动，从服务端拉取数据；服务端更新，则通过zk通知客户端，客户端知道更新后，会从服务端拉取最新的配置文件，如果更新的是redis配置，则需要写回调函数重启redis，不写，则要重启项目；更新其它的一些参数不需要重启项目；另外zk最好配成集群模式，这样可以做到高可用，一个主服务端挂了，会选举另外一个从的作为主服务端。

2、部署

      需要的软件mysql(存放一些初始化数据)、tomcat(存放服务端的动态文件)、nginx(存放服务端的静态文件)、zookeeper(存放客户端的注册信息)、redis(存放用户的登录、登出信息)

3、性能测试

      压测工具：Jmeter

      disconf和spring cloud config server，经压力测试，disconf的容错性、并发更高，有管理界面，  配置略复杂；spring cloud config性能较低，需要很多优化，并且需要同时掌握spring cloud的各个组件，才能更好的优化。

4、局限性

      1、修改mysql等服务器的配置，不能马上生效，必须重新启动项目，要生效的话，必须要写回调函数，增加编程的复杂性。

•        2、配置文件类、配置项所在的类、回调函数类 都必须是JavaBean，并且它们的”scope” 都必须是singleton的。用户标注配置时略有些不习惯。目前注解是放在get方法之上的，而不是放在域上。

•       3、注解放在get方法上，一般情况下是没有问题的。但是对于”call self”的方法调用，AOP无法拦截得到，这样就无法统一处理这些配置。一旦出现这种情况，“非一致性读问题”就会产生。