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