一、應用服務效能最佳化

(1) 最佳化應用服務框架，對程式碼進行重構，最佳化SQL；

對專案中關鍵的介面，訪問頁面等進行效能壓測，抓取資料庫AWR效能分析報告;透過分析報告，找出消耗時間比較長的SQL，並對其進行最佳化；如果資料庫服務購買的是雲伺服器，對應雲伺服器廠商都有伺服器後臺，可以檢視慢SQL的執行情況。

AWR分析報告

AWR分析報告

在應用框升級改造的同時，也應充分考慮該架構的安全性，包括B/S形式的安全，主要體現在應用資料和使用者會話的安全，還應當考慮系統自身體系架構內部的安全，以及與外系統介面的安全。針對某些特殊應用，還需考慮恢復、抗攻擊等安全機制。

業務安全：主要是指業務系統的自身業務流程和資料的安全，其中包括：身份一致性、業務資料篡改和關鍵流程繞過等；應用安全：主要指應用系統非功能性需求的資訊保安，主要包括：SQL注入、XSS攻擊、框架注入等安全防護；中介軟體安全：主要是指採用的第三方開源或非開源的元件服務，比如，tomcat服務、訊息中介軟體、mysql、structs2.0元件等；主機安全：主機是指系統所執行的伺服器的安全防護，包括：伺服器的弱口令、口令的強度策略、作業系統特權、惡意程式碼或病毒的檢測等；資料安全：主要指HTTP業務資料、資料庫資料、資原始檔等資訊的安全防護，包括資訊的脫敏、資訊的加密、檔案的下載限制等；網路安全：主要是指系統所在網路安全監控、流量預警、防火牆規則設定、源IP地址請求限制等防護，能夠抵禦埠掃描、強力攻擊、木馬後門攻擊、拒絕服務攻擊、緩衝區溢位攻擊、IP碎片攻擊和網路蠕蟲攻擊。

(2) 增加資料一、二級快取，減輕資料庫壓力

增加資料一、二級快取，減輕資料庫壓力，包括應用快取，網路快取；比如使用Redis快取叢集服務；

使用redis資料快取，相信很多開發人員比較熟悉，很多的開源專案也都會整合redis服務，那麼使用redis到底有什麼好處呢？

讀寫速度快，這也是他最大的優勢了，redis把資料儲存在記憶體中，不需要直接請求資料庫；支援的資料型別資源豐富，可以支援支援HashMap、string，list等等；支援事務，操作都是原子性操作。即對資料的更改要麼全部執行，要麼全部不執行；可以自定義設定快取的生命週期，設定過期時間，過期後將會自動刪除，不影響更新資料的快取。

(3) 調整應用服務部署架構，增加服務的負載能力

若應用服務是單應用節點部署方式，可以擴充套件服務部署節點數和物理伺服器數，防止單點故障；除此之外，也可把應用服務中高併發的讀寫服務分離，一個服務只負責讀，另外一個服務只負責寫。透過代理服務，對多個物理服務進行負載均衡，設定策略，應用服務會優先訪問優先順序比較高的服務節點。

服務部署示意圖

(4) 升級系統框架，提高系統可拓展性

升級系統框架，提高系統可拓展性，使系統可以滿足對接更多的中介軟體和第三方支援等。比如使用RabbitMQ訊息佇列主要有以下優勢：

非同步解耦：訊息佇列 AMQP可用於單體應用被拆解為微服務後不同微服務間的通訊。應用解耦的好處是不同應用的迭代不再相互依賴，而非同步通訊的好處是資料不再需要被立即處理。非同步解耦能有效縮短資料鏈路長度，提高資料處理效率；削峰填谷：大型活動帶來較高流量脈衝時，沒有做好相應保護容易導致系統超負荷甚至崩潰，限制太過則會導致請求大量失敗而影響使用者體驗。訊息佇列 AMQP 版能做到削峰填。其超高效能的訊息處理能力可以承接流量脈衝而不被擊垮，在確保系統可用性同時，因快速有效的請求響應而提升使用者的體驗。其海量訊息堆積能力確保下游業務在安全水位內平滑穩定的執行，避免超高流量的衝擊;分散式快取同步：大量併發訪問資料庫會導致頁面響應時間長。透過訊息佇列 AMQP 版構建分散式快取，能實時通知資料變化，有效降低頁面響應時間，滿足對變更的大量訪問需求；

