2016年初剛剛從CSC辭職回老部門沒多久，就聽說了部門里有個系統(tǒng)有些問題，最主要的就是反應(yīng)在系統(tǒng)性能上。然后沒多久，該系統(tǒng)的兩任Tech lead都跳槽了。再然后這個有問題的系統(tǒng)也劃到我名義下來兼管了。之后就經(jīng)歷了一段黑暗時期，每兩三天系統(tǒng)不是崩潰就是必須重新啟動，各種各樣的問題，三天兩頭數(shù)據(jù)庫鎖死，內(nèi)存溢出。最后，上頭終于同意撥了一筆專項基金用于該系統(tǒng)的優(yōu)化。如此，最重要的錢解決了，那么項目也就可以開始進(jìn)行了。

為了便于理解，系統(tǒng)的結(jié)構(gòu)還是需要略微簡單的介紹一下的。
1. IBM Webseal 負(fù)責(zé)負(fù)載均衡兩條不同數(shù)據(jù)中心的服務(wù)器和粘性會話。
2. IBM WebSphere Application Server: 部署在不同的數(shù)據(jù)中心，每個數(shù)據(jù)中心有兩個邏輯服務(wù)器，一個負(fù)責(zé)邏輯顯示層，一個負(fù)責(zé)業(yè)務(wù)邏輯層。然后每一個邏輯服務(wù)器下面有兩個實例。 這樣總共構(gòu)成了兩條線的邏輯服務(wù)器，每條線有4個實例。
3. IBM DB2 作為數(shù)據(jù)庫。
4. 整個程序是建立在Java EE上面的。界面是用部門內(nèi)部開發(fā)的WComponent(在GitHub上可以找到)來做的。邏輯層混合了Spring + EJB + MDB，持久層使用的是Hibernate+ 動態(tài)SQL +數(shù)據(jù)庫觸發(fā)器。

當(dāng)閱讀了系統(tǒng)的框架文檔后，并且做了系統(tǒng)的壓力測試后，發(fā)現(xiàn)有五個方面存在一些性能上的問題。
1. 系統(tǒng)結(jié)構(gòu)
2. 數(shù)據(jù)庫
3. 中間件設(shè)置
4. 系統(tǒng)程序
5. 業(yè)務(wù)要求的不合理性

基本上這個列表里面幾乎包括了這個系統(tǒng)的所有的東西。這里我來簡單介紹一下某些特定的問題和一些解決方案：

1. 系統(tǒng)結(jié)構(gòu)

大概有8個外部系統(tǒng)與這個有問題的系統(tǒng)通過企業(yè)服務(wù)總線(Enterprise Service Bus or ESB)用JMS進(jìn)行數(shù)據(jù)交換。JMS是以soap信息標(biāo)準(zhǔn)來實現(xiàn)的。其中有兩個系統(tǒng)是整個部門的核心系統(tǒng)。系統(tǒng)A是一個IBM主機(jī)系統(tǒng)，已經(jīng)有不少的年頭了。系統(tǒng)A通過三種方式來傳輸JMS數(shù)據(jù)給問題系統(tǒng)：程序本身，服務(wù)轉(zhuǎn)換，以及數(shù)據(jù)庫觸發(fā)器。系統(tǒng)A大概每秒鐘傳輸25條JMS到問題系統(tǒng)。系統(tǒng)B是一個客戶記錄系統(tǒng), 大概每秒鐘產(chǎn)生15條JMS傳輸?shù)絾栴}系統(tǒng)。通過數(shù)據(jù)分析發(fā)現(xiàn)以下問題：

·        由于系統(tǒng)A/B的設(shè)計問題，大量重復(fù)JMS被發(fā)送到問題系統(tǒng)進(jìn)行處理。

·        由于設(shè)計原因，系統(tǒng)A/B更新一條主記錄會產(chǎn)生多個JMS對應(yīng)同一條主記錄下面的多個子記錄，并且?guī)缀踉谕粫r間發(fā)送出去。由于這些JMS屬于同一個主記錄（KEY），當(dāng)問題系統(tǒng)多個實例下的MDB接受到JMS，需要更新數(shù)據(jù)的時候經(jīng)常會遇到該條數(shù)據(jù)被鎖死的情況。導(dǎo)致后面的JMS必須等數(shù)據(jù)庫更新完成后才能繼續(xù)處理。

