孔慶龍，一線架構師，具有多年的金融架構經驗，具備 SOA 服務化、服務治理、系統優化、分布式系統項目經驗。目前關注于互聯網金融技術架構設計、分布式架構、微服務架構、DevOps 實踐、大數據等領域。

什么是系統優化

系統優化，一方面是系統化地對 IT 系統或交易鏈上的每個環節進行分析并優化，另一方面是對單一系統進行瓶頸點分析和優化。這兩方面的優化目標大致相同，無非是提高系統的響應速度、吞吐量、降低各層耦合，以靈活應對市場需要。系統優化主要在如下三個層面上進行。

系統優化的方法論、思路和原則

什么是方法論，我個人的理解就是聽起來很厲害，做過的人認為是廢話，但可以指明行動方向的理論。下面就根據多年經驗，從系統優化的常用方法論、優化思路和優化原則三方面進行簡單分享。

2.1

常用方法論

常用的方法論有以下幾條。

2.2

優化思路

根據以往經驗總結出系統優化的思路，大致如下:

(1)了解現狀，發現問題。

(2)確定清晰的優化目標，分析現狀與目標的差距并確定執行路線。

(3)對系統進行拆分，分別對邏輯層(Web 層、業務層、持久化層)和物理層(客戶端、網絡、應用服務器、數據庫服務器)進行優化。

(4)利用工具對系統進行監控和測試，并對監控和測試結果進行分析。

(5)科學地對系統進行優化。

遵循一定的程序: 監控/性能測試→分析瓶頸→羅列瓶頸的因素→驗證瓶頸因素 →修改系統→確認是否達到優化目標。

確定影響性能的因素: CPU、內存、I/O、網絡或其他因素。

找出主要的瓶頸，優先解決關鍵因素，再重復監控或測試驗證。

避免過度優化，一次修改一個瓶頸，不要對不需要的地方進行優化。

提高 CPU 性能: 寫出更快的代碼，設計出更好的算法，減少短期生存的對象。

提高內存性能: 減少長期生存的對象。

提高 I/O 性能: 重新設計應用，減少 I/O 的交互。

緩存為王: 適度緩存，做到最大化發揮數據庫緩存、應用端緩存、客戶端緩存的作用。

2.3

優化原則

系統優化的原則如下:

性能優化

3.1

常見的性能問題

常見的性能問題大多數是由于資源不足或熱點資源競爭導致的，下面將從客戶端性能、 J2EE 系統性能和數據庫性能三方面進行簡單介紹。

常見的客戶端性能問題

常見的客戶端性能問題有如下幾項。

常見的 J2EE 系統性能問題

常見的 J2EE 系統性能問題有如下幾項。

常見的數據庫問題

在以往做核心業務系統技術支持時，遇到的常見的數據庫問題如下所述。

3.2

性能優化的具體工作

“天下武功，唯快不破”，性能優化的首要工作就是提高系統的響應時間(響應時間 = 服務處理時間 + 排隊時間)。如圖 16.1 所示的經典響應時間曲線，我們要做的就是通過優化程序來減少服務時間，通過提高系統的吞吐量減少系統的排隊時間。圖 16.1 中的縱軸代表的是響應時間，即服務時間和排隊時間的總和; 橫軸代表的是到達率。隨著每單位時間進入系統的事務數的增加，曲線逐漸向右滑動。隨著到達率的增加，排隊時間會在某一時刻陡然上升，此時，響應時間也將陡然上升，性能下降，而用戶會感到非常沮喪。

圖 16.1

下面通過以往項目中的案例來分析性能優化的具體工作。

交易線優化

交易線用來從服務消費者的角度查看交易在各個層面上應該完成的功能，以及功能點之間的關系。功能點之間的關系用有向路徑來表示，如圖 16.2 所示。

圖 16.2

交易線優化的原則如下:

隨著架構的演變，現在已經由豎井式系統逐步發展為以服務為單元、可靈活構建的分布式服務體系，如圖 16.3 所示。在服務治理的過程中，原來的核心業務系統被打碎為各種獨立的業務組件，一些中間層平臺型系統基于這些業務組件和流程服務逐漸構建了業務服務，并為前端應用的快速構建提供業務支撐。在這個過程中，服務識別和構建是基礎，交易線的規范是保障，通過交易線規范可以確定服務治理的涉及范圍，因為在軟件版本迭代時，很少有人能把系統的全部細節都考慮清楚，所以要靠規范來確定治理范圍，而不是靠人。

圖 16.3

要開發一個訂單查詢功能 A，服務整合平臺的 B 和 C 兩個服務都可以完成此功能的開發，不同的是 B 在 C 的基礎上增加了一些額外的校驗。按照最短路徑原則，A 應該直接調 用 C 服務，如圖 16.4 所示。

圖 16.4

流量控制的目的之一是保證各系統健康穩定地運行。一般使用計數器按照交易類型來檢測交易的并發數，不同交易類型使用不同的計數器。當交易請求到達時，計數器加 1; 當請求響應失敗時，計數器減 1。

流量控制是對服務提供者的一種保護機制，那么服務消費者如何避免因為服務提供者不可用而導致自身不可用，并逐級向交易鏈的調用方放大這種不可用，最終拖垮整個交易鏈路導致雪崩的情況呢? 服務的消費方一般可以通過以下 3 種方式來防止“雪崩”，實現對交易鏈路的保護。

隔離機制:資源池隔離。如果將線程池、數據庫連接池等獨立分配，那么即使某類 服務出現問題也只會影響單獨的資源池。

客戶端優化

圖 16.5

從 Web 請求時序(如圖 16.5 所示)中可以看出，客戶端優化的首要目標是加快頁面展 現和響應速度，其次是減少對服務器端的調用，常見的解決辦法如下:

圖 16.6 所示的是某企業內部應用系統客戶端的 HTTP 請求監控記錄。

圖 16.6

從圖 16.6 中可以看到共計發送 25 次請求(21 次命中緩存、4 次與服務器端交互)。從 圖 16.7 所示的統計信息中可以看到: 請求耗時總計 5.645s，進行了 4 次網絡交互，接收到 5.9KB 數據，發送了 110.25KB 數據，使用 gzip 壓縮節省了 8KB 數據。

圖 16.7

通過優化后端請求、合并和壓縮 JS/JSP 文件等操作，將頁面響應時間優化到 2s 左右。

進行前端優化最好了解瀏覽器原理、HTTP 原理。

服務器端優化

服務器端的涉及面比較廣，圖 16.8 整理了在進行服務器端優化時可能存在的問題，以及所采用的輔助分析工具、分析思路、常見解決辦法。

圖 16.8

（未完待續）

本文節選自中生代技術社區叢書之《架構寶典》