技術選型的一點個人思考

是春壹呀發表於2021-09-06

1.前言

這個題目有點大。工作也有些年頭,從開始入行的被動接受,什麼流行就學什麼;到有一些想法,會去思考為什麼使用這種技術;再到主動去學習一些前沿框架。從開始的不理解,事不關已高高掛起,不在其位不謀其政;到也成為了團隊中的中堅力量,去據理力爭應該使用某些技術,把覺得好的技術安利給同事,試圖引入到團隊中;有成功有失敗;也有迫於種種因素使用一些所謂“過時的技術”,有時候有在想,這種“被迫”或"過時"是“為了技術而技術”嗎?


本人從事的是JAVA後端開發,從業七八年,時間不長,但也經歷了不少。從需要使用juqery,easyui等各種前端技術,到前後端分離成為主流;
從一開始的hibernate+structs/structs2框架大行其道,到後來幾乎消聲匿跡;
從最初的redis/memcache兩者之間還能一較長短,到redis一統江湖。
從spring mvc 到言必談spring boot,微服務。不來兩句服務化,降級限流熔斷,高併發你都不好意思出門。


後來轉戰“大資料”領域。那時mapreduce已是明日黃花,strom以及阿里巴巴主導的漢化版jstorm也是江河日下。而spark正當其時,如日中天。遂入坑。
到flink異軍突起,阿里巴巴再出漢化版blink,與spark分庭抗禮,直至略佔上風。後來者只知flink,而鄙視spark之風氣,怪異而可愛。

從傳統關係型資料庫到非關係型資料庫,NOSql,NewSql,到資料湖,再到兼顧OLAP,OLTP的各種分散式資料庫如雨後春筍般出現。
這時期的資料庫已無法像傳統關係型資料庫那樣三足鼎立(o+m+else)(java位面下),而是春秋時期百家爭鳴的局面,各家大廠根據自身的業務需求訂製化了許多產品,包括不限於Fusion,mariadb,OceanBase,TiDB,ClickHouse,greenplum,dorisdb,kudu等等。
對於普通開發者,這是好事?壞事?
對於技術團隊,這是好事?壞事?
有了更多的選擇權?要學的東西更多了?


怎麼選擇一種技術框架,從是否開源,是否KPI開源,開源社群是否活躍/持續/穩定(我沒有說阿里,別亂說),是否有國內大廠使用,社群(特別是問答社群)是否活躍,中文資料是否夠多,都是影響普通開發者/團隊選擇某種技術的原因。

下面將從效率(技術本身),環境(開源,社群),團隊(負責人/骨幹的技術水平和技術偏好)三個方面來談談我的看法。

為避免說教的意思,以及倚老賣老(並不老)的嫌疑,首先宣告,以上以下只代表個人觀點。

2.效率

2.1沒有絕對的效率

我有點害怕技術討論會上,上來就說據XX公司/官網測試,XX比XX效率高出5%(8%or10%...).

這就有點像面試中上來就問QPS多少。不才曾經做過一個廣告競價平臺,日均訪問量幾千萬,聽起來好像很牛逼的樣子,但該系統是純記憶體計算,嚴格限制單次訪問時間,這種系統談QPS根本不具備任何橫向參考意義。

或者像面試中多次被問到spark/hadoop叢集多少個節點的問題。我一般會回答一個大概的數字,然後補充一下叢集cpu cores/記憶體/儲存空間總數,必要時補充叢集任務數,單日/總處理資料量。如果只是效能空間並不太好的有限物理機,用容器虛擬成上千個節點,那就達到了大廠的叢集規模了嗎?

只有在控制變數的前提下,談論單一指標才有意義。

效率並非不重要。但為那點3%的效率犧牲其它東西,值得嗎?這是值得衡量的。說句誅心的話,那點效能優勢對於絕大多數公司,我覺得可能是你自己想多了。還不如好好優化一下那堆shit山。

2.2效率是否絕對重要

在RocketMq(阿里牛逼!)沒有開源前,訊息佇列一般有三種選擇RabbitMQ,ActiveMq,ZeroMq。
三者控制變數的前提下,TPS測試結果表明ZeroMq效率最高。但那些年我所待過的公司,我瞭解到的情況(同事,網路),訊息佇列基本都在RabbitMQ,ActiveMq兩者之間選擇,鮮少使用ZeroMq.

這個例子可能並沒有很強的說服力。但大概就是這麼個意思。

3環境

3.1國內開發大環境

最典型的例子就是mybatis vs hibernate.
除了銀行之類的老專案,現在有新專案在使用hibernate嗎?就算有,hibernate在國內也早就遠離了主流。
可是,在國外,hibernate依然是絕對的主流。
在stackoverflow上的tags數量,看對比圖,hibernate熱度碾壓mybatis,兩者根據不是一個數量級.

按google搜尋趨勢,過去五年,hibernate的搜尋量依然碾壓mybatis.

同樣google搜尋趨勢,按國家地區劃分。全球範圍內,mybatis熱度勝過hibernate的,只有東亞地區。中日韓東亞三國最喜歡mybatis。迷惑。。。

為何會有這種地區之間的巨大差異?有人說是阿里巴巴的帶動作用。阿里對國內JAVA整體環境的帶動和影響是毋庸置疑的,但在mybatis之所以流行這件事情上,完全歸於阿里,也無法解釋韓國和日本同樣流行mybatis這件事。

