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

目前所面臨的問題
目前的報警系統只能簡單的把用戶分為為不同的組，然后每個報警分發至一個和多個組，有的機器或服務的報警并不是每個用戶都關心，太多的報警反而會降低警惕心失去報警的意義。

1. 需求分析

　　本來打算實現分組報警和發送報警至項目負責人兩個功能，以及用戶按照用戶意愿選擇想要的接受報警的服務等功能，不過作為一個沒正經寫過項目小菜同學，還是以做出東西為第一目標。所以此系統第一版只實現以項目負責人為目標的報警分發功能。
　　思考：每個人都希望自己的產品百分百的完美，但是世上并沒有完美的東西，大家都只是在向著完美的方向努力向前而已。

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

　　目前我們只能實現一個功能，不過以后慢慢加入其他的功能，為了以后其他功能加入的方便，我們應該盡可能的保證程序的可擴展性。

2. 概要設計

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

3. 詳細設計

　?、賵缶斎胗袠擞?/h5>

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

　?、讷@取報警

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

　?、蹐缶c接收人的對應關系獲取

　　第一版的關系來自于文件，后面的版本有可能來自數據庫或者其他存儲。所以此處“對應關系”的處理也是一個接口。后面所有的操作依賴此接口

　?、馨l送報警

　　第一版只實現釘釘的發送報警，后面可能實現一些其他的發送方式，所以此處也是接口。

4. 接口設計

　　接口就等著后面邊實現邊決定把，現在也沒啥思路。畢竟我連接口都沒寫過呢。

總結

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