導讀：本文由演講整理而成。美圖秀秀社區自上線以來已經有近一年時間，不管是秀秀海量的用戶還是圖片社區特有的形態都給性能優化提出了巨大的挑戰。本文將會結合這一年內我們遇到的具體案例和大家分享下美圖秀秀社區在性能優化方面的探索和實踐，希望能給大家帶來一定的借鑒意義。

唐揚，美圖秀秀社區后端技術負責人，有著10 年以上的互聯網研發從業經驗，先后供職于網易、新浪微博，現任美圖秀秀社區后端技術負責人，負責秀秀社區系統的架構設計、性能調優和穩定性優化。長期專注于高并發下社交系統的架構設計、運行維護和性能問題的排查和解決，在高并發高性能分布式系統架構領域有著豐富的經驗。

美圖秀秀社區現狀和挑戰

眾所眾知，美圖秀秀是一款被廣泛使用的工具產品，從 2008 年發布以來，十年間 MAU 早已經過億，是拍照修圖領域的 No1 。在 2018 年 8 月份的時候，美圖發布了“美和社交”戰略，美圖秀秀作為先驅產品也從工具開始往圖片社區轉型，自全量開發以來的非常短的時間里，秀秀社區用戶量級迅速增長，用戶登錄率超過 50%?。???????

伴隨著秀秀社區用戶的急速增長，也給我們技術團隊的工作帶來了很大的挑戰：

1. 相比于其它發布不到一年的產品，秀秀社區在流量上是超出其他產品的。秀秀社區依托于工具存在，尤其在節假日或者周末的時候，大家拍照、修圖、逛社區，這些都會帶來不小的流量。

2. 秀秀社區還處于快速發展的階段，這對于我們的挑戰就是產品迭代快。大量的產品需求，頻繁地變更，導致我們沒有大塊的時間做系統的性能優化，我們做性能優化的過程就好像給一個時速 100?碼的汽車換輪胎，需要團隊深厚的技術積累和持續的耐心。

3. 美圖公司在這些年技術上有很多的積累。這些積累被快速應用到了社區產品中，比如推薦，廣告，它們以獨立服務的方式被秀秀社區所依賴，這些服務也會影響秀秀社區的性能。

面臨這些挑戰，秀秀社區是如何來做性能優化的呢？在此之前我們需要先明確一下性能優化的核心關注點是什么。

性能優化關注點

先來看下秀秀社區的一個簡化版的架構圖（圖一）。從圖中可以看到，秀秀社區的服務端按照業務做了垂直的服務拆分形成了獨立的服務層，服務層之下會依賴數據庫等資源還有一些第三方的服務。除此之外，由于圖片社區的產品特性，客戶端還深度依賴于云存儲，CDN 和圖片云處理系統。那么當我們考慮性能優化的時候，我們不應該僅僅局限在服務端優化，還需要關注從端上開始完整的調用鏈條的性能。

圖一秀秀社區的一個簡化版的架構圖

因此，在秀秀社區優化的過程中，我們始終秉持的一個理念是：站在終端用戶的角度來優化用戶的使用體驗。在用戶使用你的App過程中，無論是卡頓、白屏還是錯誤都是不能有的，所有的技術上的優化都需要全局考慮，服務端優化是其中很小的一部分，我們需要考慮用戶終端網絡情況，考慮如何更快的展示圖片，甚至需要考慮如何監控客戶端的卡頓。這些都是需要聯合客戶端、服務端、運維，甚至產品一起來完成性能優化，這是一個多個團隊協作的事情。

基于上述考慮點，我們需要對用戶使用體驗做評估，這樣可以幫助我們找到系統中存在的問題以及量化優化之后的效果。一般來說，性能評估會有兩個招數：

1. 通過一體化監控可以幫助我們了解已經存在的性能問題；

2. 通過全鏈路壓測，幫我們了解流量翻了幾倍之后的性能瓶頸，同時也可以幫助我們驗證性能優化效果。

這兩個手段在大廠都會有自己的解決方案，我這邊主要來介紹一下秀秀社區這邊的考慮。

一體化監控

???????談到監控系統，一般的處理方式是通過報表反應服務端的性能指標情況，幫助我們發現性能問題。但是很多時候我們會發現，服務端接口的性能比較平穩，但卻存在因為 DNS 解析、建立連接或者客戶端卡頓導致用戶的使用體驗很差的情況，這個僅僅靠服務端的監控是無法感知的，所以我們更需要考慮的是端到端的監控。

