這一篇我們來聊聊監控系統的架構。歡迎大家加入運維開發討論交流群來交流，群號 365534424，本文僅授權51reboot、51cto上發布。

架構這個詞太大了，這里我們縮小一下，只來談談宏觀的監控系統整體架構。在這個范圍里面，web由于負責統一的系統管理和操作功能，縮減為一個模塊。

最簡單的架構如下圖：

這是監控系統第一層的架構。比照百度地圖的話，我們可以認為這個是全國地圖。最粗粒度的幾個模塊就是這三個：web、數據采集、數據處理。

PUSH和PULL

我們先來關注數據采集模塊到數據處理和報警模塊的這個環節。

推和拉，技術選型里面常常遇到的一個選擇題。 在Client/server結構中，信息獲取方式是按“拉”(Pull)的模型進行的：服務器根據用戶終端發送的服務請求進行處理并返回用戶所需的結果。在Push模型中，服務器把信息“推”給Client。雖然兩者數據傳輸的方向都是從服務器流向Client，但操作的發起者是不同的。從“信源”與 “用戶”的關系來看，信息的流動可分為兩種模式，即信息推送與信息拉取模式。

兩種模型的對比見表格：

其中PUSH的好處是及時性好。但缺點是服務端要有比較復雜的狀態管理。同時在到達率等方面都會有一些糾結的地方。而PULL的好處則是服務端簡單，狀態管理簡單，但缺點是時效性上不可控。體現在監控系統上，如果所有要監控的監控項，都是需要Server端PUSH給Client，假設Client所在服務器關機了，那PUSH的時候就是不可達的。Server端就得想辦法記錄下來，并且再做重試等失敗處理。而如果是Client端主動來PULL就好辦了，服務器開機啟動之后，Client立刻來拉取。到達率肯定要好，對Server的管理也簡化了。但缺點就是想生效一個監控項，只能等著Client來 PULL，而無法立即生效。

這里還有一個比較經典的例子，也是我面試別人的時候總喜歡問的一個問題。當然我問面試者的時候主要是想去看看TA的邏輯思維能力。

題目：微博大家都用過。里面你可以關注一個人，也可以被人關注。當你發一條微博時，關注你的人都會收到一條提示。當你關注的人發一條微博時，你會收到一條提示。 請問這個提示，是PUSH 還是 PULL到你的微博客戶端(瀏覽器或者手機微博)上的?

面試者：肯定會有人說，PUSH唄。

面試官：OK，然后我就會問了，姚晨在新浪微博上的粉絲數是5000多萬，她發一條微博，是不是得PUSH 5000多萬個消息到各個賬號去?

面試者：額，那就是定時PULL

面試官：確定嗎?幾千萬個客戶端都PULL?

面試者：額。。。 面試者開始額頭黑線了。

面試官：請問該怎么辦?

PUSH的話，姚晨的一條微博，在系統里面就要產生5000萬條消息要處理。如果她一天發個100條，估計新浪微博瘋了。這還沒有考慮很多客戶端不登陸，消息就得緩存著。還有很多客戶端一下子通知不到，還得處理失敗。

PULL的話，如果大量用戶在使用的生產系統，對存儲和緩存是一個很大的挑戰。

具體的，大家可以再去google一下，這個事情其實有很多方案。

經驗比較豐富的研發一定會同意我的一個說法：兩個爭論不休的技術方案，最終能達成一個融合了二者的第三個方案。就好像兩個特別對立的談判方，到最后談判結果是一個融合或者叫妥協的方案。PUSH和PULL也可以二者融合，將做到取長補短，使二者優勢互補。根據推、拉結合順序及結合方式的差異，又分以下四種不同推拉模式：

◆先推后拉——先由服務端PUSH，再由Client端有針對性地拉;

◆先拉后推——根據Client端PULL的信息，服務端進一步主動PUSH與之相關的信息;

◆推中有拉——在數據推送過程中，允許Client隨時中斷并PULL更有針對性的信息;

◆拉中有推——根據Client端PULL的過程，Server主動推送相關的最新信息