华为吴晟：分布式监控系统的设计与实现
微服務架構其實就是將單一的應用程序劃分成為一組小的服務，其中每個服務都是獨立的業務單元，同時又能夠被獨立開發、運行、測試以及部署。簡單來說，它的本質其實就是拆分和獨立，這也決定了微服務的部署應該是分布式的。微服務架構雖然解決了目前諸多的架構層面的問題，但在分布式部署的環境中，如何才能夠有效監控每一個服務，并及時發現系統中的問題又成為了新的挑戰。
\\Google公司早已就在其生產系統中實踐了分布式理念，為了解決監控問題，他們研發了Dapper分布式跟蹤系統，并對外公開了相關論文。與此同時，Twitter基于Google的論文開發了Dapper系統的開源實現Zipkin。國內類似的有過曝光的系統還有淘寶鷹眼系統EagleEye以及開源軟件Skywalking。InfoQ記者就分布式監控相關的問題采訪了Skywalking作者吳晟，請他從整體層面為讀者分享解讀分布式監控相關的技術難點。另外，吳晟也將會在9月10日舉行的CNUTCon全球運維技術大會上分享相關話題，歡迎關注。
\\InfoQ：對于分布式系統的監控，你認為難點是什么？目前有哪些可行的落地思路？
\\\吳晟：分布式監控系統從使用的角度上，無論是手動探針還是自動探針，上手難度都不大。多數的技術型軟件，從數據庫、大數據處理到流式計算，在入門時都需要經歷復雜的安裝和參數設置過程。但是對于分布式監控系統，無論是Zipkin、Skywalking這些國內外的開源監控產品，還是各種商業APM產品，安裝和入門難度都不大。
\\但對于開發一款分布式監控系統來說，情境則完全不同，無論是探針還是后臺處理都有很多的挑戰。比如：
\\- \\t
Java自動探針的實現，對于Java字節碼、程序運行情況、GC、程序優化都要有相當細致的要求。
\\t\\t - \\t
后端分析服務，如果不了解探針，給出的分析方案難度大，效率低，機器需求量大。
\\t\\t - \\t
探針網絡傳輸的需求，序列化效率。
\\t\
在APM領域，程序的細節決定產品的性能。目前按照探針的實現，可行的思路主要有四種：
\\基于日志系統，探針只負責對日志加上編號，又類似ELK的系統進行收集、處理、展示。這方面沒有很成熟的產品，一般都屬于公司內部封裝的框架。
\\t\\t自動探針，適用語言：Java、C#、PHP、Node.js等等存在VM的語言。絕對大多數的商業產品和熱門的開源產品都屬于這個系列。
\\t\\t全手動探針，優勢是適用范圍廣，最有名的就是Zipkin的整個生態系統，分布式追蹤幾乎無處不在。也是現在全球運用最廣泛的分布式監控系統。
\\t\\t同時支持自動和手動模式的探針，適用語言同樣是Java、C#、PHP、Node.js等等存在VM的語言，由于技術復雜性提高，運用的較少。優點是入門方便，同時使用靈活。商業上主要是Instana，開源主要是sky-walking提供了技術解決方案。
\\t\InfoQ：分布式監控領域常用的理論都有哪些？
\\\吳晟：所有的分布式理論幾乎都來自2010年的Google論文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》，這里面詳盡的描述了分布式系統的解決思路。
\\Dapper作為分布式監控的核心，主要給大家介紹了Trace、Span、spanId、log、采樣等幾個重要概念。其中Trace就是一個可能跨越多個節點的分布式。Span是調用過程中一個時間區間（時間跨度），這也是這個英文名字的由來。一般對應一個方法或者代碼塊的執行。SpanId按照書的索引方式（例如1, 1.0, 1.1, 1.1.1）來表達層級關系，讓更多的讀者很好的理解了調用鏈追蹤。不過這里要強調的是，絕大多數的追蹤系統，包括開源和商業，在工程實踐上，因為消耗問題都放棄了這種方法。
\\log是Span跨度內發生的事件，比如異常。在實際的產品中，會使用Tag、Annotation、Log、Event等多種概念來提升效率。采樣是Dapper是大篇幅強調的問題，也就是說，超高并發系統中采樣是必然，如何采樣也是各產品策略不同，比如按照Span采樣，按照Trace采樣。
\\但是幾乎所有的現在開源和商業分布式監控系統，都在論文的基礎上做了大量改進，模型并不相同。目前階段，CNCF基金會的OpenTracing標準，是一個很好的理論參考。
\\還有就是Zipkin的龐大生態和大量公司的參與。我和Zipkin的負責人，Pivotal資深工程師Adrian Cole有過很多的溝通，在跨語言，跨平臺的監控上，Zipkin有著強大的用戶基礎和案例。
\\\InfoQ：從你的角度來看，分布式監控系統應該包含哪些模塊？
\\\吳晟：監控系統一般分為三大模塊：
\\探針或SDK，負責數據采集和發送。探針或SDK是應用程序的收集端。一般使用插件的模式，自動探針一般是不需要修改程序，而SDK則是需要修改部分配置或者代碼。skywalking就是自動探針為主，zipkin-brave就是Zipkin的Java手動探針。
\\Collector模塊，負責數據收集、分析、匯總、告警和存儲。Collector模塊，這個根據不同的APM實現，可能由一個或者多個子系統構成。Collector負責對探針和SDK提供網絡接口（TCP、UDP、HTTP不同形式接口）。
\\功能上，主要包含數據收集、分析、匯總、告警和存儲。這些模塊在復雜的開源APM和商業產品上都保持一致。大家選擇時，值得注意的是，現在包括Zipkin在內的不少國外的追蹤系統，是只負責追蹤，不負責分析匯總，他們認為分析可以由使用者自己負責。
\\作為分析方式，分為流式分析和異步批量兩種，而流式分析會對數據統計和告警的實時性更有幫助。
\\UI，負責高實時性的展現。包括但不限于Trace的查詢，統計數據展現，拓撲圖展現，VM或進程相關信息等，監控關鍵數據的展現。
\\\InfoQ：對于訪問量較大的應用，如何解決埋點監控的性能問題？
\\\吳晟：這是我在本次分享里面很多內容的根本，性能問題。這個其實沒有標準答案，根據系統的不同，流量不同，容忍度不同，標準會完全不同。我們舉個簡單的例子，在Google，千分之一，萬分之一的采樣，依然是大數據分析，依然足以定位問題；在多數非BAT核心產品上，50%或者100%采樣都不會有性能問題。一定要選擇適合自己的，不要過分擔憂。
\\一般說來，一款合格的產品，在單點500TPS之下的應用，采樣率都可以保持的很高。
\\\InfoQ：現在你們的監控系統有沒有結合大數據分析，智能的進行故障預警以及處理？
\\\吳晟：目前sky-walking沒有去做這方面的工作，因為這樣會大大增加部署和運維的難度。有需求，有運維的能力的公司，很容易在產品的基礎上進行相關的分析。
\\在商業產品中，指標方差數，趨勢分析，偏移量，熱度分析，用戶促銷活動等等都是在處理范圍中。
\\\InfoQ：你的演講里有一個有趣的觀點，面向研發的監控和面向運維的監控，如何理解這句話？
\\\吳晟：雖然現在DevOps很熱，但是無論一體化進行到哪個階段，線上問題和開發迭代，永遠都有時間差。所以“線上問題的發現、規避和應急響應”和“研發過程對于產品的改進和修復”是兩個有聯系又實際并不相同的理念。
\\目前的DevOps，強調快速的迭代和響應，微更新，快速發布。相關的容器化技術也是倍受追捧。而這些對于分布式監控的要求也是越來越高。主要原因是分布式的節點，從幾十個上升到幾百個上千個都是很常見的。
\\但是，DevOps的發展，并不會完全消除“線上問題響應”和”線下修復問題“中間的時間差。
\\比如在生產環境中，某個數據庫因為冷門業務的某條大SQL語句緩慢，拖慢服務器IO性能，造成應用其他主要接口響應受到影響。
\\對于運維人員，監控系統的職責是需要發現這條慢SQL，識別數據對應的session信息，輔助運維人員殺掉這條SQL的執行。
\\t\\t對于開發人員，則需要反饋調用鏈路，找到發生這條SQL調用的原因，是特定參數引起的，還是特定的條件分支，或者是特定的用戶。并通過本周期迭代，避免或降低再次發生這個問題的風險。
\\t\這個案例中，你會看到，其實，APM系統需要提供的信息是不太相同的。這就是所謂的“面向研發的監控”和“面向運維的監控”之間的差別。而很多人都忽略了這個差別，而這對于APM系統的運用和演進都是很重要的。
\總結
以上是生活随笔為你收集整理的华为吴晟：分布式监控系统的设计与实现的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： git经常使用命令和问题
- 下一篇： python基础===八大排序算法的 P