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

前一段時間寫了一篇文章《凌晨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 號的人在這裏幹嗎。

這麼大級別的數據遷移確定是一個系統性的工程，並非一、2個程序員能夠負責的，可是遷移程序的發起入口用 一、2 程序員負責足以，中間須要調用 N 個系統的接口配合來完成總體的工做。

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

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

這個遷移程序在幹此次大活以前，其實已經經歷屢次考驗了，因此從某種程度上來說此次出問題，輕視也是問題發生的緣由之一。

不但已經屢次使用，在正式遷移以前也安排進行了屢次的驗證，只是作爲管理者沒有和程序員一塊兒深刻排查部分細節，存在部分管理失職。

另外有的讀者說爲何不使用多線程，我強調一下整個遷移項目使用了多線程，而且還不是僅僅一個多線程，只是程序的最外層沒有使用多線程，也就是咱們後面的補救方案。

其實還有不少問題，這裏再也不一一回應，有的提問真的是過低級，感受都不該該是一個程序員提出的問題。

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

不過我以爲有一位讀者的回覆我比較承認：

那些說風涼話的確定沒有作過上千張表新老系統的遷移，還數據庫中間件對接，呵呵

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