業務是滿足公司資本發展向前走的生力軍，它的腳步永遠都不應該停下來。與直接參與架構的設計和研發人員相比，技術保障人員是一群默默無聞的幕后英雄。***的架構是不存在的，這就需要技術保障人員不斷查找并解決問題、規避架構風險、完善業務以及開發所需要的基礎設施，為業務架構的穩定運行提供強大的支撐，為業務線的架構設計和開發人員做好后勤保障。

現在，各類技術大會層出不窮，技術人員有了更多學習前沿技術和設計思想的渠道。但是學習到的這些思路，是否真的適合公司的業務?要解決業務架構的更種缺點，是否一定要推翻重做?作為技術保障人員，怎樣在不重建體系的前提下，降低系統的故障率，讓它運行得更好?

[[164983]]

王春生 秒拍網架構師/前新浪系統架構師、研發技術保障部總監

在由51CTO高招主辦的“CTO訓練營”活動現場，前手機微博技術保障體系負責人、現秒拍網架構師就上述問題與現場同學進行了分享和探討。這位有十余年系統設計和技術架構經驗的老兵認為，大多數情況下，我們目前線上運行的架構，就是最適合公司業務線狀的架構。面對現實存在的一些問題，我們完全沒必要推翻現有的體系，而是找到一些方式和方案，能夠實時的發現或者監控線上存在的問題;同時通過相應的技術指標，預判并規避可能出現的風險。

手機微博架構淺析

2014年，手機微博的業務翻倍增長，這促使手機微博的架構進行了一次重大改造。主要方式是將PHP的Scribe，包括自己定義的PHP模板引擎換成鳥哥寫的Yaff；將很多PHP自身運算變成了PHP模塊，等等。

王春生首先對手機微博架構進行了簡單分析。Microservice包括開放平臺的核心池和非核心池兩部分，來將不同的業務進行隔離。用戶可以通過手機客戶端直接訪問CDN獲取圖片，以及直接訪問“圖床”Service 來上傳圖片；MAPI會請求Microsevice。

王春生坦言，整個架構無論是從平臺體系還是從業務體系來講，與許多互聯網應用的架構非常相似，無非就是接入層、業務層、數據層，當然可能有多個接入層、多個數據層和多個業務層。那么一個這樣簡單的結構，它的問題到底可能出現在哪兒呢?

上圖是王春生整理出來的手機微博遇到最多的問題，并將這些問題從業務及體驗、架構及技術保障這三個層面進行了梳理。

分析來看，這些架構所遇到的問題基本都差不多。主要所括容量上和容錯上的一些問題；一些架構上的不合理；監控、報警不夠及時，響應的速度和解決問題的速度不夠快；技術債務和技術風險等。

要想把這些技術技術債務、技術風險，包括一些對架構產生影響的外部因素挖掘出來，首先要解決的問題就是監控。因為無法對問題進行度量，管理和優化也就無從談起。

監控體系實戰

• 技術選型：Zabbix

手機微博監控選擇的是Zabbix。王春生談到，其實任何一款現在主流的開源監控產品，如Nagios、Zabbix、Ganglia、Bosun等等，幾乎都可以滿足對監控的需求。大家沒有必要在監控系統的選型上費太多力氣，而真正花費時間和精力的是在監控項的設計上，因為監控項的設計是監控工作中最重要的環節。

說到這里，王春生指出了許多公司運維工程師陷入的一個誤區——盡管同時采用了多套不同的監控系統，甚至自己寫了一部分shell腳本，但線上一些常見問題并沒有得到及時的報警。于是不斷有新的監控項堆積出來，然而，往往還是很難定位到問題的具體細節。

• 監控項設計：最小粒度原則

因此，手機微博設計監控項首先考慮的是采用最小粒度原則，任何一個涉及到單機的監控項都會定位到單機上。在成千上萬臺機器中，只要有一臺機器出現問題，可以迅速定位出現問題的那臺機器。這臺機器在哪一個IDC，影響到的是什么樣的用戶人群，同樣也能夠快速知道。

但監控做的細經常遇到的一個問題就是收到到的報警太多。某一個區域，或者說某一個功能特征的系統出現問題時，經常一下子收到幾十條、幾百條的報警短信。因此在匯總時會考慮一些收斂功能的設計。

另外在設計監控項時，還要考慮到它覆蓋的廣度和深度，因此手機微博的監控系統做了一個簡單的分層：操作系統層、Server層(服務軟件層)、業務層。

所有操作系統的日志、業務的日志全部都到Rsyslog里面去，會通過Rsyslog做轉發，比如轉發到HDFS、Elasticsearch里面去,這基本是目前互聯網公司通用的做法。值得一提的是，手機微博的監控整體上都是用的Rsyslog，基于日志進行實時計算。

• ELK/ERK:定位復雜問題

監控系統雖然能幫助我們快速發現問題，但只有監控的話，還是沒有辦法更深入的挖掘到底出在哪兒。通過監控，我們只能得到的是一些計算出來的數值，所以它得到的結果是很概要的。當故障發生時，尤其是在一個復雜行為里，我們很難快速定位問題真正發生的位置。另外，監控項之間的關聯關系也是需要提前挖掘的。比如要將Feed接口所依賴的十幾個微服務的接口的定義出來，就需要花費很多的時間和精力。而且一旦業務發生變化，監控體系也要隨之調整，這是比較麻煩的。

因此，微博采用了ELK和ERK體系，并進行了一些優化，比如用Rsyslog替換Logstash。記錄下來的大量日志需要進行一定的格式化分析，讓開發工程師和架構師更好的對系統進行優化。通過ELK體系，可以做出這樣的餅圖出來，直觀定位監控系統報警的那些問題，查找出來到底是哪一行代碼性能最差，影響了全局。

整體來看，手機微博技術保障體系的監控系統的功能，主要是快速發現并盡可能快地定位問題。通過ELK和ERK套件，更加精準的定位問題，以及發現一些更為復雜的問題。ELK和ERK套件的優勢就是日志是實時的，現場感很強，并且它支持的日是志類型非常豐富。幾乎在問題發生同時，我們就可以知道線上系統是哪一個環節都現問題，出現了什么問題。另外，它還提供了很多關聯分析。

但它的劣勢就是日志的存儲是需要一定成本的，另外效率并不高，歷史的回溯能力也不強。

保障業務前進的后勤部隊

當然，技術保障體系不止于監控。總的來說，技術保障就是要給業務架構師和開發工程師這些在前面沖鋒的戰士，提供相應的支持和更好的素材，來保證整體業務快速向前。我們的業務要往前沖，除了開發工程師，除了架構師，設計方案、寫代碼之后的所有事情，都需要有一個專門的技術保障團隊為大家提供服務和支撐。技術保障一方面對業務線提供支持，幫助架構設計和代碼實現快速部署，使產品盡快面世。另外還可以通過一些基礎的監控數據分析，和一些基礎設施的開發，償還一些技術債務。

講師簡介

王春生 秒拍架構師

秒拍網架構師，先后擔任過新浪系統架構師、研發技術保障部總監，10余年系統設計、技術架構經驗，尤其擅長高性能、高并發、大數據業務架構設計。具備豐富的技術團隊管理經驗。多個基于Rsyslog的技術作品，被Rsyslog官方引進使用。個人譯著《Puppet 3實戰手冊》，《NoSQL權威指南》。

了解更多訓練營內容請登錄 http://x.51cto.com/act/