點擊上方“開源社”關(guān)注我們

| 作者：吳晟

|?編輯：陳梅梅

| 設(shè)計：譚嘉露

吳晟

Apache 基金會會員，ApacheSkyWalking 創(chuàng)始人、項目 VP 和 PMC 成員，Apache 孵化器 PMC 成員，ApacheShardingSphere PMC成員，Apache APISIX (incubating) PPMC 成員，Apache ECharts (incubating) 和ApacheDolphinScheduler (incubating) 孵化器導(dǎo)師，Zipkin 成員和貢獻(xiàn)者，CNCF OpenTracing 核心維護(hù)者。

導(dǎo)讀：本文摘自于 SkyWalking 創(chuàng)始人吳晟撰寫的《 Apache SkyWalking 實戰(zhàn)》一書，概要介紹了 SkyWalking 的新特性。

?

SkyWalking 7是項目在2020年發(fā)布的最新版本，該版本對之前的v6版本保持著高度的兼容性、相同的內(nèi)核及設(shè)計模式，因此讀者不用擔(dān)心之前學(xué)習(xí)的內(nèi)容發(fā)生大的變化。當(dāng)然，作為一個全新的版本，SkyWalking 7也有很多獨特的地方。

SkyWalking 7新特性

SkyWalking 7保持著高速的持續(xù)迭代，我們無法羅列所有的升級，因為截至撰寫本書時，已經(jīng)有超過百項的修改。下面重點介紹一些對用戶有深刻影響的新特性。

Java探針不再支持JDK 1.6和1.7

由于大部分商業(yè)和開源 JDK 以及 Java 類庫已經(jīng)放棄了對 JDK1.8 以下版本的支持，SkyWalking 社區(qū)在 2019 年年底做完問卷調(diào)查后得出結(jié)論，放棄支持，以保證SkyWalking 依賴庫的安全和穩(wěn)定。

對于極少部分的JDK 1.6、1.7用戶，可以使用 SkyWalking6.x 的探針，SkyWalking 7 依然支持它們上報的數(shù)據(jù)。

?

支持新的生產(chǎn)級存儲實現(xiàn)

SkyWalking v6 中，我們一直支持 H2、MySQL、TiDB、Elasticsearch 作為存儲實現(xiàn)。其中，H2 主要用于演示和實驗，MySQL 適用于小型使用場景，TiDB 由于本身技術(shù)較新，使用范圍和使用案例的回饋還十分有限。Elasticsearch 6.x 和 7.x 則是當(dāng)之無愧的超大規(guī)模存儲部署的首選。SkyWalking 的大型用戶使用 Elasticsearch 作為存儲，每天收集百億以上的監(jiān)控信息。

同時，SkyWalking 社區(qū)也在不斷尋找其他的可能性。v7 中，我們新加入了兩個選項。

使用了同在 Apache 社區(qū)的 ShardingSphere。它對 MySQL 的水平擴(kuò)展能力的補(bǔ)充，能夠很好地滿足中型用戶的使用場景。同時，由于 ShardingSphere Proxy 對應(yīng)用透明的特性，我們不需要修改 SkyWalking 的代碼，通過原生提供的路由規(guī)則即可以完成集成。

InfluxDB + MySQL 混合存儲方案。InfluxDB 是一款廣泛使用的時序數(shù)據(jù)庫。對于監(jiān)控數(shù)據(jù)而言，90% 以上的數(shù)據(jù)具有高度的時序特性。同時，我們依然保持使用MySQL/H2 作為元數(shù)據(jù)的存儲，這部分無法存在于時序數(shù)據(jù)庫中。對于中型用戶與購買了 InfluxDB 企業(yè)版本的大型用戶，這會在使用成本上比 Elasticsearch 更低。同時，這種實現(xiàn)也給了喜歡 OpenTSDB 存儲的用戶參考切換新的實現(xiàn)的

機(jī)會。

HTTP請求參數(shù)采集

參數(shù)采集，這是一個被問及最多也是爭議最大的功能。SkyWalking 團(tuán)隊了解參數(shù)值對于性能診斷的重要性，但同時，參與參數(shù)造成的巨大性能消耗，對系統(tǒng)可能產(chǎn)生毀滅性的打擊。在 v7 中，我們提供了兩個需要用戶手動打開的參數(shù)：

plugin.tomcat.collect_http_params

plugin.springmvc.collect_http_params

這兩個參數(shù)結(jié)合 plugin.http.http_params_length_threshold 控制參數(shù)值長度，可以對請求的參數(shù)進(jìn)行收集。當(dāng)然，此時，被監(jiān)控系統(tǒng)和 SkyWalking 都需要承受不小的負(fù)擔(dān)。

?

