K8S | Service服務(wù)發(fā)現(xiàn)
一、背景在微服務(wù)架構(gòu)中，這里以開(kāi)發(fā)環(huán)境「Dev」為基礎(chǔ)來(lái)描述，在K8S集群中通常會(huì)開(kāi)放：路由網(wǎng)關(guān)、注冊(cè)中心、配置中心等相關(guān)服務(wù)，可以被集群外部訪問(wèn)；圖片對(duì)于測(cè)試「Tes」環(huán)境或者
作者 | 張旭海
經(jīng)過(guò)上一篇內(nèi)容《什么是性能工程》的討論，我們引出了 _“性能工程，是指通過(guò)設(shè)計(jì)、構(gòu)建工具鏈和工作流，從而對(duì)系統(tǒng)性能進(jìn)行持續(xù)改善和守護(hù)的一類實(shí)踐方法”_ 這一觀點(diǎn)，并基于此定義了落地性能工程的目標(biāo)：
本文將圍繞著上述三個(gè)建設(shè)目標(biāo)，介紹相關(guān)的嘗試和方法，以討論企業(yè)建設(shè)性能工程體系的最佳實(shí)踐。
從總體上看，我們將與性能工程相關(guān)的各種實(shí)踐，融入在研發(fā)流程的每個(gè)環(huán)節(jié)中。如下圖所示：
接下來(lái)的內(nèi)容，我們將選取上述實(shí)踐中的具體幾個(gè)方法，分別介紹。它們包括：
上篇文章提到過(guò)，現(xiàn)有的成熟研發(fā)流程中性能往往被忽視，導(dǎo)致與性能相關(guān)的工作不斷被后置。
性能左移恰恰是嘗試將性能優(yōu)化盡量前置，向研發(fā)流程的左側(cè)移動(dòng)。這包括設(shè)計(jì)階段的性能建模，開(kāi)發(fā)階段的性能實(shí)踐以及測(cè)試階段的性能測(cè)試和仿真。
性能建模是整個(gè)流程的第一個(gè)環(huán)節(jié)。它一方面包含了在設(shè)計(jì)階段需要明確的系統(tǒng)性能指標(biāo)要求，如功能響應(yīng)時(shí)間、關(guān)鍵路徑吞吐量、服務(wù)并發(fā)量等，以及對(duì)資源利用率相關(guān)的要求和設(shè)計(jì)，如彈性擴(kuò)縮指標(biāo)，系統(tǒng)容量規(guī)劃和預(yù)估等。
另一方面則包含了架構(gòu)的性能關(guān)注點(diǎn)地圖。關(guān)鍵的業(yè)務(wù)模塊、性能阻塞概率大的組件以及各種交互接口都屬于性能關(guān)注點(diǎn)的范疇。性能關(guān)注點(diǎn)地圖能夠在性能分析和優(yōu)化時(shí)為我們提供邏輯、交互、算法和數(shù)據(jù)結(jié)構(gòu)上的設(shè)計(jì)信息，并引導(dǎo)我們聚焦在關(guān)鍵路徑和更易發(fā)生性能劣化的地方。
（圖源：_TCP Implementation in Linux: A Brief Tutorial_, Fig. 1）
上圖以 TCP 網(wǎng)絡(luò)棧架構(gòu)為例，介紹性能關(guān)注點(diǎn)地圖的概念。在網(wǎng)絡(luò)棧中，用戶態(tài)和內(nèi)核態(tài)的交互，涉及數(shù)據(jù)拷貝問(wèn)題、同步/異步 IO 問(wèn)題；中斷處理的部分要關(guān)心上下文切換開(kāi)銷、軟中斷資源等場(chǎng)景；而對(duì)于各類隊(duì)列則需要考慮生產(chǎn)消費(fèi)速率、排隊(duì)長(zhǎng)度、丟棄率等等。性能關(guān)注點(diǎn)就是這些在設(shè)計(jì)階段識(shí)別到的與性能強(qiáng)相關(guān)的業(yè)務(wù)路徑和關(guān)鍵組件。
性能建模將與其他設(shè)計(jì)產(chǎn)出物一同進(jìn)入架構(gòu)評(píng)議環(huán)節(jié)進(jìn)行評(píng)審。為了確保在后續(xù)流程中設(shè)計(jì)約束不被破壞，相關(guān)設(shè)計(jì)也會(huì)以門(mén)限的形式掛載到流水線上，例如對(duì)比指標(biāo)是否達(dá)成，關(guān)鍵點(diǎn)測(cè)試覆蓋率是否達(dá)標(biāo)等。
在開(kāi)發(fā)階段，通過(guò)代碼掃描工具，能夠低成本的找出存在性能缺陷的代碼段，并提示開(kāi)發(fā)者及時(shí)修改。目前市面上有眾多靜態(tài)掃描工具可供選擇，它們不僅能識(shí)別性能問(wèn)題，也能發(fā)現(xiàn)安全和質(zhì)量問(wèn)題。
被識(shí)別為性能關(guān)注點(diǎn)的功能，需要開(kāi)發(fā)者為關(guān)鍵代碼編寫(xiě)微基準(zhǔn)測(cè)試。很多語(yǔ)言和框架已經(jīng)內(nèi)置了一些微基準(zhǔn)測(cè)試的框架，例如 go test 的 benchmark。基礎(chǔ)設(shè)施團(tuán)隊(duì)也可以對(duì)各類開(kāi)源的方案進(jìn)行封裝和適配，為開(kāi)發(fā)團(tuán)隊(duì)提供開(kāi)箱即用的微基準(zhǔn)測(cè)試框架、庫(kù)，以及模板等。
另外，通過(guò)插樁、埋點(diǎn)等形式，能將性能關(guān)注點(diǎn)地圖與分析系統(tǒng)關(guān)聯(lián)起來(lái)，在開(kāi)發(fā)階段參照性能關(guān)注點(diǎn)地圖進(jìn)行插樁，可以為后續(xù)流程提供豐富的統(tǒng)計(jì)和分析數(shù)據(jù)。
傳統(tǒng)流程中，性能測(cè)試占比本身較低，因此通過(guò)簡(jiǎn)單的腳本式用例結(jié)合常見(jiàn)的性能探測(cè)工具就可以滿足測(cè)試需求。但隨著性能左移的落地，測(cè)試環(huán)節(jié)對(duì)性能測(cè)試的要求從孤立功能的通用指標(biāo)測(cè)試轉(zhuǎn)化為對(duì)系統(tǒng)整體的性能仿真和多維度的指標(biāo)驗(yàn)證，此時(shí)傳統(tǒng)性能測(cè)試方法可能因效率低下而難以為繼。
如上圖所示，通過(guò)構(gòu)建符合企業(yè)自身場(chǎng)景的性能測(cè)試體系，能夠?yàn)樾阅軠y(cè)試提供基礎(chǔ)能力支撐。成熟的測(cè)試框架，一方面集成了標(biāo)準(zhǔn)化的用例模板或腳手架，簡(jiǎn)化通用場(chǎng)景用例的編寫(xiě)，另一方面可為用例編寫(xiě)者提供負(fù)載生成、指標(biāo)收集、執(zhí)行任務(wù)編排、分析可視化等各類原子工具，方便按需組合。
最后，也可以建立插件市場(chǎng)，將上述用例模板和原子化工具在企業(yè)內(nèi)部開(kāi)放并自下而上形成生態(tài)閉環(huán)。
DevPerfOps 要求能實(shí)現(xiàn)性能工程的反饋閉環(huán)。性能左移已經(jīng)讓性能相關(guān)工作盡可能前置，但為了實(shí)現(xiàn)完整的反饋閉環(huán)，如何持續(xù)的進(jìn)行性能分析和優(yōu)化則更為關(guān)鍵。
系統(tǒng)上線后，真實(shí)的運(yùn)行數(shù)據(jù)將不斷驗(yàn)證性能指標(biāo)是否達(dá)成，對(duì)發(fā)現(xiàn)的性能問(wèn)題，也會(huì)開(kāi)展性能優(yōu)化工作。但系統(tǒng)并非一成不變，隨著版本不斷迭代，各類性能問(wèn)題可能也會(huì)反復(fù)發(fā)生。為了能持續(xù)的監(jiān)控系統(tǒng)性能，更快地識(shí)別性能變化并定位導(dǎo)致變化的代碼塊，需要提供性能看護(hù)和定界分析的能力。
看護(hù)的本質(zhì)是建立基線，度量變化。上線前性能測(cè)試和上線后性能監(jiān)控都可以產(chǎn)生大量性能指標(biāo)數(shù)據(jù)，對(duì)指標(biāo)數(shù)據(jù)進(jìn)行清洗和篩選后，形成不同環(huán)境下的性能基線。在版本迭代過(guò)程中，通過(guò)對(duì)比基線，就能方便的發(fā)現(xiàn)性能變化點(diǎn)和劣化點(diǎn)。
傳統(tǒng)的性能基線大都來(lái)自于施加外部負(fù)載而得到的整體監(jiān)控?cái)?shù)據(jù)，這種將系統(tǒng)看做黑盒的性能基線缺少細(xì)節(jié)信息，這導(dǎo)致即便通過(guò)基線對(duì)比發(fā)現(xiàn)了指標(biāo)劣化，也難以快速定位到問(wèn)題所在。我們基于性能關(guān)注點(diǎn)地圖，可以設(shè)置更細(xì)致的監(jiān)控追蹤點(diǎn)，對(duì)系統(tǒng)形成更深入的洞察。因此通過(guò)將黑盒觀測(cè)指標(biāo)與進(jìn)程級(jí)、組件級(jí)觀測(cè)指標(biāo)相關(guān)聯(lián)，使看護(hù)報(bào)告能提供進(jìn)一步的信息檢視診斷能力，幫助定位性能劣化根因。
理想情況下，性能指標(biāo)數(shù)據(jù)的變化服從高斯分布，很容易統(tǒng)計(jì)和對(duì)比。然而實(shí)際場(chǎng)景中，性能指標(biāo)的波動(dòng)趨勢(shì)遠(yuǎn)比仿真環(huán)境下復(fù)雜得多，通過(guò)概率統(tǒng)計(jì)方法對(duì)指標(biāo)數(shù)據(jù)進(jìn)行處理后，才能形成判斷性能劣化的依據(jù)。常見(jiàn)的，指標(biāo)分布中出現(xiàn)少量離群點(diǎn)，可能預(yù)示著出現(xiàn)了環(huán)境問(wèn)題或是功能故障，而指標(biāo)分布偏左或偏右表示可能存在未分離的變量影響，需要增加觀測(cè)指標(biāo)。
看護(hù)報(bào)告可以指出哪幾個(gè)關(guān)聯(lián)指標(biāo)出現(xiàn)劣化，順著這些指標(biāo)我們能大致將分析范圍縮小到到服務(wù)或模塊級(jí)別。但這種級(jí)別的指標(biāo)數(shù)據(jù)粒度還是太粗，為了實(shí)施性能優(yōu)化，需要分析更細(xì)粒度的性能數(shù)據(jù)，才能找到具體的劣化代碼塊。
如圖所示，為了深入的了解服務(wù)或模塊的性能變化，一般采用性能剖析的手段，在函數(shù)級(jí)別進(jìn)行數(shù)據(jù)采樣。采樣剖析可以生成函數(shù)調(diào)用棧、函數(shù)總耗時(shí) / On CPU 耗時(shí)、函數(shù)內(nèi)存消耗、堆內(nèi)存分析等報(bào)告，通過(guò)它們來(lái)尋找劣化代碼塊。通過(guò)對(duì)各類性能剖析工具進(jìn)行封裝，可以固化用例、簡(jiǎn)化操作，并實(shí)現(xiàn)工具自動(dòng) attach 到 Pod 或?qū)嵗饰鐾瓿珊髷?shù)據(jù)自動(dòng)上報(bào)，生成分析結(jié)果圖。
成功的優(yōu)化不僅能改善系統(tǒng)性能，還可以與相關(guān)的多個(gè)性能指標(biāo)進(jìn)行關(guān)聯(lián)。收集優(yōu)化前后各類指標(biāo)數(shù)據(jù)的變化，積累起來(lái)形成指標(biāo)特征，嘗試訓(xùn)練生成性能劣化模型。在未來(lái)的性能看護(hù)場(chǎng)景下，發(fā)現(xiàn)指標(biāo)劣化后，系統(tǒng)能自動(dòng)嘗試進(jìn)行根因識(shí)別，給出可能的劣化點(diǎn)位置以及匹配到的優(yōu)化案例，從而進(jìn)一步降低性能優(yōu)化的成本。
通過(guò)前文提到的各種實(shí)踐，研發(fā)團(tuán)隊(duì)基本實(shí)現(xiàn)了 DevPerfOps 的全流程反饋閉環(huán)。接下來(lái)，讓我們回到性能工程的本質(zhì)：“為了對(duì)系統(tǒng)性能進(jìn)行持續(xù)改善和守護(hù)”。
性能優(yōu)化并非易事。成功的性能優(yōu)化，對(duì)實(shí)施者的技術(shù)水平、業(yè)務(wù)和架構(gòu)的理解程度，以及對(duì)系統(tǒng)觀測(cè)的深度都有較高的要求。得益于前文提到的各種實(shí)踐打下的堅(jiān)實(shí)基礎(chǔ)，提升性能優(yōu)化效率的路徑變得逐漸清晰：構(gòu)造平臺(tái)化能力，固化知識(shí)、搭建基礎(chǔ)設(shè)施并提供自助式服務(wù)。
積累了大量性能優(yōu)化經(jīng)驗(yàn)的專家永遠(yuǎn)是各個(gè)產(chǎn)品線爭(zhēng)搶的競(jìng)爭(zhēng)性資源。性能專家很關(guān)鍵也很稀缺，對(duì)專家經(jīng)驗(yàn)進(jìn)行固化，能有效降低成本并幫助提升一線開(kāi)發(fā)團(tuán)隊(duì)能力。
性能優(yōu)化包括分析和優(yōu)化兩個(gè)過(guò)程，分析要求邏輯性思維和關(guān)聯(lián)演繹能力，優(yōu)化更注重知識(shí)深度和經(jīng)驗(yàn)方法。性能專家 Brandon Gregg 著名的 “性能分析黃金60秒” 就是一種固化的通用分析方法。通過(guò) DevPerfOps 持續(xù)的性能反饋閉環(huán)，企業(yè)逐步積累了富有參考價(jià)值的性能分析優(yōu)化的方法路徑，我們可將這些過(guò)程總結(jié)成知識(shí)圖譜：包括性能分析路徑、性能優(yōu)化模式以及案例等。知識(shí)圖譜不僅能對(duì)新手產(chǎn)生足夠的指引，形成更加順暢的性能優(yōu)化體驗(yàn)，也可以成為了企業(yè)不可多得的無(wú)形資產(chǎn)。
知識(shí)圖譜能顯著提升通用場(chǎng)景性能優(yōu)化的效率，但性能專家本身是不可或缺的，畢竟仍然存在大量孤立場(chǎng)景和疑難雜癥。通過(guò)開(kāi)發(fā)平臺(tái)化能力，研發(fā)團(tuán)隊(duì)可以在平臺(tái)上創(chuàng)建 “性能優(yōu)化專項(xiàng)”，將服務(wù)架構(gòu)圖、業(yè)務(wù)場(chǎng)景描述、已有的性能分析結(jié)果等相關(guān)上下文都匯總在項(xiàng)目里，并通過(guò)預(yù)約系統(tǒng)申請(qǐng)相關(guān)領(lǐng)域的專家資源。這樣性能專家一旦進(jìn)入項(xiàng)目，就能以最快的速度熟悉上下文，并基于項(xiàng)目授權(quán)的臨時(shí)憑證訪問(wèn)相關(guān)系統(tǒng)，也可以隨時(shí)通過(guò)視頻會(huì)議進(jìn)行遠(yuǎn)程協(xié)助。
不常進(jìn)行性能優(yōu)化的研發(fā)人員，即使有知識(shí)圖譜作指導(dǎo)，在面臨性能優(yōu)化工作時(shí)也總感到無(wú)從下手。類似 “性能分析黃金60秒” 的實(shí)踐就是為了幫助實(shí)施者快速入手，并了解系統(tǒng)概貌的一種實(shí)踐。
既然我們已經(jīng)擁有了觀測(cè)系統(tǒng)、工具插件市場(chǎng)、分析優(yōu)化知識(shí)圖譜、性能看護(hù)數(shù)據(jù)和劣化特征模型，基于此可以整合這些優(yōu)秀實(shí)踐，并通過(guò)自動(dòng)化的手段，為研發(fā)人員提供啟發(fā)式的自助分析工作流。
如上圖，研發(fā)人員在平臺(tái)上創(chuàng)建項(xiàng)目，選擇關(guān)注的服務(wù)或系統(tǒng)后，平臺(tái)根據(jù)歷史觀測(cè)數(shù)據(jù)繪制服務(wù)調(diào)用/依賴圖，并展示節(jié)點(diǎn)的基本概況、性能指標(biāo)和關(guān)聯(lián)的性能優(yōu)化案例。平臺(tái)還可基于以往的劣化特征模型，建議用戶關(guān)注可能存在問(wèn)題的服務(wù)或?qū)嵗Ｖ螅脩粝裸@到某個(gè)感興趣的實(shí)例，并對(duì)該實(shí)例啟動(dòng)分析。
分析會(huì)先執(zhí)行通用采集器，繪制基于時(shí)間軸聯(lián)動(dòng)或組件聯(lián)動(dòng)的數(shù)據(jù)采集結(jié)果，根據(jù)初次采集結(jié)果，用戶可進(jìn)一步選擇進(jìn)程或線程，進(jìn)行二次性能剖析，通過(guò)調(diào)用棧、火焰圖甚至 TopDown 分析等手段，發(fā)現(xiàn)問(wèn)題。為了識(shí)別具體的代碼劣化點(diǎn)，用戶可調(diào)取同一服務(wù)之前版本的性能剖析歷史，進(jìn)行差分對(duì)比，嘗試發(fā)現(xiàn)變更點(diǎn)和問(wèn)題來(lái)源，還可以通過(guò)函數(shù)符號(hào)關(guān)聯(lián)代碼庫(kù)或是匯編指令，直接在代碼/指令級(jí)別進(jìn)行 Diff 來(lái)發(fā)現(xiàn)問(wèn)題。當(dāng)發(fā)現(xiàn)了性能問(wèn)題后，可以參考知識(shí)圖譜和以往案例，快速形成優(yōu)化方案。
從性能工程的挑戰(zhàn)、目標(biāo)以及實(shí)踐來(lái)看，企業(yè)建設(shè)性能工程體系的訴求逐漸加強(qiáng)，條件也在不斷成熟：云原生基礎(chǔ)設(shè)施、全鏈路可觀測(cè)、AI 輔助等技術(shù)的不斷發(fā)展，企業(yè)越來(lái)越有信心能建成性能工程系統(tǒng)。
如上圖所示，結(jié)合前文的內(nèi)容，我們認(rèn)為性能工程體系的演進(jìn)，從成熟度路線上可分為以下幾個(gè)層次：
(1) 流程化：
(2) 數(shù)字化：
(3) 資產(chǎn)化
(4) 平臺(tái)化
隨著成熟度水平的持續(xù)提升，企業(yè)可以逐步建成完整的性能工程平臺(tái)，其能力和層次構(gòu)成可參考下圖：
性能工程平臺(tái)所能提供的能力涵蓋了整個(gè)研發(fā)流程的各個(gè)部分，包括前文提到的建模能力、測(cè)試框架、分析工具、看護(hù)定界、性能專項(xiàng)等等。為了更好的實(shí)施這些能力，通過(guò)觀測(cè)服務(wù)、知識(shí)庫(kù)、插件市場(chǎng)等基礎(chǔ)服務(wù)對(duì)上游能力矩陣形成支撐。最后，企業(yè)的資源基礎(chǔ)設(shè)施以及數(shù)據(jù)基礎(chǔ)設(shè)施，為支撐服務(wù)和能力矩陣提供最底層的運(yùn)行時(shí)和存儲(chǔ)支持。
性能工程，是指通過(guò)設(shè)計(jì)、構(gòu)建工具鏈和工作流，從而對(duì)系統(tǒng)性能進(jìn)行持續(xù)改善和守護(hù)的一類實(shí)踐方法。
伴隨著硬件發(fā)展不斷放緩，系統(tǒng)架構(gòu)愈發(fā)復(fù)雜，維護(hù)和演進(jìn)成本高企，性能問(wèn)題在近年來(lái)逐步暴露。這給企業(yè)研發(fā)帶來(lái)了許多問(wèn)題和負(fù)擔(dān)，但也為工程實(shí)踐領(lǐng)域引入了新的機(jī)遇。
經(jīng)過(guò)上一篇《什么是性能工程》和本篇《性能工程實(shí)踐》，我們從硬件和軟件的發(fā)展角度討論了性能在軟件研發(fā)流程中的重要性，也提到了在當(dāng)下研發(fā)流程中嵌入性能相關(guān)工作的痛點(diǎn)和挑戰(zhàn)。
通過(guò)性能工程實(shí)踐方法，我們期望能通過(guò)性能左移、性能看護(hù)和定界分析構(gòu)建 DevPerfOps 反饋閉環(huán)，并構(gòu)建性能工程平臺(tái)化能力來(lái)固化專家經(jīng)驗(yàn)、沉淀方法，以至于最終形成自助式的性能分析和優(yōu)化流程。
相信越來(lái)越多的開(kāi)發(fā)者和組織都會(huì)開(kāi)始關(guān)注性能工程領(lǐng)域，探索更優(yōu)秀的方法和實(shí)踐，以更好的駕馭復(fù)雜系統(tǒng)。
本文鏈接：http://www.tebozhan.com/showinfo-26-13336-0.html性能工程實(shí)踐
聲明：本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問(wèn)題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
上一篇： Postman 腳本的奧秘：JavaScript 的內(nèi)置對(duì)象和方法
下一篇： 利用Python群組分析方法剖析客戶行為
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)