28個SpringBoot項(xiàng)目中常用注解，日常開發(fā)、求職面試不再懵圈
前言在使用SpringBoot開發(fā)中或者在求職面試中都會使用到很多注解或者問到注解相關(guān)的知識。本文主要對一些常用的注解進(jìn)行了總結(jié)，同時也會舉出具體例子，供大家學(xué)習(xí)和參考。注解
大家好，我是君哥。
最近我負(fù)責(zé)的系統(tǒng)出了一次生產(chǎn)事故，這次事故竟然是因?yàn)榱魉栔貜?fù)導(dǎo)致的。今天來給大家分享一下。
這個流水號的使用場景是上游系統(tǒng)調(diào)用下游接口時傳入一個唯一 ID，流水號這個參數(shù)在聯(lián)調(diào)或定位問題時很方便。
我們系統(tǒng)中的流水號是一個 32 位的字符串，為了能讓上下游系統(tǒng)聯(lián)動，下游系統(tǒng)接到上游傳過來的這個 ID 后，會取前 23 位，再自己拼接剩下 9 位，傳到自己要調(diào)用的下游系統(tǒng)，這樣整個調(diào)用鏈通過請求 ID 就可以快速串起來。
圖片
在我的系統(tǒng)中，自己定義流水號的后 9 位，為了能夠更清晰地從流水號中看到請求鏈上的系統(tǒng)調(diào)用關(guān)系，我們把流水號后 9 位定義成了系統(tǒng)編號(3位) + 子系統(tǒng)編號(2位) + 自增序列(4 位) 。
如下圖，我的系統(tǒng)生成的流水號前 23 位來自上游，后 9 位是 001(系統(tǒng)編碼) + 01(子系統(tǒng)編碼) + (0 ~ 9999自增)。
圖片
在我們的業(yè)務(wù)場景中，上游系統(tǒng)調(diào)用我的系統(tǒng)，我的系統(tǒng)有 10000 個流水號，支撐 10000 筆交易，理論上足夠使用了。
不幸的，系統(tǒng)中的業(yè)務(wù)開發(fā)同事并沒有注意到流水號生成規(guī)則，因?yàn)榱魉柹晒ぞ呤且粋€成熟的 util 類，大家直接調(diào)用獲取流水號。
而這一次的事故中，我們的業(yè)務(wù)是一個批量業(yè)務(wù)，收到上游系統(tǒng)的請求后，我們的處理邏輯是讀取合作方推送的文件，然后對每一個文件調(diào)用下游接口進(jìn)行處理。每一個文件處理需要調(diào)用下游四個接口，每一個接口都需要新的流水號。
圖片
這樣我們就能看到流水號生成工具的瓶頸了，如果超過 2500 個文件，10000 個流水號就會被用完。而流水號生成工具的邏輯是如果流水號用完，就會從 0 開始重新生成，造成了流水號重復(fù)。
下游系統(tǒng)會對流水號進(jìn)行判斷，收到重復(fù)的流水號，直接返回接口調(diào)用失敗。因?yàn)槭〉恼{(diào)用比較多，觸發(fā)了生產(chǎn)告警。
比較慶幸的是，這次事故并沒有造成交易阻斷、現(xiàn)金損失、客戶體驗(yàn)差等問題。還有一點(diǎn)幸運(yùn)是正好趕在上線窗口前發(fā)現(xiàn)了，沒有走緊急上線流程。要知道，緊急上線對團(tuán)隊(duì)和個人的績效考核都會產(chǎn)生影響。
但交易失敗的三方文件會影響合規(guī)檢查，必須進(jìn)行交易補(bǔ)償。
我們團(tuán)隊(duì)做的修復(fù)工作是及時修改了流水號生成規(guī)則，我們把后面 6 為定義成自增的序列，這樣足夠滿足所有場景的使用了，而我們保留系統(tǒng)編碼，對系統(tǒng)交易鏈路追蹤是非常必要的。
上線后，請上游系統(tǒng)再次觸發(fā)接口調(diào)用，對之前失敗的三方文件進(jìn)行補(bǔ)償處理。
無論在國企、銀行還是互聯(lián)網(wǎng)公司上班，生產(chǎn)事故的出現(xiàn)，都可能會影響到公司正常業(yè)務(wù)的開展，甚至讓業(yè)務(wù)遭受損失。嚴(yán)重的，事故當(dāng)事人會收到嚴(yán)格處罰，甚至被淘汰掉。
除了對考核的影響，解決故障的過程也是非常耗時的。
在沒有定位到問題之前，必須先采取緊急措施接觸生產(chǎn)告警，以免造成大的業(yè)務(wù)損失。應(yīng)急措施包括但不限于重啟服務(wù)、執(zhí)行應(yīng)急腳本、業(yè)務(wù)降級等。
采用應(yīng)急手段解決故障后，就要開始定位問題了。有的問題可能不太好定位，尤其是一些老代碼，作者已經(jīng)離職，也沒有留下什么詳細(xì)的文檔。接手人可能之前看過代碼，但是過了很長時間又記不清了。
再復(fù)雜的問題，最終肯定能定位到原因。接著就是評估業(yè)務(wù)影響，這一步也是必須要做的，因?yàn)槎鄶?shù)情況下，對業(yè)務(wù)的影響大小決定了這次事故的級別，這項(xiàng)工作一般會有業(yè)務(wù)參與。
比如我過往的一家公司規(guī)定，故障超過 15 分鐘，影響超過 100 筆訂單的故障定義為一級故障。
接著就是給領(lǐng)導(dǎo)匯報，甚至需要層層匯報。這一步可以說是最難做的。
首先需要明確問題責(zé)任人或者責(zé)任團(tuán)隊(duì)，因?yàn)楣收峡赡軙绊懙娇冃Э己耍院芏鄷r候會遇到扯皮或帥鍋的情況，沒有一個領(lǐng)導(dǎo)愿意讓自己的團(tuán)隊(duì)背鍋。有時候把鍋甩給中間件，數(shù)據(jù)庫或其他底層組件，也是一個選擇。
撰寫事故報告也是非常耗時的一個工作，領(lǐng)導(dǎo)不可能像技術(shù)人員一樣通過看代碼了解事故原因，他們需要故障報告能夠清晰易懂，甚至幾句話就能講明白。
事故復(fù)盤是為了讓團(tuán)隊(duì)能夠了解到故障的根本原因，作為經(jīng)驗(yàn)教訓(xùn)，防止再犯。
今天分享了我在工作中遇到的一次生產(chǎn)事故。生產(chǎn)事故除了影響業(yè)務(wù)正常運(yùn)轉(zhuǎn)，處理事故的過程也是非常花費(fèi)時間和精力的。完全不出事故是不可能的，如果能對歷史故障吸取教訓(xùn)，多花心思研究自己的系統(tǒng)，可以有效降低故障率。
本文鏈接：http://m.www897cc.com/showinfo-26-92145-0.html好坑，流水號重復(fù)竟然導(dǎo)致了一次生產(chǎn)事故！
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 如何線程安全的使用 HashMap
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號