我們的監控系統在設計上涵蓋了從端上用戶發起請求開始，到服務端業務處理，到資源層的數據響應這個完整的鏈路，這需要一系列的監控系統才能完成，我們稱之為一體化監控體系。這一套監控體系主要有客戶端監控和應用監控，輔以基礎監控、資源監控、容器監控以及鏈路監控。通過這套從用戶終端到操作系統的立體監控體系，可以幫助我們監控端到端的性能情況。

客戶端監控

客戶端監控–?Hubble

我們自研了一套客戶端監控體系，番號為「 Hubble 」（哈勃），期望可以像哈勃望遠鏡一樣精確監控系統性能。使用 Hubble 會給我們帶來三個方面的好處：

1. 真實地反饋用戶的使用體驗：Hubble 的所有的監控數據源均來自客戶端的用戶訪問數據實時上報，能夠準確的，真實的，實時的反應用戶操作。

2. 它是性能優化的指向標：當做業務架構改造、服務性能優化、網絡優化等任何優化行為時，Hubble 可以反饋用戶性能數據，引導業務正向優化接口性能、可用性等指標。

3. 幫助我們監控 CDN 鏈路質量：之前的 CDN 的監控嚴重依賴 CDN 廠商，存在的問題是 CDN 無法從端上獲取到全鏈路的監控數據，有些時候端上到 CDN 的鏈路出了問題， CDN 廠商是感知不到的，而 Hubble 彌補了這方面的缺陷，除此之外還可以通過告警機制督促 CDN 及時優化調整問題線路。

?Hubble 的架構設計???????

由于 Hubble 主要關注的是用戶網絡情況，所以在設計之初，考慮到中國復雜的網絡環境，我們主要選取了地區+運營商的維度來幫助我們做數據分析，從而確定性能瓶頸。它的優勢主要體現在兩個方面：

1. 出現局部故障的時候，通過地區+運營商的組合數據可以直接查出哪個地區可能出現問題，這對于我們做問題排查尤為重要；

2. 在調整 CDN 配置的時候，可以輔助做數據支撐，比如我們需要讓某一地區用戶不走 CDN 直接回源，可以使用 Hubble 來觀察對于用戶的使用體驗的影響，幫助我們找到用戶體驗和成本的平衡點。

除此之外，我們還可以從客戶端平臺、域名和網絡類型維度來聚合數據。有了這些維度之后，我們需要確定 Hubble 監控的指標：請求量、錯誤率和耗時情況。維度和指標就共同構成了我們的 Hubble 監控系統。

特別注意的是，上面提到的耗時是端到端的完整耗時，而不僅僅是服務端的耗時。為了方便針對耗時做針對性的優化，我們先把這個耗時做拆解和細化：

1. 首先，由于客戶端線程切換或者異步隊列的延遲，在建立連接之前我們有一個等待的時間；

2. 接下來需要做域名解析， TCP 握手建立連接，而我們是 HTTPS 服務，所以還要加上一個 SSL 認證的過程；

3. 這個時候，才會真正發起對接口的請求，而后等待服務端處理，我們會收到第一個響應包，也就是首包的時間；

4. 最后，還有依據響應包的大小接收所有數據的時間。

以上就是一次完整請求的過程。了解這個之后，我們可以針對請求耗時中的每個步驟做針對性優化。

Hubble 監控能讓我們清晰的看到客戶端的整體性能情況以及響應時間的詳細數據。Hubble 的整體實現架構不是很復雜，如下圖二所示。

圖二Hubble架構圖

如圖二所示，我們在端上植入一個 SDK 采樣客戶端網絡請求，每 1 分鐘按照定制的格式上報到服務端，服務端將原始數據寫入 ELK 用作備份，同時將數據寫入 Kafka ，之后有 Storm 處理程序對原始數據做聚合處理并且寫入 InfluxDB ；最后就可以在 grafana 上展示了。有了 Hubble ，我們就相當于多了一雙眼睛，任何調整和優化都有數據做支撐。

應用監控

除了客戶端監控，重點要關注的還有應用監控，我們在做應用監控之前，首先考慮服務端關注的性能指標，我們參考了從谷歌的”四個黃金指標“衍生的 RED 指標體系，吞吐量（ Request Rate ?）、錯誤率（ ErrorRate ?）和響應時間（ Duration ?）。先來看下影響這些指標的內在因素和外部因素。