由于修改系統(tǒng)A/B的可能性微乎其微(從系統(tǒng)復(fù)雜系，改動費(fèi)用，以及修改系統(tǒng)A/B對其他系統(tǒng)的影響)。第一個問題我們從ESB入手，通過數(shù)據(jù)分析，將重復(fù)的信息直接在ESB就過濾掉了。第二個問題的解決方案是通過兩個步驟修改問題系統(tǒng)。第一步，根據(jù)主鍵值將JMS分配到特定的節(jié)點，保證同一主鍵值的JMS被同一個WebSphere服務(wù)器的同一個節(jié)點處理。第二步，將即時處理系統(tǒng)改成為批處理系統(tǒng)，批處理的間隔時間根據(jù)需求設(shè)置的比較短一點。綜合第一步和第二部，一方面減少了大量的數(shù)據(jù)庫讀寫操作，另一方面也可以保證收到的JMS可以根據(jù)生成的時間順序來進(jìn)行處理。而且，數(shù)據(jù)庫數(shù)據(jù)被鎖死的情況也不會再發(fā)生了。

2. 數(shù)據(jù)庫

對于數(shù)據(jù)庫優(yōu)化我想有一定經(jīng)驗的開發(fā)人員都會有一點了解了，這里我們就不講那些最基本的東西了。當(dāng)然有一些比較復(fù)雜優(yōu)化方案也只有專業(yè)的DBA能夠全面的了解，而我有幸的遇到了一個非常不錯的DBA。問題系統(tǒng)有很多系統(tǒng)生成的SQL以及開發(fā)人員特意撰寫的SQL，我們這里來分類說一下。

·        儲存框架。問題系統(tǒng)使用hibernate作為儲存框架。在某一個hibernate mapping中使用了union-subclass 的策略，也就是對于每個具體類，產(chǎn)生一個表。本身這個策略是沒有什么問題的，可是當(dāng)用到特定的情況下，問題就來了。第一，繼承的具體類別比較多。第二，當(dāng)每個具體類有幾百萬條記錄時，因為自動生成的SQL會使用 A union B union C union D … 導(dǎo)致整個系統(tǒng)的讀取變得奇慢無比。在項目剛剛開始的時候因為繼承具體類比較少，而且數(shù)據(jù)庫記錄也比較少，在兩三個具體類，每個類上萬條至上幾十萬條數(shù)據(jù)的時候系統(tǒng)性能沒有什么影響。但是隨著具體類的增加，數(shù)據(jù)記錄的增加，問題系統(tǒng)的性能慢慢的出現(xiàn)了問題。為了盡量減少系統(tǒng)數(shù)據(jù)庫的改變，最后使用了joined-subclass來解決了這性能問題。通過使用Joined-subclass，生成的SQL采用了join而不是union，運(yùn)行效率大大提高。(圖中B在優(yōu)化的時候被取消了，因為B的定義不明確，而A可以直接作為B1/B2/B3的超類。)

·        SQL優(yōu)化。SQL優(yōu)化可以完全寫一本書了，在這里我只是略微帶一下了。基本上來說，問題系統(tǒng)的很多SQL沒有考慮到整個表掃描的耗費(fèi)。原先數(shù)據(jù)表上萬上十萬的數(shù)據(jù)全表掃描可能沒有什么感覺，但是當(dāng)數(shù)據(jù)表有了幾百萬甚至上千萬條記錄時，一定要避免全表掃描。我們做了一些統(tǒng)計，特別是當(dāng)有很多數(shù)據(jù)的幾個表結(jié)合在一起的時候，當(dāng)有全表掃描的時候，同樣效果的SQL運(yùn)行速度要比不需要掃描的SQL慢成百上千倍。另外，另外一個經(jīng)驗教訓(xùn)就是千萬不要將太多的商業(yè)邏輯封裝到SQL里面，而問題系統(tǒng)正式犯了這一個錯誤。問題系統(tǒng)有些動態(tài)生成的SQL近四五百行，復(fù)雜程度極高，導(dǎo)致幾乎整個開發(fā)小組沒有人愿意優(yōu)化這些SQL。這時候幸好我前面所提的DBA給了整個開發(fā)小組極大的幫助。

3. 中間件設(shè)置

