【51CTO.com快譯】我們大家都時不時地犯錯誤……而且，有時我們會一次犯很多錯誤！Grzegorz Ziemonski以一種令人愉快的方式和坦誠的態(tài)度與我們一起回顧了他在一次關鍵性Java應用程序發(fā)行調試過程中一路走來所犯的錯誤。

來自于DZone團隊的Michael Tharrington最近向我建議，我應該寫一寫作為一個開發(fā)者我所犯過的一些錯誤和從中取得的教訓。好吧，現(xiàn)在做這件事實在是最恰當不過——我的團隊剛剛上線一款關鍵的應用程序，而一切可能出錯的地方都出現(xiàn)錯誤了！當然，并非下文提供的每一個解決方案都完全是由我編寫的——其中一些是我們在敏捷開發(fā)中結對編程時所產生的，而一切都通過一個嚴格的代碼審查過程——也正是這一點使得問題更加可笑。

問題產生的背景

[[173689]]

我們正在開發(fā)一款簡單的Web應用程序，此程序能夠暴露一個REST API以便與一個外部供應者程序進行通信并能夠把一些結果***地存儲起來；這樣的話，我們就不需要做太多的調用，因為我們不得不為每一次API調用付費。該應用程序主要依賴于Spring Boot這個Web框架及數(shù)據(jù)功能。該應用程序的兩個實例將部署在公司的支持負載平衡器的服務器上。

• 錯誤1—進程并發(fā)錯誤

對外部提供者程序的調用需要花費很長的時間；自然，我們的客戶端應用程序都不愿意等待這種類型的調用。正因為如此，我們都同意通過后臺處理方式加以改進——***次調用時，我們返回一條消息“DONT_KNOW_YET_COME_BACK_LATER...”。下次調用時，我們返回一個持久性的結果。于是，自然就出現(xiàn)這樣一個問題：如果我們在足夠短的時間內進行兩次相同的調用，那么會發(fā)生什么情況呢？靈感突然出現(xiàn)：我們必須以某種方式保護自己避免使用相同的數(shù)據(jù)兩次調用外部提供者程序。下面給出我的初步的編程方案：

private Set<Long> currentlyProcessedIds = ConcurrentHashMap.newKeySet(); 
 
// further down in the code: 
 
