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