前面一篇是报警执行器的定义与加载已经完成,但与之对应的报警规则有是如何定义和加载的呢?
此外,既然命名为规则,那么就需要有对应的解析器,以根据报警规则和报警类型等相关输入条件,来选择对应的报警执行器,因此本文主要包括的内容就比较清晰了
- 报警规则的定义
- 报警规则的加载
- 报警规则的解析以及报警执行器选择
I. 报警规则定义
目前针对报警规则没有给出自定义配置的入口,即完全采用了默认的方案,后续可以考虑支持适用方来自定义报警规则以及解析器,这样扩展性就更强了
首先说明下我们的设计规则,我们针对不同的AlarmExecute定义了一个优先级,我们的目标是
- 针对报警频率设置不同区间,每个区间对应一种报警类型
- 当实际调用的报警频率达到这个区间,就选择这种报警类型
- 同时也允许关闭根据频率选择报警器的功能,全程用一个默认
- 每种报警类型的用户都可以自定义
针对上面的目标,我们设计的类就比较明确了
阀值类:
1 | @Getter |
配置类:
1 | @Getter |
一个报警类型对应一个AlarmConfig
,这样当执行报警时,就可以很容易的获取对应的规则
同样根据定义,也可以看出报警规则比较简单,直接根据阀值区间来选择
II. 报警规则加载
关于如何加载报警规则,想了很久,选择把这块放开,因为我们无法确定,使用方的配置是存在什么地方的,而且使用的配置是否能和我们的设计的DO兼容也是个问题,因此干脆放手,同样是通过SPI的方式来做的
我们定义规则加载接口: IConfLoader
1 | public interface IConfLoader { |
上面的方法,可以划分为两类:
- 加载时使用
- load 为具体的执行加载配置到内存的方法,返回true表示加载成功
- order 排序
- getRegisterInfo 获取基础的配置信息(包括应用名等相关配置)
- 业务运行时使用
- alarmEnable : 是否开启报警 (当大量报警时,可以先关闭报警,然后再查问题)
- getAlarmConfig:核心方法,根据报警类型,返回对应的报警规则
系统默认提供一个从配置文件中加载报警规则的方案,主要会依赖两个配置文件
- alarm.properties : 初始化注册信息,内部保存 RegisterInfo 所需要的属性
- alarmConfig : 保存具体的报警规则,json格式
1. 配置加载
配置加载的实现逻辑,如下
1 | public class PropertiesConfLoader implements IConfLoader { |
主要查看默认的load方法即可, alarmEnable 和 getAlarmConfig还是比较简单的,看一下就知道怎么玩的
2. RegisterInfo 加载
上面的实现中,第一步就是从 alarm.properteis 文件中读取对应的配置,然后初始化 RegisterInfo对象
1 | @Data |
一个配置文件实例
1 | appName=test |
从配置文件中读取信息,然后初始化对象的过程就比较简单了,我这里做了一个小简化,使用反射的方式实现对象拷贝
1 | public static void copy(Properties source, Object dest) throws IllegalAccessException { |
上面的实现目前比较简单,没有考虑父类的情况,没有考虑复杂的数据类型转换,目前只支持了基本类型的转换,后续可考虑抽象
1 | public enum ParseFuncEnum { |
3. 报警规则加载
注册信息加载完毕之后,就可以获取报警规则的文件地址了,因此首先是读取配置规则的内容(我们要求是JSON格式),然后反序列化即可
将json串格式配置,反序列化为 BaseAlarmConf 对象
1 | private static final TypeReference<Map<String, BasicAlarmConfig>> typeReference |
需要额外说明一下,json串并没有直接的映射我们前面定义的 AlarmConfig
对象,因为在原型版本的设计的过程中,考虑到配置与内部的使用对象,可能不是特别匹配,最初的设计中,是希望直接将AlarmConfig中的alarmLevel直接替换成 AlarmExecute
实例对象的,然而在实际实现中没有这么干…,所以看源码时,这里就有点奇怪,后面完全可以干掉这个无用的逻辑
此外,就是需要给一个默认的配置项,当报警类型匹配不到对应的报警规则时,就选择默认的了
下面是一个报警配置的demo
1 | { |
III. ConfLoader选择并初始化
前面说明,为了确保报警规则的多样性存储与加载,我们支持用户自定义加载类,所以就会有这么个ConfLoaderFactory, 来创建系统中使用的ConfLoader
1 | public class ConfLoaderFactory { |
实现逻辑依旧采取了SPI机制,不够我们定义了一个优先级,默认从最高优先级的开始加载,加载成功之后,就选择这个东西了;否则继续加载下一个,当所有的ConfLoader加载完毕,都没有一个成功的,就抛出一个异常
IV. 小结
鉴于篇幅问题,关于报警规则与报警执行器之间的关系,对应的解释器放在下一篇进行说明,简要小结一下本文内容
- 报警规则: 采用阀值区间方式,将报警频率与报警执行器关联起来
- 规则加载: 支持SPI方式注入用户加载器,默认提供基于配置文件的加载器,且优先级最低
基本上本文说的就是下面这张图的内容了
V. 其他
相关博文
- 报警系统QuickAlarm总纲
- 报警系统QuickAlarm之报警执行器的设计与实现
- 报警系统QuickAlarm之报警规则的设定与加载
- 报警系统QuickAlarm之报警规则解析
- 报警系统QuickAlarm之频率统计及接口封装
- 报警系统QuickAlarm使用手册
- 报警系统QuickAlarm之默认报警规则扩展
项目
- 项目地址: Quick-Alarm
- 博客地址: 小灰灰Blog
个人博客: Z+|blog
基于hexo + github pages搭建的个人博客,记录所有学习和工作中的博文,欢迎大家前去逛逛
声明
尽信书则不如,已上内容,纯属一家之言,因本人能力一般,见识有限,如发现bug或者有更好的建议,随时欢迎批评指正,我的微博地址: 小灰灰Blog