if (currentlyProcessedIds.add(id) {   
 
    doTheJob(id); 
 
    currentlyProcessedIds.remove(id); 
 
} 

你能找到這段代碼有什么毛病嗎？如果你馬上發(fā)現(xiàn)不了我的愚蠢錯誤，慢慢來就是。

當然，如果doTheJob部分拋出異常的話，整段程序會中斷！這是典型的進程并發(fā)錯誤，導致明顯的內存破壞！遺憾的是，四個人盯著這段代碼卻沒人注意到，其實我們可以阻止id再次被正確處理。下面是更正后的代碼的正確版本：

if (currentlyProcessedIds.add(id) {   
 
    try { 
 
        doTheJob(id); 
 
    } finally { 
 
        currentlyProcessedIds.remove(id); 
 
    } 
 
} 

• 錯誤2—負載已平衡，但問題仍存在

如果你足夠聰明，你可能已經注意到哪里出現(xiàn)錯誤了——上面的這段代碼仍然存在問題！我們在一臺負載平衡器上部署了應用程序的兩個獨立的實例。這意味著，問題并不只是并發(fā)方面的，還與分布式有關系！

目前，我們還沒有實現(xiàn)一個分布式的解決方案，但我們明顯需要實現(xiàn)兩個應用程序實例間對當前處理過的數(shù)據(jù)集進行同步。

• 錯誤3—喝早咖啡意外發(fā)現(xiàn)性能問題

[[173690]]

后臺處理的想法來自于我觀察舊式解決方案的結果。這種老式解決方案嚴重依賴于數(shù)據(jù)庫的性能，但即使在最糟糕的情況下，也比外部調用要快。一開始，我們建議負責客戶端應用程序的程序員可以允許***次（長）調用超時，然后稍后再試。但是，實際運行情況表明：當整個系統(tǒng)負載很重時這種方案還很不理想。我負責測算我們的應用程序響應一個時間幀需要多長時間。我找到舊解決方案中所有的數(shù)據(jù)庫查詢并一個接一個地針對我們的數(shù)據(jù)庫進行測試。我收集這些結果，作出一些計算，***制作成一個不錯的表并把它放在我們公司的Wiki上。

到底哪里出錯了？好，我一邊喝著早餐咖啡一邊手工運行查詢，結果發(fā)現(xiàn)這次的系統(tǒng)性能大大不同于在重負荷下運行所有系統(tǒng)的性能。這意味著，我的計算以前過于樂觀，而在產品上線之后我們看到的***件事成為客戶端應用程序超時的“一面墻壁”。

• 錯誤4—使用過少的測試數(shù)據(jù)

現(xiàn)在來看，系統(tǒng)負載只是我們高估了系統(tǒng)性能表現(xiàn)的原因之一。第二個原因更令人尷尬！我們的應用程序和客戶端程序之間的所有測試都基于一組相當有限的數(shù)據(jù)集——大約1000條記錄。結果看起來非常成功，因為測試過程中沒有出現(xiàn)過一點警告標志。

其實，我們忽略了一個小小的細節(jié)，那就是：系統(tǒng)上線前，我們使用從舊解決方案中遷移的數(shù)據(jù)填充數(shù)據(jù)庫——這些數(shù)據(jù)大約有100萬條記錄！數(shù)據(jù)集比原來增加了三個數(shù)量級！我們這才發(fā)現(xiàn)自己忘記了設置關鍵的數(shù)據(jù)庫索引——這是一款關鍵應用程序上線前你必須且心甘情愿要做的事情！

• 錯誤5—度量并非統(tǒng)計結果

商界人士要求我們準備一份有關我們向外部提供者程序發(fā)出請求的報告。因為我們做了大量的調用，而且這些調用都很昂貴，所以我們想給他們提供一種方式來計算預期成本和驗證我們從供應商那里得到的發(fā)票。當然，業(yè)務人員不懂SQL，所以他們要求通過電子郵件發(fā)送給他們一個Excel報表。哦，我的娘……要求我們生成Excel文件并發(fā)送電子郵件？如今都是2016年了。實在是沒有辦法！最終，我們還是提供了一個漂亮的界面來實現(xiàn)統(tǒng)計度量。以后我們還將添加一個針對發(fā)出請求次數(shù)的計數(shù)器！

因為我們有了如上文所述的那些最初的問題，所以我們發(fā)出一些修補程序并再次發(fā)布應用程序。經過重新部署，顯示有計數(shù)器的儀表板看起來很不正常。請求的次數(shù)發(fā)生了什么事？情況是：度量數(shù)據(jù)保存在應用程序端，并每隔固定的時間間隔發(fā)送到度量服務端。這意味著，每次我們重新啟動應用程序，計數(shù)器的值都將消失了。簡單是廢話！

幸運的是，我們有一種方法能夠提供有關請求的正確信息，而沒有使用儀表板上的漂亮計數(shù)器，但我們仍然在試圖實現(xiàn)一個真正的計數(shù)器，以保持業(yè)務的統(tǒng)計數(shù)字。

總結

就在我們的產品最終上線之前，我曾經告訴我的同事說：我有些擔心，因為從項目開始到測試階段都不曾遇到過重大的問題，一切顯得那么順利，沒有出現(xiàn)過重大障礙。事實證明我是正確的，錯誤的東西注定會發(fā)生！雖然我在這篇文章中提到的錯誤現(xiàn)在看起來都是很明顯的，但是當我們趕時間進行開發(fā)和測試時它們卻不是那么明顯?，F(xiàn)在，寫出關于我們的項目開發(fā)中的這些羞于啟齒的事是有點兒尷尬；但是，我希望作為讀者的您至少能夠從中獲得一些樂趣，并且以后不會再犯和我們同樣的錯誤！

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】