HTTP收集協(xié)議和Nginx監(jiān)控

Java、PHP、Go、.NET Core、Node.js 一直是最為主要的 SkyWalking 探針支持范圍，在 7.0.0 中，我們恢復(fù)了在整個 v6 中都不再提供的 HTTP/1.1 網(wǎng)絡(luò)協(xié)議。Nginx + Lua 的探針（https://github.com/apache/skywalking-nginx-lua）在Apache APISIX 項目的幫助下，也成功和大家見面了。Nginx 作為國內(nèi)最常用的負(fù)載均衡和網(wǎng)關(guān)中間件，對其監(jiān)控的支持很好地彌補(bǔ)了之前的一個功能缺失，也使得調(diào)用鏈追蹤和拓?fù)涓鼮橥暾蜏?zhǔn)確。

Elasticsearch存儲的進(jìn)一步優(yōu)化

Elasticsearch 作為目前運(yùn)用最為廣泛的存儲實現(xiàn)，在 6.0~6.3 期間，已經(jīng)經(jīng)歷了多次重構(gòu)和優(yōu)化，目前很好地工作在大量的生產(chǎn)環(huán)境中。在 v7 中，我們決心加入更多的監(jiān)控指標(biāo)，包括拓?fù)涞募?xì)節(jié)，甚至其他的監(jiān)控端，此時 Elasticsearch 索引數(shù)量成為新的挑戰(zhàn)。從 7.0.0 開始，我們將更多的索引進(jìn)行了合并，分鐘、小時、天指標(biāo)精度的索引合并成為一個索引，整體的索引數(shù)量下降了50%。同時，因為小時、天指標(biāo)精度只有分鐘精度的1/60和1/1440，索引合并后索引的性能和原始的分鐘索引性能幾乎沒有差異。

這個特性讓我們更為放心地擴(kuò)展更多的監(jiān)控指標(biāo)。同時，在這里小小地劇透一下，SkyWalking 一直在探究瀏覽器監(jiān)控的可能性和落地方案。這個升級也是為前景更廣闊的瀏覽器監(jiān)控做好準(zhǔn)備。

SkyWalking 7新特性

SkyWalking 7 新功能上的核心特性當(dāng)屬性能剖析。它真正做到了在生產(chǎn)環(huán)境對單個方法的執(zhí)行性能進(jìn)行評估和診斷。而且，它結(jié)合 SkyWalking APM 的 Metrics 和分布式追蹤能力，能夠在高壓力、高敏感度的生產(chǎn)環(huán)境安全進(jìn)行性能剖析。

?

性能剖析基本原理

性能剖析建立在大部分程序運(yùn)行模型是基于線程這種通用概念，而且絕大部分業(yè)務(wù)邏輯是運(yùn)行在單線程中的。

代碼級性能剖析就是利用方法棧快照，并對方法執(zhí)行情況進(jìn)行分析和匯總，對代碼執(zhí)行速度進(jìn)行估算。

性能剖析激活時，會對指定線程周期性進(jìn)行線程棧快照，并將所有的快照進(jìn)行匯總分析，如果兩個連續(xù)的快照含有同樣的方法棧，則說明此棧中的方法大概率在這個時間間隔內(nèi)都處于執(zhí)行狀態(tài)。從而，通過這種連續(xù)快照的時間間隔累加成為估算的方法執(zhí)行時間。時間估算方法如圖示。

時間估算方法

在上圖中，d0~d9 代表? 10 次連續(xù)的內(nèi)存棧快照，實際方法執(zhí)行時間在d3~d4 之間，結(jié)束時間在 d8~d9 之間。性能剖析無法告訴你方法的準(zhǔn)確執(zhí)行時間，但是它會估算出方法執(zhí)行時間為 d4~d8 的 4 個快照采集間隔時間之和，這已經(jīng)是非常精確的時間估算了。

性能剖析的功能特點

性能剖析可以很好地對線程的堆棧信息進(jìn)行監(jiān)控，主要有以下優(yōu)勢：

• 精確的問題定位，直接到代碼方法和代碼行；

• 無須反復(fù)增刪埋點，大大減少人力開發(fā)成本；

• 不用承擔(dān)過多埋點對目標(biāo)系統(tǒng)和監(jiān)控系統(tǒng)的壓力和性能風(fēng)險；

• 按需使用，平時對系統(tǒng)無消耗，使用時消耗穩(wěn)定。

這些優(yōu)點是傳統(tǒng)的監(jiān)控方法無法具備的強(qiáng)大優(yōu)勢。我們曾經(jīng)在InfoQ中文站發(fā)表的文章中也提到過這一點，文章名為“在線代碼級性能剖析，補(bǔ)全分布式追蹤的最后一塊‘短板’”。

