系統(tǒng)架構(gòu)如何進(jìn)行性能優(yōu)化？

對(duì)于業(yè)務(wù)系統(tǒng)的性能優(yōu)化，我原來系統(tǒng)的談過分析和診斷的思路，今天再談下業(yè)務(wù)系統(tǒng)性能優(yōu)化里面我們常見的一些思考和分析系統(tǒng)性能問題的方法。

上線前的性能測(cè)試是否有用？

有時(shí)候大家可能覺得奇怪，為何我們系統(tǒng)再上線前都做了性能測(cè)試，為何上線后還是會(huì)出現(xiàn)系統(tǒng)性能問題。那么我們可以考慮下實(shí)際上我們上線前性能測(cè)試可能存在的一些無法真實(shí)模擬生產(chǎn)環(huán)境的地方，具體為：

1. 硬件能否完全模擬真實(shí)環(huán)境？最好的性能測(cè)試往往是直接在搭建完成的生產(chǎn)環(huán)境進(jìn)行。

2. 數(shù)據(jù)量能否模擬實(shí)際場(chǎng)景？真實(shí)場(chǎng)景往往是多個(gè)業(yè)務(wù)表都已經(jīng)存在大數(shù)據(jù)量的積累而非空表。

3. 并發(fā)能否模擬真實(shí)場(chǎng)景？一個(gè)是并發(fā)需要錄制復(fù)合業(yè)務(wù)場(chǎng)景，一個(gè)是并發(fā)量大時(shí)候需要多臺(tái)壓測(cè)機(jī)。

而實(shí)際上我們?cè)谧鲂阅軠y(cè)試的時(shí)候以上幾個(gè)點(diǎn)都很難真正做到，因此要想完全模擬出生產(chǎn)真實(shí)環(huán)境是相當(dāng)困難的，這也導(dǎo)致了很多性能問題是在真正上線后才發(fā)現(xiàn)。

系統(tǒng)本身水平彈性擴(kuò)展是否完全解決性能問題？

第二個(gè)點(diǎn)也是我們經(jīng)常談的比較多的點(diǎn)，就是我們的業(yè)務(wù)系統(tǒng)在進(jìn)行架構(gòu)設(shè)計(jì)的時(shí)候，特別是面對(duì)非功能性需求，我們都會(huì)談到系統(tǒng)本身的數(shù)據(jù)庫(kù)，中間件都采用了集群技術(shù)，能夠做到彈性水平擴(kuò)展。那么這種彈性水平擴(kuò)展能力是否又真正解決了性能問題？

實(shí)際上我們看到對(duì)于數(shù)據(jù)庫(kù)往往很難真正做到無限的彈性水平擴(kuò)展，即使對(duì)于Oracle RAC集群往往也是最多擴(kuò)展到單點(diǎn)的2到3倍性能。對(duì)于應(yīng)用集群往往可以做到彈性水平擴(kuò)展，當(dāng)前技術(shù)也比較成熟。

當(dāng)中間件能夠做到完全彈性擴(kuò)展的時(shí)候，實(shí)際上仍然可能存在性能問題，即隨著我們系統(tǒng)的運(yùn)行和業(yè)務(wù)數(shù)據(jù)量的不斷積累增值。實(shí)際上你可以看到往往非并發(fā)狀態(tài)下的單用戶訪問本身就很慢，而不是說并發(fā)上來后滿。因此也是我們常說的要給點(diǎn)，即：

單點(diǎn)訪問性能正常的時(shí)候可以擴(kuò)展集群來應(yīng)對(duì)大并發(fā)狀態(tài)下的同時(shí)訪問

單點(diǎn)訪問本身性能就有問題的時(shí)候，要優(yōu)先優(yōu)化單節(jié)點(diǎn)訪問性能

業(yè)務(wù)系統(tǒng)性能診斷的分類

對(duì)于業(yè)務(wù)系統(tǒng)性能診斷，如果從靜態(tài)角度我們可以考慮從以下三個(gè)方面進(jìn)行分類