(5) 資源效能最佳化

使用更少的HTTP請求：每個HTTP請求都需要經歷以下過程:阻擋->建立連線->傳送請求->等待響應->接收資料；請求的HTTP請求越少，建立連線的過程也就越少；資源壓縮合並：對檔案大小比較大的圖片、JS、CSS等資源進行壓縮或者合併；新增過期頭：瀏覽器每次請求資源前檢查透過max-age、expires檢查本地資源是否可用，如果可用將不發起請求到伺服器，以此節約伺服器資源，加快網頁載入速度；使用雲上檔案儲存服務：檔案資源可以上傳到阿里雲OSS或者華為雲OBS等檔案儲存服務，達到可以對資源服務進行CDN加速，提高資源的訪問速度

二、資料庫效能最佳化

(1) 冗餘表字段、減少表關聯操作

我們在初始資料庫表結構的建模設計時，可能諸多世界無法考慮周全，導致部分欄位定義過大，表結構定義的欄位與實際使用佔用大小相差較大。或者部分表的冗餘欄位過多，甚至有一部分的冗餘欄位始終為空。針對這樣的問題，小編建議應當實際情況定義各欄位大小，並縮小冗餘欄位大小。選擇合理的大小可以大大減小磁碟空間及磁碟I/O讀寫開銷，減小記憶體佔用，減小CPU的佔用率。

(2) 索引建立

大家有沒有遇到以下一些問題呢？

根據實際生產的增刪改查語句進行分析，建立索引；同一個表的同一欄位已設定成主鍵，無須再建立唯一索引；聯合索引需要根據SQL語句所需進行建立，無須太多，容易造成解析計劃混亂；建議部分語句中增加強制索引

(3) 根據業務場景區分讀寫操作，訪問讀寫資料庫；

資料庫讀寫分離有一個前提就是，資料庫有多個備份，有主庫，有從庫。讀寫分離就是基於主從複製架構，一個主庫，有多個從庫，主庫主要負責寫，寫完後主庫會自動把資料同步給從庫，從庫執行查詢的一些操作

(4) 根據查詢條件對大資料表進行分庫分割槽等；

分庫又叫垂直切分，就是把原本儲存於一個庫的表拆分儲存到多個庫上，通常是將表按照功能模組、關係密切程度劃分出來，部署到不同的庫上。如果資料庫是因為表太多而造成海量資料，並且專案的各項業務邏輯劃分清晰、低耦合，那麼規則簡單明瞭、容易實施的首選就是分庫。分庫的優點是：實現簡單，庫與庫之間界限分明，便於維護，缺點是不利於頻繁跨庫操作，單表資料量大的問題解決不了；

顧名思義，分割槽就是將一個表分解成多個區塊進行操作和儲存，從而降低每次操作的資料，提高效能。而對應用來說是透明的，從邏輯上看是隻有一個表，但在物理上這個表可能是由多個物理分割槽組成的，每個分割槽都是一個獨立的物件，可以進行獨立處理。

(5) 調整資料連線池配置

系統需要滿足不同的併發數，專案中需要配置資料庫連線池的大小，可根據併發來設定連線池的各項引數。以MYSQL為例，可以從以下幾個引數進行最佳化設定：

連線池支援的最大連線數maxActive，併發100的時候該值就可以設定為100；連線池中最多可空閒連線數maxIdle，該值表示即使沒有資料庫連線時依然可以保持空閒的連線數，而不被清除；連線池中最小空閒連線數minIdle，當連線數少於此值時，連線池會建立連線來補充到該值的數量；初始化連線數目initialSize；最大請求等待時間maxWait，連線池中連線用完時,新的請求等待時間。

以上介紹的就是效能最佳化的一些知識，希望給大家在以後的專案最佳化中有一些幫助，如果還有其他比較好的建議，也可以給小編留言哦。