使用場景

大家看到上一小節(jié)的說明，應(yīng)該很容易理解性能剖析原理，那么，回到讀者最常問的問題，它的性能消耗怎么樣。因為很多人了解到，線程快照是會消耗大量性能的。但事實上，這取決你在多大范圍內(nèi)進(jìn)行線程快照。

SkyWalking 作為一個強(qiáng)大的 APM 系統(tǒng)，無論是功能還是性能上，都是完全為生產(chǎn)環(huán)境的高質(zhì)量監(jiān)控做準(zhǔn)備的。在 7.0.0 之前版本中，通過拓?fù)鋱D、指標(biāo)和分布式追蹤，能夠很好地對性能問題做好定界處理。這個定界表現(xiàn)為，可以探針到慢請求的服務(wù)、服務(wù)實例、Endpoint，以及具體的代碼范圍。性能剖析作為一個交互式功能，是在前置的定界操作完成后，針對特性服務(wù)的特定 Endpoint 發(fā)起的性能剖析。而且在剖析過程中，并行度受到嚴(yán)格限制（默認(rèn)最大不會超過 10 ），同時線程快照的時間間隔不能低于 10ms。對于針對慢方法的特定功能，10ms 的最小探查精度已經(jīng)完全夠用了。而且，性能剖析也是不允許在同一時間范圍內(nèi)存在多個剖析指令的，這也保證了對單個服務(wù)的壓力可控。

總之，我們設(shè)置了大量的限制，希望讀者在使用前做好參數(shù)設(shè)置，確保精確和有效的性能剖析。

另外，從 7.1.0 開始，性能剖析會自動激活 14.1.3 節(jié)中介紹的參數(shù)采集功能，后續(xù)可能會激活更多的高級特性，幫助用戶結(jié)合 Trace 和剖析結(jié)果，確定代碼短板。

SkyWalking 8 Roadmap

SkyWalking 8 將只會保持探針和后端協(xié)議的邏輯一致性，在 SkyWalking 3.2 發(fā)布之后的 2 年，結(jié)束對老版本協(xié)議的支持。8.0 首次重新規(guī)范協(xié)議，同時，徹底移除注冊、ID 交換等元數(shù)據(jù)信息，使系統(tǒng)運(yùn)維和升級的便利性得到提高。

?

關(guān)于 SkyWalking 的實戰(zhàn)內(nèi)容推薦閱讀《 Apache SkyWalking 實戰(zhàn)》一書，本文經(jīng)出版社授權(quán)發(fā)布。

推薦語：《Apache SkyWalking實戰(zhàn)》從功能使用、項目設(shè)計、核心模塊、工作原理、擴(kuò)展實踐5個維度全面講解 SkyWalking，由 SkyWalking 的創(chuàng)始人吳晟與核心開發(fā)團(tuán)隊撰寫，得到了來自華為、百度、螞蟻金服、京東數(shù)科、Tetrate.io 的5位資深技術(shù)專家的聯(lián)袂推薦。

文末福利

我們將在本期的讀者中，以抽獎的形式送出 5 本原版書籍！

?

2020-8-7（周五）中午 12 點準(zhǔn)時開獎，趕快點擊下方小程序進(jìn)行抽獎，一起學(xué)習(xí) SkyWalking 吧！

開源社線上直播 “源”來如此 報名方式

掃描下方二維碼通過活動行報名填寫信息，添加小編微信號：chatbot-yuan，回復(fù)OS，進(jìn)入“源”來如此粉絲群。相信你可以在這里和志同道合的伙伴們愉快交流！
?
8月9日14：00-16：00，我們不見不散！

開源社簡介

開源社是由國內(nèi)外支持開源的企業(yè)，社區(qū)及個人，依“貢獻(xiàn)，共識，共治”原則，所組織的廠商中立、純志愿者、非營利的開源聯(lián)盟，旨在共創(chuàng)健康可持續(xù)發(fā)展的開源生態(tài)體系，并推動中國開源社區(qū)成為全球開源軟件的積極參與及貢獻(xiàn)者。我們專注于開源治理、國際接軌、社區(qū)發(fā)展和開源項目。

相關(guān)閱讀?|?Related Reading

GitHub 標(biāo)星 10,000+，Apache 頂級項目 ShardingSphere 的開源之路

“源”來如此第一期 帶你走進(jìn)開放式協(xié)作

標(biāo)準(zhǔn)共建 開源共贏

開源社執(zhí)行長王偉老師榮獲“2020中國開源杰出貢獻(xiàn)人物獎”

總結(jié)

以上是生活随笔為你收集整理的重磅推荐 ｜ SkyWalking未来初探（文末有福利哦）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。