與單體應用相比，在微服務架構下，一次用戶調用會因為服務化拆分後，變成多個不同服務之間的相互調用，這也就需要對拆分後的每個服務都監控起來。
在講述如何監控微服務調用前，首先你要搞清楚三個問題：監控的對象是什麼？具體監控哪些指標？從哪些維度進行監控？下面就從這三個問題開始，一起來看看如何監控微服務調用。
監控對象
既然要監控，那麼要監控哪些對象呢？根據我的實踐經驗，對於微服務系統來說，監控對象可以分為四個層次，由上到下可歸納為：
- 用戶端監控。通常是指業務直接對用戶提供的功能的監控。以微博首頁 Feed 為例，它向用戶提供了聚合關注的所有人的微博並按照時間順序瀏覽的功能，對首頁 Feed 功能的監控就屬於用戶端的監控。
- 接口監控。通常是指業務提供的功能所依賴的具體 RPC 接口的監控。繼續以微博首頁 Feed 為例，這個功能依賴於用戶關注了哪些人的關係服務，每個人發過哪些微博的微博列表服務，以及每條微博具體內容是什麼的內容服務，對這幾個服務的調用情況的監控就屬於接口監控。
- 資源監控。通常是指某個接口依賴的資源的監控。比如用戶關注了哪些人的關係服務使用的是 Redis 來存儲關注列表，對 Redis 的監控就屬於資源監控。
- 基礎監控。通常是指對服務器本身的健康狀況的監控。主要包括 CPU 利用率、內存使用量、I/O 讀寫量、網卡帶寬等。對服務器的基本監控也是必不可少的，因為服務器本身的健康狀況也是影響服務本身的一個重要因素，比如服務器本身連接的網絡交換機上聯帶寬被打滿，會影響所有部署在這臺服務器上的業務。
監控指標
搞清楚要監控的對象之後，需要監控具體哪些指標呢？根據我的實踐經驗，通常有以下幾個業務指標需要重點監控：
- 請求量。請求量監控分為兩個維度，一個是實時請求量，一個是統計請求量。實時請求量用 QPS（Queries Per Second）即每秒查詢次數來衡量，它反映了服務調用的實時變化情況。統計請求量一般用 PV（Page View）即一段時間內用戶的訪問量來衡量，比如一天的 PV 代表了服務一天的請求量，通常用來統計報表。
- 響應時間。大多數情況下，可以用一段時間內所有調用的平均耗時來反映請求的響應時間。但它只代表了請求的平均快慢情況，有時候我們更關心慢請求的數量。為此需要把響應時間劃分為多個區間，比如 0～10ms、10ms～50ms、50ms～100ms、100ms～500ms、500ms 以上這五個區間，其中 500ms 以上這個區間內的請求數就代表了慢請求量，正常情況下，這個區間內的請求數應該接近於 0；在出現問題時，這個區間內的請求數會大幅增加，可能平均耗時並不能反映出這一變化。除此之外，還可以從 P90、P95、P99、P999 角度來監控請求的響應時間，比如 P99 = 500ms，意思是 99% 的請求響應時間在 500ms 以內，它代表了請求的服務質量，即 SLA。
- 錯誤率。錯誤率的監控通常用一段時間內調用失敗的次數佔調用總次數的比率來衡量，比如對於接口的錯誤率一般用接口返回錯誤碼為 503 的比率來表示。
監控維度
一般來說，要從多個維度來對業務進行監控，具體來講可以包括下面幾個維度：
- 全局維度。從整體角度監控對象的的請求量、平均耗時以及錯誤率，全局維度的監控一般是為了讓你對監控對象的調用情況有個整體瞭解。
- 分機房維度。一般為了業務的高可用性，服務通常部署在不止一個機房，因為不同機房地域的不同，同一個監控對象的各種指標可能會相差很大，所以需要深入到機房內部去了解。
- 單機維度。即便是在同一個機房內部，可能由於採購年份和批次的不同，位於不同機器上的同一個監控對象的各種指標也會有很大差異。一般來說，新採購的機器通常由於成本更低，配置也更高，在同等請求量的情況下，可能表現出較大的性能差異，因此也需要從單機維度去監控同一個對象。
- 時間維度。同一個監控對象，在每天的同一時刻各種指標通常也不會一樣，這種差異要麼是由業務變更導致，要麼是運營活動導致。為了瞭解監控對象各種指標的變化，通常需要與一天前、一週前、一個月前，甚至三個月前做比較。
- 核心維度。根據我的經驗，業務上一般會依據重要性程度對監控對象進行分級，最簡單的是分成核心業務和非核心業務。核心業務和非核心業務在部署上必須隔離，分開監控，這樣才能對核心業務做重點保障。
講到這裡先小結一下，對於一個微服務來說，你必須明確要監控哪些對象、哪些指標，並且還要從不同的維度進行監控，才能掌握微服務的調用情況。明確了這幾個關鍵的問題後，那麼該如何搭建一個監控系統，來完成上面這些監控功能呢？
監控系統原理
顯然，我們要對服務調用進行監控，首先要能收集到每一次調用的詳細信息，包括調用的響應時間、調用是否成功、調用的發起者和接收者分別是誰，這個過程叫作數據採集。採集到數據之後，要把數據通過一定的方式傳輸給數據處理中心進行處理，這個過程叫作數據傳輸。數據傳輸過來後，數據處理中心再按照服務的維度進行聚合，計算出不同服務的請求量、響應時間以及錯誤率等信息並存儲起來，這個過程叫作數據處理。最後再通過接口或者 Dashboard 的形式對外展示服務的調用情況，這個過程叫作數據展示。
可見，監控系統主要包括四個環節：數據採集、數據傳輸、數據處理和數據展示，下面我來給你講解下每一個環節的實現原理。
1. 數據採集
通常有兩種數據收集方式：
- 服務主動上報，這種處理方式通過在業務代碼或者服務框架里加入數據收集代碼邏輯，在每一次服務調用完成後，主動上報服務的調用信息。
- 代理收集，這種處理方式通過服務調用後把調用的詳細信息記錄到本地日誌文件中，然後再通過代理去解析本地日誌文件，然後再上報服務的調用信息。
無論哪種數據採集方式，首先要考慮的問題就是採樣率，也就是採集數據的頻率。採樣率決定了監控的實時性與精確度，一般來說，採樣率越高，監控的實時性就越高，精確度也越高。但採樣對系統本身的性能也會有一定的影響，尤其是採集後的數據需要寫到本地磁盤的時候，過高的採樣率會導致系統寫入磁盤的 I/O 過高，進而會影響到正常的服務調用。所以設置合理的採用率是數據採集的關鍵，最好是可以動態控制採樣率，在系統比較空閒的時候加大采樣率，追求監控的實時性與精確度；在系統負載比較高的時候減小採樣率，追求監控的可用性與系統的穩定性。
2. 數據傳輸
數據傳輸最常用的方式有兩種：
- UDP 傳輸，這種處理方式是數據處理單元提供服務器的請求地址，數據採集後通過 UDP 協議與服務器建立連接，然後把數據發送過去。
- Kafka 傳輸，這種處理方式是數據採集後發送到指定的 Topic，然後數據處理單元再訂閱對應的 Topic，就可以從 Kafka 消息隊列中讀取到對應的數據。
無論採用哪種傳輸方式，數據格式都十分重要，尤其是對帶寬敏感以及解析性能要求比較高的場景，一般數據傳輸時採用的數據格式有兩種：
- 二進制協議，最常用的就是 PB 對象，它的優點是高壓縮比和高性能，可以減少傳輸帶寬並且序列化和反序列化效率特別高。
- 文本協議，最常用的就是 JSON 字符串，它的優點是可讀性好，但相比於 PB 對象，傳輸佔用帶寬高，並且解析性能也要差一些。
3. 數據處理
數據處理是對收集來的原始數據進行聚合並存儲。數據聚合通常有兩個維度：
- 接口維度聚合，這個維度是把實時收到的數據按照接口名維度實時聚合在一起，這樣就可以得到每個接口的實時請求量、平均耗時等信息。
- 機器維度聚合，這個維度是把實時收到的數據按照調用的節點維度聚合在一起，這樣就可以從單機維度去查看每個接口的實時請求量、平均耗時等信息。
聚合後的數據需要持久化到數據庫中存儲，所選用的數據庫一般分為兩種：
- 索引數據庫，比如 Elasticsearch，以倒排索引的數據結構存儲，需要查詢的時候，根據索引來查詢。
- 時序數據庫，比如 OpenTSDB，以時序序列數據的方式存儲，查詢的時候按照時序如 1min、5min 等維度來查詢。
4. 數據展示
數據展示是把處理後的數據以 Dashboard 的方式展示給用戶。數據展示有多種方式，比如曲線圖、餅狀圖、格子圖展示等。
- 曲線圖。一般是用來監控變化趨勢的，比如下面的曲線圖展示了監控對象隨著時間推移的變化趨勢，可以看出來這段時間內變化比較小，曲線也比較平穩。
- 餅狀圖。一般是用來監控佔比分佈的，比如下面這張餅圖展示了使用不同的手機網絡佔比情況，可見 Wi-Fi 和 4G 的佔比明顯要高於 3G 和 2G。
- 格子圖。主要做一些細粒度的監控，比如下面這張格子圖代表了不同的機器的接口調用請求量和耗時情況，展示結果一目瞭然。
總結
服務監控在微服務改造過程中的重要性不言而喻，沒有強大的監控能力，改造成微服務架構後，就無法掌控各個不同服務的情況，在遇到調用失敗時，如果不能快速發現系統的問題，對於業務來說就是一場災難。
搭建一個服務監控系統，涉及數據採集、數據傳輸、數據處理、數據展示等多個環節，每個環節都需要根據自己的業務特點選擇合適的解決方案，關於監控技術方案的選型我會在專欄後面進行詳解。
思考題
最後請你思考一下，你所在的技術團隊目前採用的監控系統，都監控了哪些業務數據？包含哪些業務指標？都有哪些維度？你覺得是否合理？
歡迎你在留言區寫下自己的思考，與我一起討論。
閱讀更多 架構師的修煉之路 的文章