內在因素：對于 Java 應用來說主要是 GC 暫停，也可能是一些鎖的阻塞或者是線程池的異步隊列堆積。

外部因素：主要是依賴的存儲資源還有服務的影響，還有就是內網地波動以及容器宿主機的性能。

那么我們在做服務端監控的時候，如何展示這些指標和因素的關鍵數據，來幫助我們來發現問題和分析問題就顯得尤為重要。基于此，我們將服務端需要監控的數據拆解為四個部分，分別是訪問量趨勢數據、資源 profile數據、JVM 數據和線程池數據。

訪問量趨勢數據

???????訪問量趨勢數據是用來展示系統整體的性能情況。如上文所說，我們在服務端的指標上需要關注吞吐量、錯誤率和響應時間，訪問量趨勢數據能完全展示這些性能數據。

1. 在吞吐量上，我們除了需要展示整體數據以外還需要展示慢請求比例；

2. 在響應時間上，我們關注的是平均響應時間，但是在只有少量慢請求的情況下，我們很難從平均響應時間上看出問題，所以還需要知道某一個響應時間區間的比例是多少，也就是響應時間的分布情況；

3. 在錯誤率上，我們需要對錯誤做分類，這個分類是由業務來決定的，比如說認證的錯誤率上升可能影響不大，但是如果有些破壞性的錯誤比例上升了，我們就要關心一下是否是業務出問題了。

這些數據我們可以從 tomcat 和 lb 的 access log 以及業務的日志中獲得。當我們從訪問量趨勢發現有性能問題后，我們需要怎么排查呢？下面要說的幾張報表可以幫助我們定位問題。

資源?profile?數據

首先是資源 profile 數據。在我們日常的排查問題時，比較常見的情況是依賴的資源或者服務出現響應時間上的波動，這時我們需要知道具體哪個端口、哪個實例或者哪個服務出了問題，這就是我們的資源profile 數據。

當我們需要對資源客戶端和微服務客戶端進行改造時，在調用后端資源和服務的時候打印 profile 日志，并且把這些日志數據發送給監控系統，經過聚合之后就形成了資源 profile 數據。?

Profile 報表目前主要用來檢測數據庫、緩存和第三方服務的響應情況，它是我們排查性能問題的利器，可以很方便的定位是哪種資源的哪個接口或者哪個 URL 出了問題，然后再做定向的排查。

JVM數據

下一個要說的是監控 JVM 信息的報表。我們知道由于對于內存的過度使用，高并發或者參數配置不當，會導致應用頻繁的觸發 GC ?，帶來 stop the world 的暫停，同時也會搶占 CPU 資源，影響整體的吞吐量。所以我們需要監控整體內存的大小、每個內存區的大小以及GC 停頓的間隔和時間。

有了這份動態數據之后，我們還可以對JVM 的參數做一些針對性的優化。比如在我們的業務模型下，我們的內存可以設置為多少、 GC 算法要使用什么等等，從而保證我們 GC 停頓時間控制在可接受的范圍之內，進而達到性能優化的目的。

線程池數據

???????最后我們對線程池也做了監控。我們使用線程池的目的是并發執行任務，減少響應時間，但是如果線程池中線程數設置不合理，或者是任務執行時間較長，就會造成線程池中活躍線程數大量增長，線程池內的隊列中任務堆積，阻塞新提交任務的執行，尤其是針對 tomcat 線程池的監控，一旦出現堆積，結果將是毀滅性的。因此，我們會定期的打印線程池的活躍線程數和任務堆積數。

除了通過一體化監控相關指標，發現和定位問題，壓測也是我們做性能問題排查的重要方法。

全鏈路壓測

美圖秀秀做全鏈路壓測有三個目的：

1. 通過全鏈路壓測幫助我們發現潛在的性能瓶頸，在流量達到一定量級的時候，哪些服務或者組件會先出問題，這樣我們可以做出一些預案來應對；

2. 壓測也可以為我們做容量評估提供數據支撐，這不僅僅是需要部署多少個? pod ?，也可以讓我們知道當到達性能上限的時候，CPU ?使用率是多少，內存閾值要設置成多少；

3. 在壓測的時候做預案演練，因為壓測一般會安排在流量低峰期進行，這樣我們可以降級一些服務來驗證預案效果，且盡量減少對線上用戶的影響。

全鏈路壓測的實現

