資訊

波尔多红衣服:這波技術社區的程序員,技術視野有點堪憂!

廣告
廣告

微信掃一掃,分享到朋友圈

這波技術社區的程序員,技術視野有點堪憂!
0 0

前一段時間寫了一篇文章《凌晨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 :我覺得這個錯誤犯得很低級 日數據量達到幾十億次的應用 居然沒考慮到數據量過大遷移耗時太長的問題?平時小項目寫個定時器都會考慮會不會執行時間過長導致,第一次還沒執行完就執行第二次,你們面對千億的數據量居然沒有考慮這個問題?

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

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

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

另外有的讀者說為什么不使用多線程,我強調一下整個遷移項目使用了多線程,并且還不是僅僅一個多線程,只是程序的最外層沒有使用多線程,也就是我們后面的補救方案。

其實還有很多問題,這里不再一一回應,有的提問真的是太低級,感覺都不應該是一個程序員提出的問題。

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

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

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

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

作者簡介純潔的微笑,一個有故事的程序員。曾在互聯網金融,第三方支付公司工作,現為一名自由職業者,和你一起用技術的角度去看這個世界。我的微信號puresmile2,歡迎大家找我聊天,記錄你我的故事。

我還沒有學會寫個人說明!

滴滴從KV存儲到NewSQL實戰

上一篇

一篇文章看懂,存儲虛擬化在不同用例中的實踐與優勢

下一篇

你也可能喜歡

這波技術社區的程序員,技術視野有點堪憂!

長按儲存圖像,分享給朋友

ITPUB 每周精要將以郵件的形式發放至您的郵箱


微信掃一掃

微信掃一掃