閑話 寫這篇博客來記錄下這兩三個月來的所學所感。 目前市面上，有許許多多互聯網公司，對於類似BAT那種級別的，我們就不說了。那種剛起步，剛經歷第一輪融資或者投資的小型互聯網公司比比皆是。當這些公司業務量上來的時候、用戶量上來的時候，總是會有一個擔憂，之前運行穩定的公司平臺架構能否繼續穩定的服務下去，
閑話
寫這篇博客來記錄下這兩三個月來的所學所感。
目前市面上，有許許多多互聯網公司，對於類似BAT那種級別的，我們就不說了。那種剛起步，剛經歷第一輪融資或者投資的小型互聯網公司比比皆是。當這些公司業務量上來的時候、用戶量上來的時候，總是會有一個擔憂，之前運行穩定的公司平臺架構能否繼續穩定的服務下去，或者哪一塊地方需要重構。單憑平常的人工去分析日誌看代碼，其實是沒什麼用的費時且費力，結果也不准確。
這時，大家就會有一個統一的想法，就是怎麼不去弄一個監控系統，把公司內部所有的業務介面、訪問流量等等的東西全部都監控起來，然後再分析分析，看看哪裡耗時最嚴重的，哪裡的調用併發最高，哪個時段的CPU承受不住了等等，暴露出這些問題，再高薪聘請幾個有大公司架構經驗的架構師過來重新整理架構，一個個擊破，幫助公司走上高富帥的道路。
那這個監控系統到底誰來做呢？一是由自己來開發，二請人來開發。
我們的選擇是自己來開發。原因：
- 公司內部的業務比較複雜，自己人做出來的監控能對症下藥
- 公司發展不錯，招來大牛帶領我們一起搞，技術這塊不虛
- 招來大牛已經花了不少錢了，再去外面找人外包，老闆虛
監控思路
讓業務介面、伺服器等需要監控的地方，實時上報耗時、調用次數、錯誤拋出、CPU承載等信息，伺服器端接受這些信息，對這些信息進行歸類、分析、持久化等操作，通過一個監控報表的web站點顯示分析結果、歷史數據、告警操作等。
具體模塊
通過上述的思路，已經大概瞭解要搞這個監控需要做哪些事情了吧。那就細化出以下這幾個模塊[根據各個公司的具體業務而定製]:
- PhpSDK：供公司php相關業務上報監控數據到ApiService
- JavaSDK：供公司java相關業務上報監控數據到ApiService
- ApiService：提供支持高性能、低消耗的上報介面，供sdk端上報數據，並且按規則收集這些數據寄存到redis中
- MonitorStorage：讀取redis中的數據，進行峰值分析、是否按告警策略告警、統計等操作，並且把這些數據持久化到mysql中
- Web站點：實時讀取mysql中整理好的監控數據信息，以圖示、表格等方式來向被監控方展示各種信息，並可以在上面配置被監控方的所有統計策略、告警策略等等
流程圖如下：
要點事項
首先，你的監控是負責給人家監控的，不能影響人家的正常業務和效率。所以這樣sdk在設計開發的時候，就必須輕量化再輕量化，都給我非同步操作，意思就是說sdk就是埋個點而已，簡單通過CURL上報一下數據，不需要給我返回什麼，我們業務這邊也不管你搞什麼，就是多你這一行垃圾代碼而已，幾乎可以忽略的那種，這樣你的SDK就是完美的。
還有，就是ApiService的性能要求非常高，因為當接入你的監控系統的業務越來越多的時候，高可靠性、高併發性是必須的，只有當所有上報成功的數據的成功率到達99.9999%的時候，你的ApiService也是弔飛了。
MonitorStorage中文就是監控存儲，負責將數據分析、並且持久化，因為最後web那邊數據是你這裡持久化到mysql中的，所以準確性是很重要的,還有怎麼樣保證數據的實時同步、告警措施、分析措施是如何進行的都是需要考慮的。
報表那邊的話，就是做的好看一點，功能齊全一點了。折線圖什麼的圖示插件推薦用Highcharts或者國產百度團隊的ECharts插件也是非常不錯的。
個人心得
第一期的監控系統已經在生產環境開跑了，這兩天都在觀察、優化、各項測試進行中，希望我負責的MonitorStorage模塊堅強的挺住！！！讓數據量、併發量來得更猛烈些吧！
BB完了，繼續搬磚了！
如有雷同，純屬巧合