???????美圖秀秀的壓測平臺在設計上也是參考了其他大廠的成熟做法。其實現圖如圖三。

圖三秀秀壓測平臺實現圖

1. 首先我們會將線上的流量拷貝存儲起來并且對壓測流量打上標記。這么做的原因是我們需要對壓測流量做一些特殊的處理，比如一些對于曝光數據比較敏感的服務如廣告服務，推薦服務，我們是不能將壓測的流量直接打過去的；

2. 另外也要屏蔽壓測對于大盤的統計的影響，我們會包裝一些 Mock 服務來模擬真實的系統；

3. 最后對于上行流量，我們會把壓測產生的數據寫入到單獨的影子存儲里面，以達到隔離的目的。

在壓測的過程中我們會逐步地增加流量，并且時刻關注系統監控指標，一旦響應時間有比較大的波動就立刻終止壓測，排查問題原因，在問題解決后，再進行新一輪的壓測。如此反復，直到到達目標的吞吐量為止。???????

我們通過一體化監控和全鏈路壓測這兩種手段來幫助我們評估端到端系統性能，不僅能幫我們找到優化的方向，也可以幫助我們驗證優化的效果。下文中我將給大家具體介紹下美圖秀秀社區做的一些優化的實踐。

美圖秀秀性能優化實踐

???????秀秀作為一個社區，流量最大也是最重要的頁面就是首頁，這相當于微博的信息流。而我們從點開首頁到首頁完全渲染，時間分為兩個大部分：一個是服務端接口的響應時間；另一個是圖片加載的時間，這是由秀秀社區的產品特性決定的。我們對這兩部份時間分別做細化，選取幾個關鍵點來做重點的說明，這幾個點分別是 DNS 解析優化、圖片傳輸優化以及服務端接口響應時間優化。

DNS解析優化

???????先來說下DNS 的優化。最初我們從兩個途徑發現 DNS 解析存在可優化的空間，一個是部分用戶反饋客戶端錯誤，一個是從 Hubble 監控中發現 DNS 時間存在毛刺。

我們知道，在做 DNS 解析的時候，我們先會查詢運營商的 LocalDns ，如果? LocalDns 沒有緩存，會從 root dns 開始做逐級遞歸查詢直至從權威DNS 查詢到結果為止，并且會在運營商的 LocalDns 上緩存起來。但是這會有幾個問題：

·?一旦 LocalDns 緩存失效，我們就需要請求公網 DNS 服務器做域名解析，在網絡波動的情況下查詢性能上會有尖刺；

· LocalDns 這個東西是很不靠譜的，有些小的運營商為了節省流量，會把一些域名解析到內網的內容緩存服務器上，甚至會解析到廣告或者釣魚網站上，出現域名劫持的情況；

·?有些運營商它自己不去解析域名，而是把解析請求轉發到別的運營商上，這就出現解析的 IP 和請求源來自不同的運營商，導致流量跨網。

在業界針對上述的問題是有成熟的第三方解決方案，就是 HttpDns 。HttpDns ?繞過了 LocalDns 這個原罪直接訪問 Http DNS Server ，也就能避免了這幾個問題。但是即使是使用了 HttpDns ，從 Hubble 監控來看平均的 DNS 時間也要 200-300ms ，所以我們要考慮一種方式可以盡量減少 DNS 的解析時間。

我們內部有一套解決這個問題的方案，番號為FastDNS ，它其實是一個客戶端 SDK ，在組件中我們可以通過代碼或者服務端下發的方式指定一些域名，在 SDK 啟動的時候異步的預先做解析，并且把解析結果寫入到一個LRU 緩存里面， SDK 每隔一段時間會定期地對LRU 緩存中的 IP 信息做健康檢查，如果檢查失敗就會從緩存中去掉。在本地網絡環境發生變化的時候，也會清空緩存來保證緩存數據的正確性。

圖四

這個異步解析有兩種策略，一種是走 LocalDns ，另一種是走 HttpDns 。這個策略的選擇是服務端來下發的，我們目前統一走 LocalDns ，如果解析失敗、超時或者不符合預期的話會走 HttpDns 解析。

當然，我們可以指定某個域名優先走?HttpDns?，但是HttpDns?解析出來的結果也可能不符合預期，我們需要一些容錯的機制保證，我們在對IP?地址做健康檢查的時候，如果發現解析?IP?地址不合格，就會標記這個域名，如果域名被多次標記?HttpDns?解析錯誤的話，我們會把這個域名降級為?LocalDns?解析

