螞蟻集團技術專家山丘：效能優化的常見模式及趨勢
點選“技術領導力”關注∆每天早上8:30推送
陳顯銘，花名山丘，就職於螞蟻集團，對分散式應用架構、服務化、效能優化等有深入的理解。參與支付寶支付鏈路核心系統，設計、調優應用系統關鍵能力， 高效、穩定保障系統平穩支撐大促。曾歷經多年雙十一大促，對於效能調優、構建高可用系統有豐富的實戰經驗。熟悉常見的效能優化模式，比如應用結構優化、鏈路級、單系統優化等多種優化方式。對於常見的壓測模式，如單機壓測、鏈路級壓測都有深厚的積累。作為一名效能專家，以追求效能最大化為己任，與之相伴的自然是高技巧、高難度的程式碼優化。這也是一名效能專家的畢生追求。
本章希望通過對效能優化的模式進行總結，使讀者瞭解常見的效能招式，並能通過這些招式，找到自己系統中的效能瓶頸點，或者當前應用所處的發展階段及下一步可能演進的模式。
效能是驅動應用結構演進的主要動力之一，本文會通過應用結構的變化揭示效能是如何在不同階段、以不同的結構驅動應用結構朝著下一個結構演進的。通過應用結構的發展也可以揭示，如何不做過度的設計，在應用盡量簡化且不浪費企業資源的情況下支撐企業業務的發展。首先說明效能優化的價值。
1
效能優化的優缺點
對效能進行優化有如下幾個優點：
降低業務成本。
提升系統穩定性。
提升使用者體驗。
效能優化的缺點是可能會使維護成本增加，增加程式碼、結構及技術棧的複雜度。以上所講到的效能優化的優缺點如圖 17.1 所示。
圖 17.1
2
效能優化的兩種模式
縱觀效能優化案例，效能優化整體上可以分為兩類：單應用優化和結構型優化。
單應用優化：關注單系統瓶頸，通過解決單系統瓶頸提升效能。
結構型優化：通過改造鏈路結構和配比進行整體效能的優化。
3
單應用優化
3.1
優化基本思路
圖 17.2
如圖 17.2 所示，優化基本思路包含如下幾個方面。
確定性能瓶頸/熱點。
確定優化方案。
實施優化方案並反饋優化情況。
3.2
確定性能瓶頸點/熱點的常見方法
確定性能瓶頸點/熱點的常見方法有如下兩種。
效能壓測：通過工具、人工等方式量化執行時的效能情況。
業務/程式碼梳理：通過程式碼走讀發現資源消耗熱點，通過統計程式碼對資源的操作量化程式碼對資源的消耗（比如一個業務操作會進行多少次資料庫呼叫，進行多少次服務運算等方式）。
3.3
壓測時通常觀察的內容及其所使用的工具
以 Java 環境為例，壓測時通常使用 JMeter 及 LoadRunner 發起壓力測試並收集壓測指標，使用 nmon 來檢測 Linux 的效能情況。nmon 是一種在 AIX 與各種 Linux 作業系統上被廣泛使用的監控與分析工具。除此之外，壓測時通常觀察的內容及其所使用的工具如下：
記憶體的使用情況：MAT、GC 日誌、vmstat。
I/O 情況：iostat。
網路情況：Netstat。
熱點程式碼：JProfiler、BTrace、JStack、JStat。
CPU 情況：Linux top 命令。
3.4
常見的優化手段及模式
常見的優化手段及模式大概有如下幾種。
靜態化：動態資料和靜態資料分離。
非同步化：使用非同步化減少主流程中的非關鍵業務邏輯。
並行化：使用多執行緒併發處理，縮短響應時間。
記憶體優化：減小物件所佔空間，減少物件建立的數量，優化資料模型。
去重複運算：優化業務邏輯，或者使用快取。
減少資料庫操作：為此，需要減少資料冗餘、資料快取等。
縮短資料庫事務：可以考慮使用短事務、非同步化、最終一致性等方式。
精簡程式碼邏輯：去除冗餘程式碼，諸如重複判斷的程式碼。
精簡日誌操作：要關注日誌大小，注意 I/O 上的瓶頸。日誌太多，說明生成的 String 也會很多，會增加 GC 的負擔。
4
結構型優化
此部分介紹的內容在很多網站架構變遷的文章中都會提到，下面通過圖示的方式展現出來。每個階段都有適用的軟體架構，出於對建設複雜度、維護成本的考慮，不必強求一開始就建設出很完整的技術體系。個人認為，效能是驅動應用體系演進的重要驅動力，可以通過下面的應用結構演進看出來。單應用時代的常見瓶頸先發生在資料庫上。由於所有的業務都儲存在一個數據庫（DB） 上，因此資料庫的讀寫和效能是可能遇到的第一個問題，如圖 17.3 所示。
圖 17.3
單應用時代對此問題的第一個常見解決辦法是使用快取（偏向應用級別的快取）。為了防止所有的資料讀寫都集中在資料庫上進行，首先想到的就是通過快取減少對資料庫的壓力，比如將配置資料全部載入到快取（某些場景可以使用類似 LRU 的快取）中，如圖 17.4 所示。
圖 17.4
單應用時代解決此問題的第二個辦法是使用獨立快取服務（集中式快取，如 MemCache），如圖 17.5 所示。
圖 17.5
單應用集中式部署帶來了應用叢集處理能力的提升，可以使應用進行水平擴充套件，如圖 17.6 所示。
圖 17.6
單應用集中式部署後的資料庫瓶頸如圖 17.7 所示。
圖 17.7
單應用集中式部署後的資料庫瓶頸的解決辦法是對資料庫進行拆分及讀寫分離，如圖 17.8 所示。
圖 17.8
為了應對更大範圍的請求量，需要進行服務化拆分，由此進入多應用分散式服務化時代，如圖 17.9 所示。
圖 17.9
隨著業務及資料的規模不斷擴大，又逐漸進入多應用分散式服務叢集化時代，此時依然存在一些問題需要解決，如圖 17.10 所示。
圖 17.10
5
兩個結構優化的案例
5.1
處理單點/網路瓶頸的可行方式
通過去分散式呼叫進行去中心化，可以規避網路裝置成為瓶頸和單點故障，如圖 17.11 所示。
圖 17.11
5.2
處理資料庫連線池瓶頸的可行手段
增加資料處理中間層可以緩解資料庫連線池的瓶頸，最好的處理方式是對架構進行服務化和單元化，將資料量大的資料庫進行拆分，分散壓力，如圖 17.12 所示。
圖 17.12
6
總結
對於小型企業的業務，通過進行較為簡單的單系統優化，並輔助結構性優化，便能滿足大部分企業的要求，如圖 17.13 所示。但隨著企業的業務量不斷增加，單獨的單機優化已經不能滿足需求。分散式部署是中大型企業的必經之路，水平擴充套件、垂直拆分、服務化等方式是實現分散式部署的方式。
圖 17.13
近年來，像阿里巴巴這類的大型一線網際網路公司已經不再滿足固定模式的水平擴充套件， 那麼當一個機房的容量不足時要如何應對呢？一個城市的機房容量不足時又要如何應對？綜合不斷增長的業務述求，阿里巴巴這類公司正在實施單元化程序，根據一定的資料分片規則，使特定分片規則下的使用者訪問到特定單元化的應用系統，並通過不同城市的單元實現流量的自由切換和容災。技術總是在不斷更迭，今天的解決辦法是明天的問題，也許單元化也不是最終的解決辦法，總會湧現出越來越多的新挑戰和應用模式。
-END-
推一下老K的小號“BAT架構”，專門研究BAT大廠技術架構，偏技術一些，感興趣的關注一下。
“BAT架構”，老K主理
大家在看：