功能上的需求(重点):
一:账号信息控制
1: 邮箱登陆第一次登陆密码为标准,各环境之间账号均为隔离的;
2: 各个环境是隔离的,所以需要控制各个环境的用户组信息,开发环境不做控制
3: 记录登陆用户的操作历史并且控制key的操作权限,开发环境只能由具体维护人和授权用户控制,管理员可控制所有权限(操作key, 邮箱,ip信息之类的)
二: 整体流程设计(流程变换可发邮件通知)
使用的需求:
一: 配置精简(已完成)
<plugin:disconf id="disconfPlugin" scanPackage="com.example.disconf.demo">
<plugin:disconf-config path="classpath:config.properties"></plugin:disconf-config>
</plugin:disconf>
可插拔初步设想:组件之间的共性等需要经过调研等
二:启动问题慢的问题,disconf配置key越多加载越慢,针对每一个key发起http请求获取
解决思路:一次性开启多线程调用—> 更新并watcher
三: 一致性校验邮件通知,对于未生效的key,是否提供服务端主动推送;一致性校验由disconf-web定时器维护;
四: 统一操作工具类(直接操作disconf仓库数据)— 已完成
DisconfTools
五:实体bean 注入更新,是否通过可通过抽象实现回调改变该实例
目前存在一些已注入实体bean依赖disconf的key,当key信息变更后无法生效,比如redis
六: 托管文件的处理方式(暂无该需求)
七: 服务已启动,但是配置中心还未配置,等配置中心配置后,主动推送key的创建事件,客服端根据情况重新加载并注册watcher
八: 其他
客户端调用流程梳理:
1: 第一次扫描:
1、staticScannerMgrList 注解文件扫描
staticScannerFileMgr
staticScannerItemMgr
staticScannerNonAnnotationFileMgr — 非注解文件(托管)
2、注入仓库 DisconfCenterStore
// key: 配置文件名 // value: 配置文件数据 private Map<String, DisconfCenterFile> confFileMap = new HashMap<String, DisconfCenterFile>(); // 每个配置Item一条 // key: 配置项的Key // value: 配置项数据 private Map<String, DisconfCenterItem> confItemMap = new HashMap<String, DisconfCenterItem>();
3、 注入仓库完毕后,从disconf-web发起http拉取数据请求
5、 网络下载数据 —xml, properties, kvMap 注入第二步中的value值中, 当存在非注解式或注解式集合为空,则将文件内容写到配置库里(非注解式的生效问题可在这做扩展)
6、注入完毕后向zookeeper注册Watcher——> this.zk.getData(path, watcher, stat)
7、 watcher回调问题 —> 以及重新注册watcher
ClientCnxn SendThread等待服务端socket回执,获取结果判定是否xid==-1,如果是说明是watcher事件通知,加入一个阻塞队列,然后由EventThread进行消费,并执行watcher.process() 即NodeWatcher,更新入库后重新进行watcher并调用该key的回调函数
8、第二次扫描的作用
1: 更新回调, disconfUpdateService —> ScanDynamicModel (可添加一个统一回调入口,然后由统一回调入口调用自定义的回调函数)
DisconfCenterBaseModel.disconfCommonCallbackModel —>回调函数
2: 注入实体bean
3: 自定义的DisconfUpdateService在回调过程中可以修改已注入其他bean的实体
9、注解式的获取都是通过代理直接从仓库中获取的,而不是通过实例bean获取
10、 存活监控,客户端注册历史节点,随着session的关闭消失