【我要写代码】报警分发系统分析与设计

目前所面临的问题
目前的报警系统只能简单的把用户分为为不一样的组，而后每一个报警分发至一个和多个组，有的机器或服务的报警并非每一个用户都关心，太多的报警反而会下降警戒心失去报警的意义。

1. 需求分析

　　原本打算实现分组报警和发送报警至项目负责人两个功能，以及用户按照用户意愿选择想要的接受报警的服务等功能，不过做为一个没正经写过项目小菜同窗，仍是以作出东西为第一目标。因此此系统初版只实现以项目负责人为目标的报警分发功能。
　　思考：每一个人都但愿本身的产品百分百的完美，可是世上并无完美的东西，你们都只是在向着完美的方向努力向前而已。

1.1. 需求分析引申出来的问题

　　目前咱们只能实现一个功能，不过之后慢慢加入其余的功能，为了之后其余功能加入的方便，咱们应该尽量的保证程序的可扩展性。

2. 概要设计

　　本程序会从接受一个报警信息开始的，每一个报警信息通过此系统的分发会发送至不一样的用户。因此每一个报警信息自己必须带有标记，用于标记本身的属性，好比属于哪一个负责人。要把每一个报警信息和接收人对应起来，就必须有一个对于关系表，而且此对应关系存储在某个介质上。为了方便起见，此处以文件的形式来存储报警与接收人的对应关系，最后就是以指定的方式发送报警了。因此此系统主要流程有下面三个部分：
　　1. 报警输入标记
　　2. 获取报警
　　3. 获取报警与接收人对应关系
　　4. 根据标记和对应关系发送报警

3. 详细设计

　　①报警输入有标记

　　遇到没标记的状况怎么办：得有默认的发送方式及目标
　　用户如何自定义标记：以配置的方式把标记的定义放入配置文件中

　　②获取报警

　　报警信息的输入只能来自prometheus的alertmanager?
　　把报警信息的输入设计成一个接口，此接口有一些方法，而后来自alertmanager的报警实现此接口，而后此信息就能被后续的方法获取并处理。

　　③报警与接收人的对应关系获取

　　初版的关系来自于文件，后面的版本有可能来自数据库或者其余存储。因此此处“对应关系”的处理也是一个接口。后面全部的操做依赖此接口

　　④发送报警

　　初版只实现钉钉的发送报警，后面可能实现一些其余的发送方式，因此此处也是接口。

4. 接口设计

　　接口就等着后面边实现边决定把，如今也没啥思路。毕竟我链接口都没写过呢。

总结

　　之前写代码，都是......不对，不该该称做代码。。。嗯。。。叫作“脚本“可能更为合适。之前写脚本呀，都是想到那写到哪，也没啥规划，类什么的真心得是懒得写。至于继承。。。做为一个小菜，我仍是crtl+c/v搞定吧。毕竟是写脚本嘛，以实现暂时的目标为第一方向。不过如今呢，【我要写代码】了，已经不是简单的脚本了，要有基本的结构，不说什么高内聚，低耦合了，至少也得考虑到简单的扩展吧。固然，依然还只是以实现简单的功能为目标。至于什么并发之类的东东，仍是之后版本再考虑吧。不过，即便简单也要有基本的东西。好比日志，配置文件，异常处理~
　　第一次写的分析确定一点都不像个分析，可是呢，就跟写代码同样，老是要迈出第一步的，之后确定会尽可能愈来愈来哒，代码也会愈来愈好~就酱！