【我要寫代碼】報警分發系統分析與設計

目前所面臨的問題
目前的報警系統只能簡單的把用戶分爲爲不一樣的組，而後每一個報警分發至一個和多個組，有的機器或服務的報警並非每一個用戶都關心，太多的報警反而會下降警戒心失去報警的意義。

1. 需求分析

　　原本打算實現分組報警和發送報警至項目負責人兩個功能，以及用戶按照用戶意願選擇想要的接受報警的服務等功能，不過做爲一個沒正經寫過項目小菜同窗，仍是以作出東西爲第一目標。因此此係統初版只實現以項目負責人爲目標的報警分發功能。
　　思考：每一個人都但願本身的產品百分百的完美，可是世上並無完美的東西，你們都只是在向着完美的方向努力向前而已。

1.1. 需求分析引申出來的問題

　　目前咱們只能實現一個功能，不過之後慢慢加入其餘的功能，爲了之後其餘功能加入的方便，咱們應該儘量的保證程序的可擴展性。

2. 概要設計

　　本程序會從接受一個報警信息開始的，每一個報警信息通過此係統的分發會發送至不一樣的用戶。因此每一個報警信息自己必須帶有標記，用於標記本身的屬性，好比屬於哪一個負責人。要把每一個報警信息和接收人對應起來，就必須有一個對於關係表，而且此對應關係存儲在某個介質上。爲了方便起見，此處以文件的形式來存儲報警與接收人的對應關係，最後就是以指定的方式發送報警了。因此此係統主要流程有下面三個部分：
　　1. 報警輸入標記
　　2. 獲取報警
　　3. 獲取報警與接收人對應關係
　　4. 根據標記和對應關係發送報警

3. 詳細設計

　　①報警輸入有標記

　　遇到沒標記的狀況怎麼辦：得有默認的發送方式及目標
　　用戶如何自定義標記：以配置的方式把標記的定義放入配置文件中

　　②獲取報警

　　報警信息的輸入只能來自prometheus的alertmanager?
　　把報警信息的輸入設計成一個接口，此接口有一些方法，而後來自alertmanager的報警實現此接口，而後此信息就能被後續的方法獲取並處理。

　　③報警與接收人的對應關係獲取

　　初版的關係來自於文件，後面的版本有可能來自數據庫或者其餘存儲。因此此處「對應關係」的處理也是一個接口。後面全部的操做依賴此接口

　　④發送報警

　　初版只實現釘釘的發送報警，後面可能實現一些其餘的發送方式，因此此處也是接口。

4. 接口設計

　　接口就等着後面邊實現邊決定把，如今也沒啥思路。畢竟我鏈接口都沒寫過呢。

總結

　　之前寫代碼，都是......不對，不該該稱做代碼。。。嗯。。。叫作「腳本「可能更爲合適。之前寫腳本呀，都是想到那寫到哪，也沒啥規劃，類什麼的真心得是懶得寫。至於繼承。。。做爲一個小菜，我仍是crtl+c/v搞定吧。畢竟是寫腳本嘛，以實現暫時的目標爲第一方向。不過如今呢，【我要寫代碼】了，已經不是簡單的腳本了，要有基本的結構，不說什麼高內聚，低耦合了，至少也得考慮到簡單的擴展吧。固然，依然還只是以實現簡單的功能爲目標。至於什麼併發之類的東東，仍是之後版本再考慮吧。不過，即便簡單也要有基本的東西。好比日誌，配置文件，異常處理~
　　第一次寫的分析確定一點都不像個分析，可是呢，就跟寫代碼同樣，老是要邁出第一步的，之後確定會儘可能愈來愈來噠，代碼也會愈來愈好~就醬！