需求是什么
這里不再介紹具體的業務。簡而言之,有兩個接口(查詢、確認)對前端頁面提供服務。
查詢接口返回的數據依賴于本地數據與外部接口計算后的結果,也就是頁面展示的是數據快照。確認接口是按照頁面的展示結果請求外部接口。
考慮到用戶打開展示頁面時的數據與提交操作可能間隔很久,實際請求時結果已發生變化,而這種操作會影響業務結果。因此在提交時會進行一次 check,如果發現數據發生變化需要提示頁面進行刷新。
為了方便大家理解,我簡單的畫了個圖,畢竟上面太啰嗦了。
查詢接口:
確認接口:
雖然這個圖有點草率,但是相信看到這里的小伙伴(默認都是聰明的)都對需求了然于胸了。
我怎么搞得
掰扯了半天,我們的主角 MD5 還沒有出場,別著急,馬上就來了。
你也可以想想,這個場景和 MD5 是怎么扯上關系的呢?
可以看出,這里需要前端將查詢接口的返回值重新組裝作為確認接口的入參。而后端需要再次走數據聚合的邏輯與前端傳過來的業務值進行比較,如果不匹配則提示頁面需要刷新。
一切看起來都順理成章,那么小編遇到了什么問題呢?
簡單來說有兩點:
- 前端同學表示值不好傳,因為這個頁面比較復雜,具體原因小編也沒深究,可能是被糊弄了。
- 后端同學(也就是小編)發現,這樣查詢接口和確認接口耦合很嚴重,如果確認接口需要新的入參,那么就需要改動查詢接口。隨著查詢接口邏輯越來越復雜,確認接口的一個入參就需要一層一層的傳過來。很不友好。
呵呵,機智的小編靈機一動,便想到了了MD5,看看百度百科怎么說:
MD5 信息摘要算法(英語:MD5 Message-Digest Algorithm),一種被廣泛使用的密碼散列函數,可以產生出一個 128 位(16 字節)的散列值(hash value),用于確保信息傳輸完整一致。
一圖勝千言:
在工程,它差不多就是這么用。
String md5= Md5Utils.get(String source);
可能有聰明的小伙伴會說了,這是散列函數存在哈希碰撞,不同的字符串也有可能生成相同的哈希值。
是的沒錯,但是在小編的業務場景中,這種出現的概率微乎其微,忽略不計,解釋權歸小編所有。
那么具體怎么做的呢,還是看圖說話.
改造后的查詢接口:
改造后的確認接口:
我們需要對查詢接口返回的業務集關鍵屬性進行組合哈希,這樣可以生成數據快照值。確認接口無需再傳入業務集合,只需要傳入數據快照值,后端進行對比即可知道是否發生變更。
一切都是那么的美好,接下來就到了動人心魄的編碼環節。話不多說,小編的項目中引入了hutool包,什么你不知道糊涂包?
真不錯,果然是效率擔當,一行代碼就搞定了。
/**
*生成數據哈希
*/
privateStringgenerateSnapShotHash(AcceptListQueryWrapResultDTOwrapResultDTO){
StringBuilderbuilder=newStringBuilder();
for(AcceptListQueryResultDTOitem:wrapResultDTO.getAllList()){
builder.append(item.getQuotationId()).append(item.getOperateType()).append(item.getPriceTypeCN());
}
returnMD5.create().digestHex16(builder.toString());
}
請各位看官記住這行代碼:
MD5.create().digestHex16(builder.toString());
畢竟它就是糊弄你點進來的罪魁禍首。
出了什么事
當小編開發完以后,開心的部署在了測試環境。和前端聯調的時候,發現第一次請求總是超時 ???
一想可能是mock平臺的問題,畢竟三方的查詢接口還沒開發完成,就不以為然。請注意,只是第一次超時。同樣的請求參數第二次光速返回。呵呵,你說不是環境的問題,小編自己都不大信呢。
友方的接口開發完了,小編期待的換上了對方的接口。結果現實給了小編一記左勾拳,還是第一次超時。這不科學?于是小編對自身產生了懷疑?難道不是環境的問題?
于是連忙在本地測試了一下,居然是光速返回。作為自信的人一定不是代碼的問題,那么這個鍋往哪里甩呢?又臭又硬的小編狠狠的思考了一分鐘,又將鍋甩給了業務網關(統一接收HTTP請求)肯定是它的毛病,畢竟測試環境的網關出問題很常見。
于是開開心心的準備上預發了。上了預發絕對沒問題!!!小編信誓旦旦的對QA說道。
上帝為你關上一扇門的同時也會為你關上一扇窗,預發環境第一次還是超時!!!小編覺得很慚愧對不起一起上線的小伙伴,畢竟大家都準備十點下機了。
小編陷入了沉思中。。。
怎么修好的
排查了預發環境的接口,友方的杰夫接口TP99只有幾毫秒,網關也沒有問題,也許是數據庫的原因,排查發現也沒有問題。頓時,小編又迷茫了。
山重水復疑無路柳暗花明又一村,機智的小編想到了國內知名廠商開源的一款java診斷工具Arthas,利用它可以查看方法詳細耗時。點我查看 主動打開另一扇窗。
當你遇到以下類似問題而束手無策時,Arthas可以幫助你解決:
- 這個類從哪個 jar 包加載的?為什么會報各種類相關的 Exception?
- 我改的代碼為什么沒有執行到?難道是我沒 commit?分支搞錯了?
- 遇到問題無法在線上 debug,難道只能通過加日志再重新發布嗎?
- 線上遇到某個用戶的數據處理有問題,但線上同樣無法 debug,線下無法重現!
- 是否有一個全局視角來查看系統的運行狀況?
- 有什么辦法可以監控到 JVM 的實時運行狀態?
- 怎么快速定位應用的熱點,生成火焰圖?
- 怎樣直接從 JVM 內查找某個類的實例?
由于預發環境還是比較麻煩,于是小編在測試環境準備好了arthas環境。
下面簡單介紹下使用步驟:
- 下載全量包 arthas-bin.zip
- 解壓
- chmod -777 arthas-boot.jar
- 啟動 sudo -u admin -EH java -jar /home/export/App/arthas-boot.jar
當看到圖標出現時,即啟動成功。具體使用方法可以查看官網,此處不再贅述。
我們使用trace命令查看方法耗時,同時在頁面請求該查詢接口。
trace --skipJDKMethod false com.jd.universal.inquiry.service.protocol.jsf.AcceptListWebErpServiceImpl queryList
可以看到這行生成數據快照的方法,耗時占整個接口的99.57%,緊接著我們繼續監控generateSnapShotHash方法:
trace --skipJDKMethod false com.jd.universal.inquiry.service.protocol.jsf.AcceptListWebErpServiceImpl generateSnapShotHash
可以看到方法的耗時都集中在
[99.99% 36562.318173ms ] cn.hutool.crypto.digest.MD5:create() #103
接著再次頁面點擊請求操作,出現以下情況:
可以看到后面多次請求 cn.hutool.crypto.digest.MD5:create()方法耗時僅不到一毫秒。和我們之前遇到的狀況一致。此時已確定是這行MD5導致的第一次加載很慢。
雖然原因找到了,但是還是得看下為什么這行代碼只有在第一次時這么慢,于是我們進入該方法看看它到底搞什么幺蛾子。
可以看到初始化方法如下:
由于現象是程序第一次運行很慢,后續很快,根據小編多年的寫/修BUG經驗懷疑是這段初始化中存在靜態加載。
MessageDigest是JDK自帶的類,為應用程序提供摘要算法的,這里我們關注點就落在了上面的一行。我們點進去看一下:
果然我們看到了他在嘗試加載BouncyCastle庫,我們來看一下這個庫的介紹:
BouncyCastle(輕量級密碼術包)是一種用于 Java 平臺的開放源碼的輕量級密碼術包;Bouncycstle 包含了大量的密碼算法,其支持橢圓曲線密碼算法,并提供 JCE 1.2.1 的實現。
所以問題的答案就呼之欲出了,隨著源碼的深入,我們看到:
privatevoidsetup()
{
loadAlgorithms(DIGEST_PACKAGE,DIGESTS);
loadAlgorithms(SYMMETRIC_PACKAGE,SYMMETRIC_GENERIC);
loadAlgorithms(SYMMETRIC_PACKAGE,SYMMETRIC_MACS);
loadAlgorithms(SYMMETRIC_PACKAGE,SYMMETRIC_CIPHERS);
loadAlgorithms(ASYMMETRIC_PACKAGE,ASYMMETRIC_GENERIC);
loadAlgorithms(ASYMMETRIC_PACKAGE,ASYMMETRIC_CIPHERS);
loadAlgorithms(KEYSTORE_PACKAGE,KEYSTORES);
loadAlgorithms(SECURE_RANDOM_PACKAGE,SECURE_RANDOMS);
loadPQCKeys();//sowecanhandlecertificatescontainingthem.
//省略。。。
}
正是由于這些算法實現的加載,導致MD5.create()第一次調用時耗時超過數十秒。
好了,既然找到了問題。那么改動起來就很簡單了,小編嘗試尋找了糊涂包中提供的方法,發現并沒有入參可以關閉該三方加密包的初始化。于是換用了Google提供的MD5的實現。重新打包,部署,一次成功,完美。
后語
QA同學在測試環境測出了這個問題,而自信的本人不屑一顧,堅持自己愚昧的觀點,先認為是Mock的問題,接著又說是網關的問題。由于我的盲目自信,導致上線到很晚,表示非常的慚愧。總結失敗的原因:
- 合理評估使用第三方包
- 測試環境遇到的問題盡力去追,不要盲目下結論
- 要聽QA的話
-
數據
+關注
關注
8文章
7003瀏覽量
88943 -
md5
+關注
關注
0文章
29瀏覽量
20867 -
Check
+關注
關注
0文章
4瀏覽量
7556
原文標題:震驚,一行MD5居然讓小伙伴都回不了家!!!
文章出處:【微信號:magedu-Linux,微信公眾號:馬哥Linux運維】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論