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