系統優化實例一則
2016年初剛剛從CSC辭職回老部門沒多久，就聽說了部門里有個系統有些問題，最主要的就是反應在系統性能上。然后沒多久，該系統的兩任Tech lead都跳槽了。再然后這個有問題的系統也劃到我名義下來兼管了。之后就經歷了一段黑暗時期，每兩三天系統不是崩潰就是必須重新啟動，各種各樣的問題，三天兩頭數據庫鎖死，內存溢出。最后，上頭終于同意撥了一筆專項基金用于該系統的優化。如此，最重要的錢解決了，那么項目也就可以開始進行了。
為了便于理解，系統的結構還是需要略微簡單的介紹一下的。
1. IBM Webseal 負責負載均衡兩條不同數據中心的服務器和粘性會話。
2. IBM WebSphere Application Server: 部署在不同的數據中心，每個數據中心有兩個邏輯服務器，一個負責邏輯顯示層，一個負責業務邏輯層。然后每一個邏輯服務器下面有兩個實例。 這樣總共構成了兩條線的邏輯服務器，每條線有4個實例。
3. IBM DB2 作為數據庫。
4. 整個程序是建立在Java EE上面的。界面是用部門內部開發的WComponent(在GitHub上可以找到)來做的。邏輯層混合了Spring + EJB + MDB，持久層使用的是Hibernate+ 動態SQL +數據庫觸發器。
當閱讀了系統的框架文檔后，并且做了系統的壓力測試后，發現有五個方面存在一些性能上的問題。
1. 系統結構
2. 數據庫
3. 中間件設置
4. 系統程序
5. 業務要求的不合理性
基本上這個列表里面幾乎包括了這個系統的所有的東西。這里我來簡單介紹一下某些特定的問題和一些解決方案：
1. 系統結構
大概有8個外部系統與這個有問題的系統通過企業服務總線(Enterprise Service Bus or ESB)用JMS進行數據交換。JMS是以soap信息標準來實現的。其中有兩個系統是整個部門的核心系統。系統A是一個IBM主機系統，已經有不少的年頭了。系統A通過三種方式來傳輸JMS數據給問題系統：程序本身，服務轉換，以及數據庫觸發器。系統A大概每秒鐘傳輸25條JMS到問題系統。系統B是一個客戶記錄系統, 大概每秒鐘產生15條JMS傳輸到問題系統。通過數據分析發現以下問題：
· 由于系統A/B的設計問題，大量重復JMS被發送到問題系統進行處理。
· 由于設計原因，系統A/B更新一條主記錄會產生多個JMS對應同一條主記錄下面的多個子記錄，并且幾乎在同一時間發送出去。由于這些JMS屬于同一個主記錄（KEY），當問題系統多個實例下的MDB接受到JMS，需要更新數據的時候經常會遇到該條數據被鎖死的情況。導致后面的JMS必須等數據庫更新完成后才能繼續處理。
由于修改系統A/B的可能性微乎其微(從系統復雜系，改動費用，以及修改系統A/B對其他系統的影響)。第一個問題我們從ESB入手，通過數據分析，將重復的信息直接在ESB就過濾掉了。第二個問題的解決方案是通過兩個步驟修改問題系統。第一步，根據主鍵值將JMS分配到特定的節點，保證同一主鍵值的JMS被同一個WebSphere服務器的同一個節點處理。第二步，將即時處理系統改成為批處理系統，批處理的間隔時間根據需求設置的比較短一點。綜合第一步和第二部，一方面減少了大量的數據庫讀寫操作，另一方面也可以保證收到的JMS可以根據生成的時間順序來進行處理。而且，數據庫數據被鎖死的情況也不會再發生了。
2. 數據庫
對于數據庫優化我想有一定經驗的開發人員都會有一點了解了，這里我們就不講那些最基本的東西了。當然有一些比較復雜優化方案也只有專業的DBA能夠全面的了解，而我有幸的遇到了一個非常不錯的DBA。問題系統有很多系統生成的SQL以及開發人員特意撰寫的SQL，我們這里來分類說一下。
· 儲存框架。問題系統使用hibernate作為儲存框架。在某一個hibernate mapping中使用了union-subclass 的策略，也就是對于每個具體類，產生一個表。本身這個策略是沒有什么問題的，可是當用到特定的情況下，問題就來了。第一，繼承的具體類別比較多。第二，當每個具體類有幾百萬條記錄時，因為自動生成的SQL會使用 A union B union C union D … 導致整個系統的讀取變得奇慢無比。在項目剛剛開始的時候因為繼承具體類比較少，而且數據庫記錄也比較少，在兩三個具體類，每個類上萬條至上幾十萬條數據的時候系統性能沒有什么影響。但是隨著具體類的增加，數據記錄的增加，問題系統的性能慢慢的出現了問題。為了盡量減少系統數據庫的改變，最后使用了joined-subclass來解決了這性能問題。通過使用Joined-subclass，生成的SQL采用了join而不是union，運行效率大大提高。(圖中B在優化的時候被取消了，因為B的定義不明確，而A可以直接作為B1/B2/B3的超類。)
· SQL優化。SQL優化可以完全寫一本書了，在這里我只是略微帶一下了。基本上來說，問題系統的很多SQL沒有考慮到整個表掃描的耗費。原先數據表上萬上十萬的數據全表掃描可能沒有什么感覺，但是當數據表有了幾百萬甚至上千萬條記錄時，一定要避免全表掃描。我們做了一些統計，特別是當有很多數據的幾個表結合在一起的時候，當有全表掃描的時候，同樣效果的SQL運行速度要比不需要掃描的SQL慢成百上千倍。另外，另外一個經驗教訓就是千萬不要將太多的商業邏輯封裝到SQL里面，而問題系統正式犯了這一個錯誤。問題系統有些動態生成的SQL近四五百行，復雜程度極高，導致幾乎整個開發小組沒有人愿意優化這些SQL。這時候幸好我前面所提的DBA給了整個開發小組極大的幫助。
3. 中間件設置
問題系統使用IBM WebSphere Application Server8.5作為中間件。在問題系統長時間運行之后，我們發現數據庫連接雖然回到了數據庫連接池，但是當系統嘗試獲得一個數據庫鏈接的時候，WAS并沒有可用的數據庫鏈接提供給系統。剛開始的時候開發小組以為在系統的某處可能存在異常處理不到位導致數據庫連接沒有回到連接池。開發組用了很長的時間做了系統源代碼分析，可是沒有發現任何可疑的異常處理而導致數據庫連接丟失。最后通過WAS的數據庫分析模塊發現數據庫連接是被返回到連接池中了，但是該連接處于不可用狀態。最后發現罪魁禍首是WAS的StaleConnectionException。而在WAS的數據庫設置里面，系統管理員將數據庫連接池清除政策設置成FailingConnectionOnly，而不是整個連接池。最后通過將連接池清除策略設置為整個池后，我們解決了這個問題。
4. 系統程序
問題系統本身有一個批處理功能用來處理大量數據，這個批處理功能在一個全局事務(Global transaction)下面。這個全局事務時間已經從默認的120秒提升到了300秒，但是有時還是有超時現象發生。等仔細研究了系統程序以后，發現這個批處理功能在某一時間只在某一節點上運行，而其他另外三個節點是空閑的。通過修改系統程序，把這個批處理功能所需要處理的數據均勻分布到四個節點上同時進行操作后，該批處理功能速度提升近四倍。
5. 業務要求的不合理性
問題系統有一個最嚴重的問題就是應許終端用戶建立自己的批處理命令，并且應許終端用戶設置自己想要運行該批處理命令的時間。通過數據分析發現，兩年半之內終端用戶總共建立了7000多個批處理命令，而大概有3000多個都是設置運行在早上7：00點。然后大概有2000多個是在凌晨0：00，剩下的2000個左右的批處理命令比較均勻的分布在其他不同的22個時段。當技術小組查看當年的用戶需求文檔的時候，有一條用戶需求就是“用戶可以自己設置批處理命令的運行時間”。這個用戶要求本身沒有什么問題如果這個是一個個人使用的單機系統，但是當作為一個多用戶系統，系統的資源是共享的，這條業務需要本身需要一個約束。通過與用戶代表的溝通，最后根據系統性能，這個約束條件被加入了開發文檔，限定了在每個時段最多有1000個批處理命令。總共全天可以有24000個批處理命令可以執行。
總結
當我們做系統優化的時候，我們不能只考慮到系統本身，必須從多方面，多角度來看。當我們通過壓力測試知道了某一個系統瓶頸時候，我們必須分析這個瓶頸是如何造成的。有很多時候這個系統瓶頸并不是由于系統自身導致的，而是由于不合理/不清楚的需求，或者系統交互的設計問題，系統集成的架構問題導致的。沒有從這些方面著手，系統內部再怎么優化也是有局限性的。
另外一點，在優化系統的過程中，開發人員往往會發現當一個瓶頸被優化好了以后，另一個瓶頸又出現了。這是很正常的一個過程。優化系統就像是一段旅程，每旅游完一個景點后就會有下一個景點在前面等著你。何時這段旅程能夠完成就看優化后的系統是否達到了非功能性要求的標準。
作者華杰， 從事IT工作15年，做過程序員，首席軟件工程師，架構師，IT技術顧問，現為澳大利亞移民和邊境保護局Tech lead.
LinkedIn：http://au.linkedin.com/in/jie-hua-01021118
個人電子郵件：jhua04@outlook.com
