很多時候我們為了節省開支，會在ECS自建Mysql資料庫或者採用第三方一鍵環境來執行WP資料庫，雖然有時會出現訪問延遲等問題，但總體而言還是挺合適的一種方式。只不過並不是每個朋友都具備處理突發問題的能力，一旦在一個相對重要的時刻出現了宕機等難題，抓狂可能是很多人能做也是唯一能做的事情。因此，從成本和運營效率上考慮，推薦大家藉助RDS來執行站點資料庫。

從系統架構本身來說，一般系統最佳化主要從三個方面入手，資料持久層、業務邏輯層和前端展示層。

限制系統性能主要有兩個方面，一是資料庫自身的效能，二是對資料庫操作的方式，資料庫自身相對簡單，一般透過最佳化配置、採用高可用方案、搭建叢集或者使用效能更好的資料庫來提升效能；資料庫操作主要是資料庫讀寫操作，可以透過SQL最佳化的方式來提升讀寫速度，或者透過快取的方式減低併發、提升效能。

程式碼層面常見的問題有記憶體洩露、資源洩露、執行緒死鎖等，主要透過最佳化相關的程式碼和演算法來提升效能，使用資料庫連線、檔案讀取時及時關閉IO流，注意執行緒死鎖，以及靜態物件的使用等，降低JVM的記憶體消耗，使用高效能的框架、演算法，從程式碼層面提升系統性能。

前端主要考慮從程式碼和資源角度進行最佳化，如最佳化、壓縮JS程式碼，最佳化頁面渲染效果，減低渲染頻率，使用非同步載入資料，採用快取減少伺服器的訪問以及靜態資源的訪問。

對於業務系統的效能最佳化，我原來系統的談過分析和診斷的思路，今天再談下業務系統性能最佳化裡面我們常見的一些思考和分析系統性能問題的方法。

有時候大家可能覺得奇怪，為何我們系統再上線前都做了效能測試，為何上線後還是會出現系統性能問題。那麼我們可以考慮下實際上我們上線前效能測試可能存在的一些無法真實模擬生產環境的地方，具體為：

1. 硬體能否完全模擬真實環境？最好的效能測試往往是直接在搭建完成的生產環境進行。

2. 資料量能否模擬實際場景？真實場景往往是多個業務表都已經存在大資料量的積累而非空表。

3. 併發能否模擬真實場景？一個是併發需要錄製複合業務場景，一個是併發量大時候需要多臺壓測機。

而實際上我們在做效能測試的時候以上幾個點都很難真正做到，因此要想完全模擬出生產真實環境是相當困難的，這也導致了很多效能問題是在真正上線後才發現。

第二個點也是我們經常談的比較多的點，就是我們的業務系統在進行架構設計的時候，特別是面對非功能性需求，我們都會談到系統本身的資料庫，中介軟體都採用了叢集技術，能夠做到彈性水平擴充套件。那麼這種彈性水平擴充套件能力是否又真正解決了效能問題？

實際上我們看到對於資料庫往往很難真正做到無限的彈性水平擴充套件，即使對於Oracle RAC叢集往往也是最多擴充套件到單點的2到3倍效能。對於應用叢集往往可以做到彈性水平擴充套件，當前技術也比較成熟。

當中間件能夠做到完全彈性擴充套件的時候，實際上仍然可能存在效能問題，即隨著我們系統的執行和業務資料量的不斷積累增值。實際上你可以看到往往非併發狀態下的單使用者訪問本身就很慢，而不是說併發上來後滿。因此也是我們常說的要給點，即：

單點訪問效能正常的時候可以擴充套件叢集來應對大併發狀態下的同時訪問

單點訪問本身效能就有問題的時候，要優先最佳化單節點訪問效能

業務系統性能診斷的分類

對於業務系統性能診斷，如果從靜態角度我們可以考慮從以下三個方面進行分類

那麼一個業務系統應用功能出現問題了，我們當然也可以從動態層面來看實際一個應用請求從呼叫開始究竟經過了哪些程式碼和硬體基礎設施，透過分段方法來定位和查詢問題。

比如我們常見的就是一個查詢功能如果出現問題了，首先就是找到這個查詢功能對應的SQL語句在後臺查詢是否很慢，如果這個SQL本身就慢，那麼就要最佳化最佳化SQL語句。如果SQL本身快但是查詢慢，那就要看下是否是前端效能問題或者叢集問題等。

對於業務系統性能問題，我們經常想到的就是要擴充套件資料庫的硬體效能，比如擴充套件CPU和記憶體，擴充套件叢集，但是實際上可以看到很多應用的效能問題並不是硬體效能導致的，而是由於軟體程式碼效能引起的。對於軟體程式碼常見的效能問題我在以往的部落格文章裡面也談過到，比較典型的包括了。

1. 迴圈中初始化大的結構物件，資料庫連線等

2. 資源不釋放導致的記憶體洩露等

3. 沒有基於場景需求來適度透過快取等方式提升效能

4. 長週期事務處理耗費資源

5. 處理某一個業務場景或問題的時候，沒有選擇最優的資料結構或演算法

以上都是常見的一些軟體程式碼效能問題點，而這些往往需要透過我們進行Code Review或程式碼評審的方式才能夠發現出來。因此如果要做全面的效能最佳化，對於軟體程式碼的效能問題排查是必須的。

對於效能問題的發現一般有兩條路徑，一個就是透過我們IT資源的監控，APM的效能監控和預警來提前發現效能問題，一個是透過業務使用者在使用過程中的反饋來發現效能問題。

而隨著DevOps和自動化運維的思路推進，我們更加希望是透過APM等工具主動監控來發現效能問題，對於APM工具最大的好處就是可以進行服務鏈間和全鏈路的效能分析，方便我們發現效能問題究竟發生在哪裡。比如我們提交一個表單很慢，透過APM分析我們很容易發現究竟是呼叫哪個業務服務慢，或者是處理哪個SQL語句慢。這樣可以極大的提升我們效能問題分析診斷的效率。