最近遇到一個網際網路金融應用系統的效能問題，看了開發的優化方案，覺得還不夠深入。結合之前看到一些網際網路企業分享的方案，今天從運維角度整理一下比較理想的應用系統性能優化思路。

先列一個傳統應用架構的幾個組成部份：

上面的架構容易出現幾個常見問題：

1、應用內部服務APP的服務承載的交易服務過多，從交易看是緊耦合的；

2、源交易應用到目標應用之間經過匯流排、多個過程系統，最終才到目標系統，任一環節出問題都將影響這支交易的效能；

3、從應用來看，高併發的情況下前端容易出現併發數過高導致的異常，後端DB資料處理容易因前端過多交易導致的DB連線數超限；

4、關聯絡統，尤其是匯流排系統如採用同步方式容易導致匯流排系統癱瘓，最終導致影響企業其它應用系統;

所以，優化後的架構大致如下：

主要的幾點思路如下：

1、應用拆分：邏輯上分析業務主流程，將分支交易進行分離，按業務功能拆分獨立的服務；物理上將獨立的服務進行分離，獨立部署，出現問題後可以快速採取措施進行隔離或擴容。

2、服務或系統互動解耦：如WEB到邏輯服務前加佇列層，減少前端放開流量導致後端處理能力跟不上的問題；資料庫前加上快取層，減少資料庫的併發壓力。

3、減少匯流排節點服務的依賴：由多節點組成的邏輯互動改為端對端的訪問方式，一方面減少影響交易的因素，另一方面減少自身效能問題影響其它應用系統。

4、增加非同步訪問機制：同步的機制在效能出現問題時，會在短時間花完最大連線數，哪怕這個最大併發數是正常情況下的10倍。這方面可以直接改非同步通訊，也可以引入一些佇列工具實現。

5、多層次的快取：快取的引入可以多層次，從前端、應用內部、資料庫等，比如：前端頁面可以利用快取技術減少頁面重新整理，這方面可以採用網路工具解決；資料庫前可以採用REDIS等；應用自身同樣可以用快取代替資料庫的讀操作；

6、資料庫優化：1）架構上：拆庫、線上庫與歷史庫分離、分散式資料庫、讀寫分離、非關係型資料庫。比如：第1點應用拆分後，則可以按業務拆庫；分散式資料庫實現資料分片讀寫等等。2）編碼上：SQL優化、索引新增、資料定時清理，這個優化方式最快，最容易出效果；減少資料庫訪問次數、減少資料庫一次返回的結果集；

7、前端限流、削峰機制，前端系統因為邏輯簡單往往可以支援更多請求，但後端系統則不同。所以需要前端系統做交易併發控制，並通過一些前端互動設計減少客戶的本驗影響；

8、基礎設施支援快速擴容：支援彈性擴容（第1點系統拆分獨立部署很重要，可以減少擴容複雜性）。

9、服務降級：重要服務重點保障，次要服務有損保障，緊急情況下進行降級。

另外，做運維，當然要從運維角度進行一些輔助性工作，比如：

• 灰度釋出
• 效能監控、業務監控
• 效能基線的建立
• 效能分析，用資料分析抓典型的效能瓶徑並督促優化

最後，方案看起來挺美好，但放在實際的情況下，阻力可能很大，甚至根本沒法實施，因為這些思路對開發團隊依賴比較大。

但夢想還是要有，說不定哪天就實現了，比如，哪天開發團隊的老闆覺得效能和業務功能實現同等重要的時候。

作者：彭華盛

文章來自微信公眾號：運維之路