本文是WOT2016互聯網運維與開發者大會的現場干貨，新一屆主題為WOT2016企業安全技術峰會將在2016年6月24日-25日于北京珠三角JW萬豪酒店隆重召開！

2016年4月14-15日，在北京珠三角JW萬豪酒店，51CTO舉辦了WOT互聯網運維與開發者峰會。WOT秉承專注技術，服務技術人群的理念，自 2012年首次舉辦以來，歷經八屆，積累了大量的技術資源，成為廣大技術從業者和技術愛好者一致認可的技術分享大會、交流和人脈拓展平臺。會后，記者專訪了本次大會監控與性能優化專場的沈劍講師，他分享的內容是創業公司快速搭建立體化監控平臺之路。

沈劍 58到家技術委員會主席、技術總監

嘉賓介紹

沈劍，58到家技術委員會主席、技術總監。曾任百度高級工程師，58高級架構師，C2C技術部負責人，58技術學院優秀講師。目前，他主要負責58到家后端的技術管理工作，比如說架構部、后端平臺部、基礎服務部、DBA，還有測試平臺等相關偏后臺的技術工作。

在本次WOT峰會上，沈劍老師分享了《創業公司快速搭建立體化監控平臺之路》。沈老師是2015年9月份加盟58到家，當時整個到家的技術監控體系還沒有搭建起來，他結合這幾個月在到家做的一個監控系統來分享創業性公司如何快速搭建監控平臺這一技術主題，比如58到家是如何小成本快速建立起服務器監控、進程監控、端口監控、接口監控、錯誤日志監控、業務系統監控等立體化監控體系，有怎樣的經驗及實踐。

采訪實錄如下：

記者：您的從業經歷非常豐富，高級工程師、架構師、技術講師，您更偏向于哪個角色?您是如何輕松實現各個角色間的切換?

沈劍：我更傾向于架構師的角色，因為架構師需要幫助應用線解決應用中的實際問題，能夠給公司帶來非常大的收益，而且在解決問題的過程中，我個人也有成長和提高，非常有成就感。技術講師，也是我們技術委員會的一個工作職責，這個角色是因為我個人比較喜歡總結并將學到的一些技術點跟大家分享。

記者：技術委員會的職責定位是什么，相當于公司內部培養新員工“大學”?

沈劍：技術委員會日常負責招聘、技術培訓、職級發展等工作，具體包括社會招聘，人才培養，校招生的培訓，各個職級人員的培訓、職位晉升。其中很多工作是人力部門同事來主導，但是一些技術方面的工作，比如說技術的評審需要高階的技術人員來評判，包括校園招聘，一些技術試卷的產出和一些技術面試等。技術委員會還有一項核心的工作職責，就是對公司技術發展方向的把關和重點項目、重點系統的技術方案把關，對公司的技術戰略發展提出建議。

記者：您經歷的幾個產品線，它們的架構設計亮點有哪些，有哪些成功經驗可以分享?

沈劍：我就分享幾個我曾經負責過的系統的一些特點，比如我之前負責過即時通信系統，即時通信系統和站點系統、電商系統不一樣的地方是它是基于通知的系統，站點系統、電商系統都是用戶往站點去發一個請求，實現響應一個頁面。但是即時通訊系統，比如QQ，你即使沒有向QQ服務發送任何請求，但是你的客戶端會收到請求，它是基于通知的系統，要有獨立通知的通道，這就需要有一個TCP長連接。所以，即時通訊系統的在線量、并發量，包括響應處理時間上面臨很多技術挑戰。

我再舉一個例子是推薦系統，原來在58同城負責推薦系統的架構設計，推薦系統和其他系統不一樣的地方在于它是一個在線和離線相結合的系統。離線狀態下，系統可以計算出一些推薦結果，當用戶實時訪問的時候將會獲取該推薦的結果，同時要支持分流的系統。普通的系統，任何用戶去訪問一個頁面，可能獲得的結果是相同的。但是對于推薦系統，每個用戶訪問同一個頁面，系統根據該用戶的歷史行為、興趣返回的頁面，推薦出來的結果是不一樣的。這就要求架構師在做架構設計的時候，要支持一個流量過來的時候，能夠分配到不同的子系統，實現不同的頁面推薦策略，獲取不同的推薦結果。

還有，針對因某些熱門活動引發的短期瞬間流量過大，架構師在架構設計中要提前考慮到，對互聯網的高并發在可用性、擴展性上做有針對性的設計。為了應對高并發，系統要有很強的擴展性，比如可以通過增加機器，就可以增加系統的性能，擴展性很好時，流量增加的時候，系統只要簡單增加機器就可以。如何做好設計上的預留呢?常見的架構設計分為三層，站點層、服務層和數據層。站點層和服務層的設計準則，就是說服務無狀態，系統不能保存任何數據，只要不保存任何數據，沒有狀態，通過加機器就可以簡單實現擴充性能。數據層有狀態，系統要做好水平切分，不能將所有的數據都保存在一臺機器上，要水平分布在不同機器上，這樣也可以通過增加機器擴充系統容量。這是比較專業的架構設計注意點。

記者：最后一個問題，58到家技術發展中，您遇到的最大問題是什么?您和您的團隊是如何通過架構設計解決的?

沈劍：58到家是一個初創的公司，到現在發展不到兩年的時間，創業的公司初期基本是業務跑得非常快，為了應對業務的快速發展，技術支持上也是怎么快怎么來，可能用了一些開源的方法。每個團隊使用不同的方法，幫助業務快速的迭代和發展，但是各團隊各做一套，在整體的框架之內，有些事情可能就做重復了。比如說監控系統，A業務線實現了一個小的監控系統，B業務線也實現了一個小的監控系統，快速滿足初期監控需求，但是在公司層面、更高層面，這個小監控系統就做重復了。我現在負責后端的一些部門，希望從底層架構設計上進行框架統一，在框架層面上就把這個監控系統實現了，涉及到這個監控系統的部門都可以使用這一統一的監控框架，不需要每個業務部門單獨去開發小監控系統了。以后，這些公用的工具平臺和框架，可以幫助各個業務線去解決他們通用的痛點問題。

【編輯推薦】