???????引入 FastDNS 之后，經過測試驗證平均耗時大概減少 50%?，最大耗時可以控制在 200ms 之內，而傳統的 LocalDns 方式最大 DNS 解析時間會到1秒以上。從 Hubble 監控來看，平均Http時間減少了80-100ms。

圖片傳輸優化

???????說完了DNS 解析優化，再來分享下我們在圖片傳輸優化方面做的一些事情，這主要包括以下三個方面：

1. 融合調度；

2. 圖片大小的優化；

3. 在端上做一些預加載的策略。

我將著重和大家分享一下融合調度和圖片大小優化方面我們的一些經驗。

先來看看融合調度，也是我們內部自研的系統名叫Chaos 。在接入融合系統前，我們圖片只能配置一個CDN 的地址，當這家 CDN 出現故障時我們只能在接到報障之后手動地切換，這樣會延長故障的時間，也有損用戶體驗。于是我們考慮是否可以給同一張圖片接入多家CDN 地址，并且在故障的時候做到自動切換呢？這就是融合調度系統在做的事情。

下面是融合調度系統的流程示意圖，從圖中我們可以看出融合調度系統主要由三部分組成：SDK 、服務端和 MeituDNS 。

圖五融合調度整體實現圖

當服務端在下發圖片地址的時候，會生成一個調度的地址，端上的融合調度SDK 會把這個調度地址發送給融合調度服務端，融合調度服務端把它轉換成真正的資源地址之后會請求 MeituDNS 來得到 DNS CNAME 。這里我們可以為一個域名配置多個 DNS CNAME 。同時我們會有一個質量監控平臺給 CDN 打分，這個打分的數據來自于客戶端對于 CDN 質量的真實上報，比如說響應時間情況以及錯誤發生數據。有了打分數據融合調度系統就可以決策我們優先使用哪一個 CDN 或者每一個 CDN 的流量分配比例是什么樣的，端上也就可以知道該從哪一個 CDN 獲取數據。

接入融合調度系統之后，我們從單一CDN 地址變成了動態使用的多 CDN 地址，提升了圖片下載的容錯率和用戶的使用體驗。

但是這個無法縮短圖片下載的時間，如果要縮短下載時間，需要考慮如何減小圖片的大小，同時還需要考慮圖片質量，我們不能以過度地損失圖片的質量來換取圖片大小地減少，這樣會造成圖片的失真。考慮到圖片的打開時間，我們還要保證更快的編解碼速率。?

綜合上述幾方面的考量，我們的思路是綜合評估不同的圖片編碼格式，達到提升碼率的目的。

我們備選的圖片格式有幾種：JPEG 、 WebP 和 HEIF 。試驗的方法如下，我們從秀秀平臺選取熱度 Top500 的圖像集合，分別用 HEIF ，libwebp 、 MozJPEG ?、libjpeg-turbo等編碼器對圖片做編碼，以 SSIM 來評估圖片失真情況，考察圖片壓縮性能，也就是輸出圖片碼率大小。通過實驗表明，在低分辨率下，HEIF 相對于 WebP 平均大約節省 20% 的碼率，相比于 JPEG 節省50%，而隨著源圖分辨率增加， HEIF 的優勢越來越明顯，碼率節省呈上升趨勢。另一方面，考慮到用戶查看圖片的體驗，我們也需要考慮解碼速率。經過測試，在 iOS 平臺下，HEIF 在解碼速率上無論硬解還是軟解都會優于 WebP ，但在安卓平臺下，HEIF 的軟解效率不佳，只有Android P 系統下的部分機型才支持對 HEIF 圖片格式做硬解，所以安卓平臺目前還是用WebP。

圖六

目前秀秀社區在 iOS 上推進 HEIF 格式的圖片，這樣相較WebP 大約可節省 20%?的圖片下載帶寬。不過有得必有失，HEIF 在編碼效率上相比 WebP 和 JPEG相差較遠，編碼時間大約是 JPEG 的 45 倍，是 WebP 的 12 倍，因此，我們采用了異步的方式來對圖片做 HEIF 編碼。

服務端優化

???????在說服務端優化之前，先來看圖七。這個是在 2015 年 3 月份 Rebel Labs 做的調研報告中的一張結論圖。

圖七