不管怎麼說,不管公司,團隊還是個人,都是一定程度上從眾的。既然大環境都在使用mybatis,那麼這樣用就不會犯大錯。公司好招人,個人也好找工作。大家的成本都在最低,皆大歡喜。

3.2技術社群的影響

有個笑話,外行人看到程式設計師在工作,覺得好牛逼,全英文的介面。知乎也常有提問,英語不好,學程式設計可行嗎?
底下回答,很多鼓勵,英語跟程式設計沒有太大關係云云。

這句話有毛病嗎?
這至少透露出來兩層意思。

  • 不是說程式設計方面英語不重要。英語好,優勢巨大。

  • 國內程式設計師很多英語不好。以本人常年混跡小公司的經驗來說,好多程式設計師連eclipse或者idea上常用的介面按鈕上的單詞都認不全。唯手熟爾。不懂就百度。這個很多,是好多,無法統計,但個比例絕對不低。

  • 國內IT圈子是一個比較封閉的圈子。雖然,用的技術基本都是發源於國外,但國內的規模保證了資源的足夠。比如spark/flink不需要去官網閱讀一手資料,各個論壇網站上公眾號各種二手三手N手的資料滿天飛(這其中部落格園已經可以算是一股清流了);比如出現了問題,第一時間開啟百度,CSDN雖遲但到,雖然上面都是各種推廣廣告複製貼上錯誤百出答非所問殭屍文章,但一個一個試嘛,多翻幾頁,總能解決問題嘛。(大霧)

有追求的程式設計師,或者大廠的大佬覺得嗤之以鼻,遇BUG先必稱看原始碼,再次github issue,stackoverflow,搜尋必須google,資料必須原文。對CSDN表示垃圾。

本垃圾表示CSDN是個好垃圾。就算是一條底褲,一張廁紙,都有它的用處。

所以英語跟程式設計沒有太大關係,這不是一個疑問,對很多程式設計師來說,這就是事實。大量分佈於各類中小型公司,嚴重依賴於國內各種社群學習(copy)技術,解(zhi)決(zao)問題,賺錢養家。

國內頭部公司/團隊用什麼,大多數的公司/團隊/個人就用什麼。

這件事情的另一個力證是spring cloud vs apache dubbo,兩者隱隱有在國內分庭抗禮之勢。但在全球範圍呢,我就不放google trend圖了。有點欺負人。

但是因為apache dubbo是阿里巴巴出品,進而影響到了國內整個程式設計師圈子,社群,所以大家也逐漸願意去用,雖然被之前的開源社群挺屍行為傷過。就像一個渣男,但他是高富帥啊,自帶光環。

4團隊

4.1 團隊負責人及核心骨幹的技術積累以及技術偏好

2017年新公司進行一個流計算專案。當時整個團隊都是新組建,尚處於磨合期。當時我個人偏向於spark streaming,用得比較熟,上手快,能夠提前排坑,能快速解決線上問題。但當時的技術負責人在召開技術研討會,聽取各方意見後,決定使用jstorm。

我當然服從決定。
當時的jstorm尚有餘暉。而且據說那時jstorm在開源社群詐屍了。頗有幾分捲土重來的架勢。加上當時負責人力排眾議,讓我覺得很安心,他應該是很懂jstorm這項技術棧的。

後來專案順利上線。再後來,不出意外,執行一段時間,遇到棘手線上問題。幾次團隊溝通後,我得出一個結論,決定使用jstorm的負責人並不瞭解jstorm,甚至應該不懂java技術棧(客觀白描事實,無情緒輸出,技術管理者並不一定要懂技術);所以,整個團隊最懂jstorm的好像就是我了。
肝吧,騷年。在經歷了好幾個後半夜,併成功在國慶享受了三倍工資(並沒有)後,BUG解決。

後來回想,如果當時上的是spark streaming就不會出現同樣的問題,就算出現這樣的問題,憑藉對spark streaming的較深入瞭解,也能夠快速解決。


上述這段經歷,我想表達什麼?

  • 一個程式設計師的競爭力包括什麼?不是會用某一種技術,也不是能夠快速上手某種新技術。

    • 學習新技術的慾望,動力,能力;快速上手,保證任務,這些只是基本功。對於新技術,能夠利用經驗,快速理解原理內幕,預排坑道,又快又好解決線上問題,更為重要。所以,當決定使用某種新技術(哪怕技術並不新,如果團隊當中沒人使用過,沒有深刻了解過)時,並不能僅滿足於“能快速上手”。
  • 技術本身沒有立場。沒有好的壞的,沒有國外的國內的。有些技術棧,並沒有mybatis和hibernater那麼懸殊,如何抉擇,很大概率就看技術團隊的偏好,類似於spark vs flink,spring cloud vs apache dubbo,不管誰是勝出者,都很隱。

  • 除了團隊的學習成本,還要考慮其它成本.

    • 比如,運維成本,比如,用scala還是java開發spark.
      用java的好處是雖臃腫但新手外行上手超快。用scala好處是它是spark開發語言,熟悉scala便於檢視spark原始碼,語法強大,逼格高(我真見過scala開發spark的鄙視使用java的);壞處是,語法強大,語法糖很爽,但有時天馬行空對於團隊合作開發真的是災難。
    • 行政成本比如招人成本。
      招一個使用scala的程式設計師不難,基本上會用java的都能快速上手,但要寫出沒有“java”味兒的scala程式碼,還真不容易。(scala的java味兒,就是那種,你一看就是java程式設計師轉過來的痕跡,滿屏都快溢位來)
    • 等等

相關文章