陳顯銘(山丘)

讀完需要

6分鐘

速讀僅需 2 分鐘

陳顯銘，花名山丘，就職于螞蟻集團，對分布式應用架構、服務化、性能優化等有深入的理解。參與支付寶支付鏈路核心系統，設計、調優應用系統關鍵能力， 高效、穩定保障系統平穩支撐大促。曾歷經多年雙十一大促，對于性能調優、構建高可用系統有豐富的實戰經驗。熟悉常見的性能優化模式，比如應用結構優化、鏈路級、單系統優化等多種優化方式。對于常見的壓測模式，如單機壓測、鏈路級壓測都有深厚的積累。作為一名性能專家，以追求性能最大化為己任，與之相伴的自然是高技巧、高難度的代碼優化。這也是一名性能專家的畢生追求。

本章希望通過對性能優化的模式進行總結，使讀者了解常見的性能招式，并能通過這些招式，找到自己系統中的性能瓶頸點，或者當前應用所處的發展階段及下一步可能演進的模式。

性能是驅動應用結構演進的主要動力之一，本文會通過應用結構的變化揭示性能是如何在不同階段、以不同的結構驅動應用結構朝著下一個結構演進的。通過應用結構的發展也可以揭示，如何不做過度的設計，在應用盡量簡化且不浪費企業資源的情況下支撐企業業務的發展。首先說明性能優化的價值。

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

近年來，像阿里巴巴這類的大型一線互聯網公司已經不再滿足固定模式的水平擴展， 那么當一個機房的容量不足時要如何應對呢？一個城市的機房容量不足時又要如何應對？綜合不斷增長的業務述求，阿里巴巴這類公司正在實施單元化進程，根據一定的數據分片規則，使特定分片規則下的用戶訪問到特定單元化的應用系統，并通過不同城市的單元實現流量的自由切換和容災。技術總是在不斷更迭，今天的解決辦法是明天的問題，也許單元化也不是最終的解決辦法，總會涌現出越來越多的新挑戰和應用模式。

- EOF -

想要加入中生代架構群的小伙伴，請添加群合伙人大白的微信

申請備注(姓名+公司+技術方向)才能通過哦！

擴展閱讀

? ?

阿里專家馬飛翔：一文讀懂架構整潔之道2020-10-16DDD專家張逸：構建領域驅動設計知識體系2020-10-13京東架構師閆文廣：訂單系統高可用架構及演變過程2020-10-12架構師，是否需要寫代碼？2020-09-18阿里高級技術專家簫逸：如何畫好一張架構圖？2020-09-07大神手把手教你設計秒殺架構模型2020-09-06阿里巴巴閑魚架構負責人王樹彬：萬億交易規模技術架構實踐2020-09-05阿里高級技術專家張建飛：應用架構分離業務邏輯和技術細節之道2020-08-31波波老師大解密：如何成為優秀的架構師？2020-06-25微信支付軟件架構重構之旅2020-06-08一個思維習慣，讓你成為架構師2020-06-03阿里P9專家右軍：以終為始的架構設計2020-04-27

? ?END ? ??

#架構師必備#

點分享點點贊點在看

總結

以上是生活随笔為你收集整理的kali2020进入单模式_蚂蚁集团技术专家山丘：性能优化的常见模式及趋势的全部內容，希望文章能夠幫你解決所遇到的問題。

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