影音體驗是真的強 簡單聊聊iQOO Pad
大公司的好處就是產品線豐富，非常細分化的東西也能給你做出來，例如早先我們看到了新的vivo Pad2，之后我們又在iQOO Neo8 Pro的發布會上看到了iQOO的首款平板產品iQOO Pad。雖
作者 | 張旭海
性能工程，是指通過設計、構建工具鏈和工作流，從而對系統性能進行持續改善和守護的一類實踐方法。
本文將從起源開始探尋性能工程出現的必然性，進而以軟件研發流程中處理性能問題和實施性能優化時所遇到的挑戰為出發點，來討論性能工程的定義以及企業實踐性能工程的目標。
圖源：《計算機體系結構：量化研究方法》
上圖展示了處理器性能在近 40 年間的發展趨勢。1986 年開始到 2003 年這段時間，處理器性能每年增加 52%，17 年性能翻了 25 倍。然而由于登納德縮放比例定律的終結，單核性能無法再增長，導致 2003 年開始性能增長的方向從單核轉向了多核，性能增速有所降低，但也依然稱得上高增長。然而，隨著摩爾定律的逐漸失效，2015 年開始年均性能增速僅剩 3.5%，這種速度與先前相比可謂幾乎停滯了。
另外，在單核處理器主流的年代，處理器主要通過指令級并行來提升性能，這對軟件開發來說幾乎無感。而多核時代到來后，主要通過數據級并行（例如 SIMD）和線程級并行（多任務）來提升性能，這種優化很依賴代碼設計，因此對程序員也提出了更高的要求。
總之，如果不發生大的技術變革，軟件性能再也無法簡單的通過硬件的更新而大幅增長了，然而隨著各種新奇功能的出現，用戶對性能提升的需求卻絲毫未減。
與硬件不同，得益于高度靈活的架構，軟件一直朝著擴大規模的方向發展。為了治理不斷膨脹的軟件規模，軟件架構從早年的單體應用逐步發展到 SOA 架構，再到分布式、微服務架構和云原生技術等。如今的軟件系統規模越來越大，越來越復雜，只有通過不斷的分層和分治才能有效的對其進行控制和演進。
圖源：Uber 的微服務架構圖
然而，正因為對系統架構的拆分，導致服務間的交互早已不再是單個函數的調用，而是跨進程調用甚至遠程調用。正如上圖所示的Uber 的微服務架構圖，復雜的調用鏈路上任何一個環節都有可能存在性能瓶頸。系統間依賴的復雜度越高，出現性能阻塞點的概率就越大，如果不加以治理，其結果就是運行低效和難以擴展。
隨著在線業務的逐漸飽和，疊加多變的經濟形勢，企業越來越感受到基礎設施的巨大成本對經營產生的顯著影響。
圖源：2023 State of the Cloud Report
據_2023 State of the Cloud Report_顯示，云成本管理十年來第一次超過了云安全，成為企業用云的頭號挑戰。同時，公有云支出平均超出企業預算 18%，并且云成本仍在逐年增長。成本的增長驅使人們想盡辦法提升資源的利用率和分配效率，這也引領了近些年虛擬化技術和容器化技術的發展趨勢。
但在 CNCF 發布的 _FINOPS FOR KUBERNETES_ 中顯示，即便在容器技術大幅提升資源利用率的情況下，仍有 68% 的企業表示在遷移至 K8s 后其計算資源成本反倒增加了。畢竟，遷移 K8s 給系統引入了新的復雜度，也引入了適配和學習的隱性成本。
通過對系統進行更深層次的觀測，發現性能劣化問題和性能阻塞點進而優化性能，能夠在提供同樣服務水平的前提下降低硬件開銷，充分利用硬件算力，并改善用戶體驗，從而在多個角度降低成本。因此在如今這樣成本敏感的時代，性能優化意義非凡。
即便是軟件性能比以往任何時候都更重要，但想要順利地把性能融入研發工作流，卻并不是件容易的事。
正如前文提到的，現有研發流程一般只會在測試階段安排少量性能測試內容，而其他各研發環節都沒有對性能形成固定的認識。
設計階段，架構師通常會基于自身的經驗和知識，進行一定程度的性能考量，但大都不會輸出完整的性能建模方案和驗證方法。
開發階段，程序員也是在完成業務開發之余，零散的寫一些性能相關的代碼，且不太可能提供完整的性能測試用例。
測試階段，雖然有性能測試，但是否覆蓋了關鍵性能路徑？測試方法是否存在偏頗？也是一筆糊涂賬。抓緊測完按時上線永遠是第一位。
上述流程現狀實際上是把性能問題推到了 Day2。測試階段發現性能問題已經很遲，而倘若上線后再出性能故障，一定會大動干戈，傷筋動骨，甚至要調整架構。習慣了“性能后置”，想要打破現有流程，引入新的環節，對已經形成思維定式的研發團隊實在是很不容易。
性能問題是復雜且多樣的，其場景可能介于 Cynifin 框架中 Complicated 和 Complex 之間，需要通過對問題審慎的分析和對系統深入的洞察才有可能找到正確的優化路徑。
性能優化的實施者不僅需要對被分析系統的整體架構和關鍵業務路徑有清晰的認識，還要掌握系統層面的基礎知識和原理，以及各種性能分析工具的使用。此外，為了提升定位問題和尋找優化方向的成功率，性能優化方法和理論以及大量的實踐經驗也不可或缺。
以上要求對一般的研發人員來說挑戰極大，因此實際當中遇到性能問題往往需要依賴性能專家和領域專家的共同努力，但面對多種多樣的性能問題，專家資源往往“捉襟見肘”，增加時間成本的同時也難以規模化推進性能改進。
正因專家資源的稀缺性，性能優化通常會首先由研發人員嘗試介入。實施優化的前提是數據收集和問題分析，即便是如今的可觀測系統越來越強大，但在進行性能分析和系統剖析時大都還是會依賴外部采集分析工具。
然而，現實是不同的編程語言、技術框架、中間件和操作系統都有自己的一套實用工具，這些工具之間的使用存在差異，關注點與數據格式也不盡相同。對各種工具的熟悉和使用存在可觀的成本與學習負擔，也導致對人員能力的特殊需求。
圖源：_Linux Performance Observability Tools
有過分析性能問題經驗的人都知道，選擇并使用數種工具，在眾多的運行結果中進行數據關聯來尋找問題蹤跡，是性能分析和優化工作的日常。由于數據缺少關聯性，展現形式也不夠直觀，使得這類分析工作存在巨大的認知負載。對大多數應用開發者來說，這種高認知負載導致了在性能優化工作上的巨大負擔。
基于前面提到的在實施性能優化過程中的問題和挑戰，我們期望通過設計、構建工具鏈和研發工作流，來落地稱為 “性能工程” 的工程化方法，以實現標準化和規模化的系統性能持續改善及守護。
為了明確這種工程化方案的內涵以更好的指導工程落地，我們嘗試定義性能工程的目標：
為了改變研發工作流中忽視性能的現狀，通過在完整 DevOps 流中引入性能工程改造點，以實現嵌入性能工程的研發工作流反饋閉環。
上述全流程方法，從設計規劃階段開始關注性能，到運營階段完成分析和看護，能形成性能工程的持續反饋閉環，也能實現研發性能左移。
通過持續的指標檢測，形成性能指標數據庫，將積累的性能指標在不同系統之間關聯，能夠從趨勢上洞悉業務變化從而以數據驅動架構設計決策。
對日常性能分析和優化的實踐經驗進行總結提煉，形成特定場景的性能分析流程、性能劣化反模式，以及性能優化思路，固化進知識庫以供參考。知識庫使業務研發人員也能基于標準化流程嘗試解決性能問題，這極大地降低了性能專家的工作量，使其能更專注于少量疑難雜癥的解決。
形成一定規模的知識庫后，一方面能夠基于知識沉淀出方法，進而研發出公共平臺組件一勞永逸的解決同類問題。另一方面能夠通過機器學習的手段，對發現的性能問題給出解決方法建議和步驟，進一步降低性能優化的難度。
通過構建平臺化的性能工程能力，為研發人員提供一站式的性能分析工具集和自助式使用體驗。在該場景中，研發團隊扮演需求提出方，平臺團隊扮演能力提供方。
通過建設可觀測體系，平臺可為研發團隊提供開箱即用的監控能力市場，常見的如 APM、全鏈路觀測等，實現對系統各類性能指標的一鍵監控。
通過封裝各類性能分析工具集，以幫助研發團隊通過簡單的操作就可以對不同環境下運行的各類異構應用、中間件、系統甚至硬件進行數據采集和即時分析，并生成可視化友好的分析報告，如火焰圖、調用圖、內存地圖、請求分析圖、線程分析圖等。
通過擴展持續交付流水線，允許研發團隊將各類性能指標和測試用例在流水線上集成和關聯，以方便形成性能基線，并為性能看護提供基礎設施和流程自動化的支持，以實現持續的性能改善，防止性能劣化。
本文先討論了性能問題日趨嚴峻且不容忽視，之后引出了研發團隊在處理性能問題時的現狀問題和挑戰，然后對應每一種問題，提出了性能工程的實現目標。
那么，如何才能開始建設性能工程體系？企業落地性能工程的實踐有哪些？怎樣評價企業性能工程建設的水平？
請看后續系列文章。
本文鏈接：http://m.www897cc.com/showinfo-26-10598-0.html什么是性能工程？
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
下一篇： 使用二進制字面量在現代C++中的應用
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號