關於深夜技術事故紀實錄的若干問題回復

• 2019 年 10 月 9 日
• 筆記

前一段時間寫了一篇文章《凌晨1點突發致命生產事故，人工多執行緒來破局！》，只是一篇生產事故的記實文章，沒想到在圈內流傳甚廣，其中有程式設計師對其中的細節有點疑惑，剛好國慶可以和大家再進一步探討一下。

現在技術圈有一個不太好的現象，經常看到這樣一個現象，當出現稍微熱門一點的文章的時候，總會出現兩級分化的現象，一撥人會回饋牛逼寫得太好了，然後另一撥人總是回饋又開始吹牛逼了，各種無腦質疑。

個人認為兩個現象其實都不太客觀，一篇文章的出現只是作者本人對於技術的闡述，難免有自身的局限，同樣既然能寫文章必然也不會是瞎亂吹牛逼，那畢竟也有同事朋友都認識，後面還要在這個行業混。

既然文章肯定具有它的局限性，如果寫出來讀者可以給出一些更好的建議，這樣對於寫文章的人也是一種學習，我經常從讀者的留言中學到了很多知識，這是一種正回饋。

現在的問題是很多技術人把抬杠當作了一種本事，用以展示自己的優越感，如果能說到點子上也還好，關鍵是有的留言你一看就可以發現，技術涵養太低了明顯是不懂行的情況。

這篇文章發出來後，公眾號的用戶回饋還可以，因為大家對我有個基本認識，在部落格園和開源中國中，部分技術朋友質疑比較多的地方給予解釋一下：

問題 1：「幾百萬商戶、幾千個代理商」，「上千多張表，關係極為複雜」，「在生產環境找十台伺服器」至少也得是淘寶，京東這個級別的電商網站才能有這個規模了吧！

回復：淘寶、京東到底有多少商戶我還真不太清楚，所以不敢妄言，但請不要輕易低估一家排名靠前的第三方支付公司的數據量，由於歷史堆積、外放通道等各種原因，這點數據還是有的。

至於在生產環境找十台伺服器，這種操作應該是隨隨便便的一個中型互聯網公司都能搞定的，之前公司至少用了 300-400 太伺服器，從中找個10台不是啥問題。

問題2 ：吹什麼牛逼，難道貴公司是淘寶，拼多多？淘寶也就幾百萬商戶，還日均 40 億的交易量，用 Spring Cloud 幾百個微服務撐不起這麼大的體量。

回復：淘寶也就幾百萬商戶這個數據準確嗎？包含個體小微商戶？

日均 40 億的交易額在線下收單這個行業這不算高，下面這張是網傳收單機構2019年7月交易量排名截圖，排名第 10 就已經不止這個交易量了。

用 Spring Cloud 幾百個微服務撐不起這麼大的體量這個問題，就明顯是一個外行得不能再外行的問題了，我就姑且不說有多少成功案例了，就這種評估方式就是低級的。

沒有說哪個技術可以支援多少體量或者不能支援多少體量，要評估這個問題，需要看是什麼樣的團隊在什麼樣的場景以什麼樣的方式來使用次技術。技術本身並不能決定能支撐多大體量，最重要的是看你怎麼用它。

問題3：我怎麼看這是資料庫工程師的工作，為什麼需要寫程式遷移呢？

這一看就是技術小白了，從一個非常老的系統遷移到一個完全的新系統，這其中的業務變化、邏輯變化有多少？如果能讓 DBA 直接遷移的話，那這個系統有多簡單？

且不說這個系統涉及盡千張表，以前老系統的架構和新系統的架構差別有多大， 最重要的是這個新系統後面還跟了一個大數據平台，大數據平台需要根據新系統的 Binlog 日誌，做相關數據的邏輯操作。

所以從讀者提問本身來講，就能看出根本不明白這個難點在哪裡。

問題4：為什麼不建一個和生產 1：1 的環境來模擬測試呢？

一般情況下研發會有四個環境來測試：

• DEV 開發環境，研發人員開發完成自行測試環境。
• SIT 集成測試環境，將自己項目上傳到 sit 一般就進入測試部測試階段了，整體集成測試。
• UAT 客戶集成測試環境，一般可以做外部合作商對接的准生產環境，要儘可能的和生產環境保持一致。
• PRO 生產環境，這個大家都清楚，就是真正項目要運行的環境。

讀者說的1：1 環境，應該就是需要 UAT 和 PRO 的環境儘可能的保持一致，這是一個比較理想的情況，估計只有部分有錢的互聯網公司可以真正實現。

我們做一個中型的互聯網公司，每年在 IDC 上面的花費大概在幾千萬，如果要完全 1：1 的模擬生產環境，每年的花費大概在1000萬以上，中型互聯網公司很難說服老闆去干這件事情。

問題5 ：更別提都啥時代了還 servlet，從描述的技術方案和處理流程來看，基本屬於作坊式的階段，一個程式設計師寫一個介面就能做日均幾十億交易的系統遷移了，呵呵。

使用 Servlet 一點都不過時，現在企業級開發90%的公司都使用的是 Spring MVC 吧，Spring MVC 就是 Servlet 包裝出來了，很過時嗎？

至於屬不屬於作坊式的階段我不反駁，流程上肯定是有缺陷的這個我認可，但並不是一個程式設計師寫一個介面做幾十億的系統遷移，如果真的是這樣那還需要留 20 號的人在這裡幹嘛。

這麼大級別的數據遷移肯定是一個系統性的工程，並不是1、2個程式設計師可以負責的，但是遷移程式的發起入口用 1、2 程式設計師負責足以，中間需要調用 N 個系統的介面配合來完成整體的工作。

問題6 ：我覺得這個錯誤犯得很低級 日數據量達到幾十億次的應用 居然沒考慮到數據量過大遷移耗時太長的問題？平時小項目寫個定時器都會考慮會不會執行時間過長導致，第一次還沒執行完就執行第二次，你們面對千億的數據量居然沒有考慮這個問題？

這個問題中有一個錯誤，交易額是日幾十億而不是交易量幾十億次，訂單量遠遠沒有到達這個量級。數據遷移當然考慮了遷移時間，在整個項目遷移之前其實已經進行過很多次的小規模遷移了，並不是第一次遷移，這個文章中也說明了，這個提問者明顯沒有看完就來噴了。

這個遷移程式在干這次大活之前，其實已經經歷多次考驗了，所以從某種程度上來講這次出問題，輕視也是問題發生的原因之一。

不但已經多次使用，在正式遷移之前也安排進行了多次的驗證，只是做為管理者沒有和程式設計師一起深入排查部分細節，存在部分管理失職。

另外有的讀者說為什麼不使用多執行緒，我強調一下整個遷移項目使用了多執行緒，並且還不是僅僅一個多執行緒，只是程式的最外層沒有使用多執行緒，也就是我們後面的補救方案。

其實還有很多問題，這裡不再一一回應，有的提問真的是太低級，感覺都不應該是一個程式設計師提出的問題。

不過還是有一些讀者會對這種大規模遷移有所了解，這其中涉及的細節簡直不要太多，任何一個小的忽略都有可能導致大的問題，這種事情沒有辦法在文中一一舉例出來。

不過我覺得有一位讀者的回復我比較認可：

那些說風涼話的肯定沒有做過上千張表新老系統的遷移，還資料庫中間件對接，呵呵

最後，還是那句話：保持技術人的那顆初心，一切以解決實際問題為主。