技術還是思想？

     

 我總是遇到一些問題，這些問題是由於基本的問題沒有引起重視或者是沒有深入研究問題在哪裡。導致做出了技術棧改變甚至架構改變。我記得以前在一個群裡，一個小夥伴又發了一個連線，這個講述了一個新的概念和技術棧。小夥伴說我剛學會了這個。這時候群裡一位資深的技術領導說到：“我們要學習的是一種程式設計思想，而不是一種技術。”這裡就引出一個問題，因為我們IT系統是唯一一個比時裝界概念還多的領域。這個我之前有公眾號寫過的，感興趣去的可以去看看。技術是層出不窮的，尤其是最近10幾年，大資料、AI、區塊鏈、機器學習、微服務、中臺等等。這裡這些技術不是適合每個公司的，而且有些技術實際上對於不少公司來說就是坑，或者完全不適用。比如有些大公司最後放棄了微服務。請看連線。 https://blog.csdn.net/k6T9Q8XKs6iIkZPPIFq/article/details/115152912

   我們引入一種技術基本是為了解決某種問題，但是如果這種問題本身是現在技術人員技術基本功不紮實導致的，那麼引入技術的就變成了迴避問題後增加了新的問題。比如我一再說的，1000萬的表查詢慢這明顯是SQL的問題，不是資料庫的問題。改成分庫分表以後只是將資料庫進行了切分，看上去是N分之一的資料，但是隨著資料堆積再次會達到每個N分之一到了1000萬，問題再次回到了原點。再次切分？不要相信（很輕易的）水平擴充套件，這種水平擴充套件，不是動態無感知的。redis做reblance的時候都要卡一下。

   還有由於有錯誤的認知，認為資料庫寫入來不及處理，所以引入了訊息佇列。如果這個訊息佇列是為了削峰填谷也是可以理解的，但是幾乎我見過的是為了過一道而過一道居多，因為通常只有幾秒一條或者一秒幾條。每秒上萬條的，可能又不選擇訊息佇列了。而這只是剛到了資料庫效能的半山腰，甚至膝蓋，距離資料庫天花板還早著呢。就這樣使得整個系統多了一個技術環節而導致架構的複雜、而且多了一個環節導致繼續慢了。我這裡不是說訊息佇列不行，而是要達到一定程度的訊息佇列處理能力的硬體（SSD）等，成本是巨大的。迄今為止一般中小公司，很少能有每秒1萬左右的事務線上業務寫入。

   還由於對快取和大資料的迷信。把不管有沒有必要的都放到redis中，增加了redis的負擔。以及不管邏輯全表查詢（上億資料）來提醒大資料的價值，總有一天資料積累到了，一個命令下去系統會故障的時候。

   與其把架構搞得複雜以後還是回答原點，那麼不如我們一開始就找到這個問題點，解決掉。我有一次就和一位領導說，我相信15年前中國的三大運營商和五大行的業務量，都比我們99.99%的企業的業務量大（不要不承認）。那時候，沒有大資料業務也沒受影響；那時候，沒有微服務系統開發也沒什麼問題；那時候，沒有中臺系統也能執行挺好。當然這裡沒有說這幾個不行，沒有這個意思。只是結合實際來說看看是不是真的適合。

   我們真的可以編寫一段程式計算1+2+3.。。。+100  1000或者1萬。 但是如果我真實環境真的是隻要1+2+3.那麼編一段程式的代價比直接運算要大。

   如果真的要執行，那麼是不是一定要傻算？參考我以前的一篇文章。 https://mp.weixin.qq.com/s/3x2GsCohBy_4AXf4DbQk5w