從圖七中不難看出，日常工作中遇到的性能問題中，因為數據庫慢查詢占54.8%?，不高效的代碼占到 51.5%?，而我們經常提到的 GC 問題只占 17.9%，IO 問題也只占 13%?。通過此圖告訴我們在分析問題的時候一定要避免盲目，通過一些排查方法來幫助我們找到問題的根本原因，這會讓我們的優化事半功倍。

我們常用的排查性能問題的方法有下面幾個：

·?其一是使用一些工具，我們一些常用的工具有這么幾類，一類是通過類似xxstat 、xxtop 了解整體資源負載情況；第二類是通過例如 Perf，DTrace ?等對 CPU 做 profile 的；最后是通過一些Java特有的工具來分析內存情況以及線程情況，如 jmc 、jstat 、jmap ；

·?其二我們還有一些日志，主要是業務日志還有 trace 日志，系統日志，GC 的日志也需要保留；

·?最后就是之前提到的監控，我們從監控上可以看到很多信息，有些簡單的問題可以從監控數據中直接得到結論。

真實案例剖析

下面介紹一個真實的案例，在案例中可以看下我們是如何使用上面的方法來分析和優化性能問題的。2019 ?年年初秀秀的流量增長很快，我們發現系統在重啟的時候性能衰減很厲害，慢請求比例會達到 10%?，這極大的影響用戶的使用體驗，并且也給后臺系統的穩定性埋下了炸彈，所以我們需要來集中精力解決它。首先，通過查看報表我們發現三個異常的情況：

1. memcached、 Redis 、 MySQL 以及依賴服務的響應時間都有所波動；

2. CPU 使用率上升一倍；

3. Safepoint 造成的 STW 頻率大幅上升，從每秒兩次上升到每秒20次。

經過分析判斷，發現依賴服務和資源的時間波動和Safepoint 的頻率上漲有關，于是我們先去解決這個問題。

首先我們在壓測環境下復現了這個問題，并且在啟動參數中增加打印詳細安全點信息的日志。在重啟后我們發現日志中出現大量撤銷偏向鎖類型的安全點日志。眾所周知，偏向鎖的目的是在無競爭或者低競爭下，某一個線程獲得了鎖之后，消除這個線程鎖重入的開銷，偏向于同一個線程再次獲得鎖。但是當系統競爭激烈時，其它線程嘗試獲得鎖，持有偏向鎖的線程會撤銷偏向鎖，這是需要等待所有線程到達全局安全點的，所以會造成系統暫停的情況。我們通過增加不啟動偏向鎖的參數，使得問題有了很大地緩解。

???????但是CPU 使用率上漲一倍的問題并沒有得到解決，我們通過給壓測環境增壓后慢請求再次出現，這個時候報表上的表現有兩個：新區 GC 的停頓時間從 20ms 上漲到 100ms ， CPU 使用率上漲了一倍。

我們嘗試通過分析 GC 日志和調整參數來降低新區 GC 的停頓時間，但都無功而返。那是否是因為CPU 使用率上升導致的 GC 線程無法搶占到 CPU 的時間，從而導致 GC 的響應時間增長呢？于是，我們在重啟的時候對CPU 做 profile ，果然發現 JIT 線程占用了大量的 CPU 資源。我們知道JVM 在啟動的時候是按照解釋方式來執行的，在應用運行一段時間之后，才會對字節碼做 C1 和 C2 編譯，提高熱點代碼的執行性能。所以我們的解決方案是預熱，在容器重啟之后先只放 10%?的流量，在低負載的情況下讓系統完成熱點代碼的編譯，然后再放全量。多次嘗試并且試驗后，可以看到收效還是非常明顯的。慢請求比例從原先的 10%?下降到?0.5%?以下。

從這個案例我們也可以看到性能優化另外兩點：一個是性能問題的原因可能是多方面的，需要不斷的追究根本原因；另一個是壓測環境真的非常重要，它可以幫助我們復現問題，也可以驗證性能優化的結果。

總結

通過秀秀社區化過程中性能優化的具體實踐，可以總結成三句話，希望對你有所幫助：

一、?性能的優化目標是關注用戶體驗，我們做的事情都要從終端用戶角度出發；

二、?一體化監控和全鏈路壓測可以幫忙我們發現性能問題，驗證優化效果；

三、?性能優化是一個系統工程，需要后端，前端，架構， SRE 等多個團隊共同協作完成。

總結

以上是生活随笔為你收集整理的从工具到社区，美图秀秀大规模性能优化实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。