操作系統(tǒng)和存儲(chǔ)層面中間件層面（包括了數(shù)據(jù)庫(kù)，應(yīng)用服務(wù)器中間件）軟件層面（包括了數(shù)據(jù)庫(kù)SQL和存儲(chǔ)過程，邏輯層，前端展現(xiàn)層等）

那么一個(gè)業(yè)務(wù)系統(tǒng)應(yīng)用功能出現(xiàn)問題了，我們當(dāng)然也可以從動(dòng)態(tài)層面來看實(shí)際一個(gè)應(yīng)用請(qǐng)求從調(diào)用開始究竟經(jīng)過了哪些代碼和硬件基礎(chǔ)設(shè)施，通過分段方法來定位和查詢問題。

比如我們常見的就是一個(gè)查詢功能如果出現(xiàn)問題了，首先就是找到這個(gè)查詢功能對(duì)應(yīng)的SQL語(yǔ)句在后臺(tái)查詢是否很慢，如果這個(gè)SQL本身就慢，那么就要優(yōu)化優(yōu)化SQL語(yǔ)句。如果SQL本身快但是查詢慢，那就要看下是否是前端性能問題或者集群?jiǎn)栴}等。

軟件代碼的問題往往是最不能忽視的一個(gè)性能問題點(diǎn)

對(duì)于業(yè)務(wù)系統(tǒng)性能問題，我們經(jīng)常想到的就是要擴(kuò)展數(shù)據(jù)庫(kù)的硬件性能，比如擴(kuò)展CPU和內(nèi)存，擴(kuò)展集群，但是實(shí)際上可以看到很多應(yīng)用的性能問題并不是硬件性能導(dǎo)致的，而是由于軟件代碼性能引起的。對(duì)于軟件代碼常見的性能問題我在以往的博客文章里面也談過到，比較典型的包括了。

1. 循環(huán)中初始化大的結(jié)構(gòu)對(duì)象，數(shù)據(jù)庫(kù)連接等

2. 資源不釋放導(dǎo)致的內(nèi)存泄露等

3. 沒有基于場(chǎng)景需求來適度通過緩存等方式提升性能

4. 長(zhǎng)周期事務(wù)處理耗費(fèi)資源

5. 處理某一個(gè)業(yè)務(wù)場(chǎng)景或問題的時(shí)候，沒有選擇最優(yōu)的數(shù)據(jù)結(jié)構(gòu)或算法

以上都是常見的一些軟件代碼性能問題點(diǎn)，而這些往往需要通過我們進(jìn)行Code Review或代碼評(píng)審的方式才能夠發(fā)現(xiàn)出來。因此如果要做全面的性能優(yōu)化，對(duì)于軟件代碼的性能問題排查是必須的。

通過IT資源監(jiān)控或APM應(yīng)用工具來發(fā)現(xiàn)性能問題

對(duì)于性能問題的發(fā)現(xiàn)一般有兩條路徑，一個(gè)就是通過我們IT資源的監(jiān)控，APM的性能監(jiān)控和預(yù)警來提前發(fā)現(xiàn)性能問題，一個(gè)是通過業(yè)務(wù)用戶在使用過程中的反饋來發(fā)現(xiàn)性能問題。

而隨著DevOps和自動(dòng)化運(yùn)維的思路推進(jìn)，我們更加希望是通過APM等工具主動(dòng)監(jiān)控來發(fā)現(xiàn)性能問題，對(duì)于APM工具最大的好處就是可以進(jìn)行服務(wù)鏈間和全鏈路的性能分析，方便我們發(fā)現(xiàn)性能問題究竟發(fā)生在哪里。比如我們提交一個(gè)表單很慢，通過APM分析我們很容易發(fā)現(xiàn)究竟是調(diào)用哪個(gè)業(yè)務(wù)服務(wù)慢，或者是處理哪個(gè)SQL語(yǔ)句慢。這樣可以極大的提升我們性能問題分析診斷的效率。