問題系統(tǒng)使用IBM WebSphere Application Server8.5作為中間件。在問題系統(tǒng)長時間運(yùn)行之后，我們發(fā)現(xiàn)數(shù)據(jù)庫連接雖然回到了數(shù)據(jù)庫連接池，但是當(dāng)系統(tǒng)嘗試獲得一個數(shù)據(jù)庫鏈接的時候，WAS并沒有可用的數(shù)據(jù)庫鏈接提供給系統(tǒng)。剛開始的時候開發(fā)小組以為在系統(tǒng)的某處可能存在異常處理不到位導(dǎo)致數(shù)據(jù)庫連接沒有回到連接池。開發(fā)組用了很長的時間做了系統(tǒng)源代碼分析，可是沒有發(fā)現(xiàn)任何可疑的異常處理而導(dǎo)致數(shù)據(jù)庫連接丟失。最后通過WAS的數(shù)據(jù)庫分析模塊發(fā)現(xiàn)數(shù)據(jù)庫連接是被返回到連接池中了，但是該連接處于不可用狀態(tài)。最后發(fā)現(xiàn)罪魁禍?zhǔn)资荳AS的StaleConnectionException。而在WAS的數(shù)據(jù)庫設(shè)置里面，系統(tǒng)管理員將數(shù)據(jù)庫連接池清除政策設(shè)置成FailingConnectionOnly，而不是整個連接池。最后通過將連接池清除策略設(shè)置為整個池后，我們解決了這個問題。

4. 系統(tǒng)程序

問題系統(tǒng)本身有一個批處理功能用來處理大量數(shù)據(jù)，這個批處理功能在一個全局事務(wù)(Global transaction)下面。這個全局事務(wù)時間已經(jīng)從默認(rèn)的120秒提升到了300秒，但是有時還是有超時現(xiàn)象發(fā)生。等仔細(xì)研究了系統(tǒng)程序以后，發(fā)現(xiàn)這個批處理功能在某一時間只在某一節(jié)點上運(yùn)行，而其他另外三個節(jié)點是空閑的。通過修改系統(tǒng)程序，把這個批處理功能所需要處理的數(shù)據(jù)均勻分布到四個節(jié)點上同時進(jìn)行操作后，該批處理功能速度提升近四倍。

5. 業(yè)務(wù)要求的不合理性

問題系統(tǒng)有一個最嚴(yán)重的問題就是應(yīng)許終端用戶建立自己的批處理命令，并且應(yīng)許終端用戶設(shè)置自己想要運(yùn)行該批處理命令的時間。通過數(shù)據(jù)分析發(fā)現(xiàn)，兩年半之內(nèi)終端用戶總共建立了7000多個批處理命令，而大概有3000多個都是設(shè)置運(yùn)行在早上7：00點。然后大概有2000多個是在凌晨0：00，剩下的2000個左右的批處理命令比較均勻的分布在其他不同的22個時段。當(dāng)技術(shù)小組查看當(dāng)年的用戶需求文檔的時候，有一條用戶需求就是“用戶可以自己設(shè)置批處理命令的運(yùn)行時間”。這個用戶要求本身沒有什么問題如果這個是一個個人使用的單機(jī)系統(tǒng)，但是當(dāng)作為一個多用戶系統(tǒng)，系統(tǒng)的資源是共享的，這條業(yè)務(wù)需要本身需要一個約束。通過與用戶代表的溝通，最后根據(jù)系統(tǒng)性能，這個約束條件被加入了開發(fā)文檔，限定了在每個時段最多有1000個批處理命令。總共全天可以有24000個批處理命令可以執(zhí)行。

總結(jié)

當(dāng)我們做系統(tǒng)優(yōu)化的時候，我們不能只考慮到系統(tǒng)本身，必須從多方面，多角度來看。當(dāng)我們通過壓力測試知道了某一個系統(tǒng)瓶頸時候，我們必須分析這個瓶頸是如何造成的。有很多時候這個系統(tǒng)瓶頸并不是由于系統(tǒng)自身導(dǎo)致的，而是由于不合理/不清楚的需求，或者系統(tǒng)交互的設(shè)計問題，系統(tǒng)集成的架構(gòu)問題導(dǎo)致的。沒有從這些方面著手，系統(tǒng)內(nèi)部再怎么優(yōu)化也是有局限性的。

另外一點，在優(yōu)化系統(tǒng)的過程中，開發(fā)人員往往會發(fā)現(xiàn)當(dāng)一個瓶頸被優(yōu)化好了以后，另一個瓶頸又出現(xiàn)了。這是很正常的一個過程。優(yōu)化系統(tǒng)就像是一段旅程，每旅游完一個景點后就會有下一個景點在前面等著你。何時這段旅程能夠完成就看優(yōu)化后的系統(tǒng)是否達(dá)到了非功能性要求的標(biāo)準(zhǔn)。

作者華杰， 從事IT工作15年，做過程序員，首席軟件工程師，架構(gòu)師，IT技術(shù)顧問，現(xiàn)為澳大利亞移民和邊境保護(hù)局Tech lead.
LinkedIn：http://au.linkedin.com/in/jie-hua-01021118
個人電子郵件：jhua04@outlook.com