這段時間一直在忙著作業上的事情和新書的籌備,但都2021年了,怎么都應該寫一點,算不上總結回顧,只能算閑聊胡扯,
2020年TIOBE’s對于各種編程語言排名情況的總結是:“Python is TIOBE’s Programming Language of 2020”,這無疑是對我自己這個寫了20年Java程式的老屌絲相當有震撼力的一句話,曾幾何時自己調侃delphi、調侃Ruby的樣子和近些年自己被調侃的樣子極為相似,
Python的快速發展、Java的被趕超、Ruby的夕陽余暉有其語言自身的因素,也有各大廠商推波助瀾的因素,還有其生態圈發展情況等等因素,但筆者認為那些都是表面現象,而最大影響因素是由社會對資訊化應用、數字化應用的需求所決定的,一門高級語言是不是有活力,主要是看它能不能低成本解決各行業對各類軟體方案進行快速復制的要求,這些成本可以包括人力資源、單位時效、需求匹配度、行業所需的運行效能各個方面,
而作為程式員,特別是生活在當前物質環境下的程式員,我們對于一門語言的選擇往往取決于建立在此基礎上的下一維度的考量,例如就業機會如何、學習成本如何、薪資水平如何、持續性如何、內卷風險如何甚至還包括行業趨勢的押注,就基本盤來看Java和Python這兩門語言在各自擅長的領域表現得都還不錯,不過也相互向對方擅長的領域進行試探(這里的Java泛指JVM系列語言,包括但不限于Groovy、Scala、Kotlin),之前Java和C#不也是這樣相互試探,互摸過河的嗎?
1、關于Java版本
Java社區今年發布了JDK14和JDK15兩個版本,但是目前國內使用Java的群體,大都使用的是JDK8或以下版本,將JDK11應用于生產環境的組織還是少數(但越來越多),即使使用Oracle JDK 11完成的系統開發大多也會運行在OpenJDK環境下,這主要的原因還是由于大家關注的主要是JDK的LTS版本,而JDK8和JDK11這兩個LTS版本,Oracle分別承諾會一直提供更新支撐到2030年和2026年(但還需要注意OpenJDK相關停更時間),如果讀者所在組織依然還在使用JDK8以前的版本,這里建議可以至少升級到JDK8了,
今年發布的JDK14和JDK15兩個版本,雖然不是TLS版本,但是作為JDK17 LTS發布前的特性預覽,大家可以通過這兩個版本中發布的各種重要特性窺探到Oracle對于Java后續發的規劃思路,從JDK 9開始,Oracle JDK每半年就會更新一次,每次發布新的Oracle JDK后其對應的Open JDK也會隨之進行半年時間的更新,

在JDK 14、JDK 15兩個版本中個人覺得比較重要的幾個特性更新包括:
-
關于垃圾回收器的更新:CMS垃圾回收器正式被剔除,ParallelScavenge + SerialOld GC 的組合模式被棄用,ZGC垃圾回收器轉正,G1回收器得到優化后依然是默認的垃圾回收器,
-
關于模式匹配語法的使用:模式匹配語法已經是連續兩次發布預覽版本,那么大概率會作為正式特性出現在JDK17版本中,匹配模式是對instanceof修飾符的語法優化,
-
關于NullPointerExceptions例外的完善:更完善的NullPointerExceptions例外將快速幫助使用者定位出現空指標的位置,既是使用多個連續方法進行呼叫時,也可以快速定位,
-
依賴封閉/介面封閉:實際上介面封閉功能在JDK15之前的版本就有內部應用,這個版本只是將介面封閉功能作為預覽特性提供給最終使用者使用,個人估計在穩定的JDK17版本中,該特性大概率會作為正式特性被發布,
-
record緊湊語法:該特性也已經連續兩次發布預覽版本了,也是大概率會作為正式特性在JDK17版本中進行發布,個人疑惑,緊湊語法不會是Oracle團隊借鑒了Lombok的功能特色吧~~
2、Spring生態
2.1、Spring Boot更新
2020年11月,Spring Boot發布了2.4.0版本,這是一個GA版本也就是正式發布版本,而且Spring Cloud也做了對應匹配的更新,2.4.0版本開始支持JDK15的特性,但這個版本并不建議各位在正式環境立即更新,
實際上Spring Boot今年一共維護了兩個大版本2.3.1——2.3.6版本,以及2.4.1版本,作者目前在實際作業中使用最多的版本還是2.2.X的版本,而2.3.X的版本在最新的幾個專案中也有采用,從Spring 2.3.X版本開始,Spring Boot的構建方式從Maven切換到了Gradle,這個是筆者之前的猜想是一樣的,作者在幾年前就在專案構建程序中力推使用Gradle,并且在實施程序中得到很好的效果證明,
Gradle在多年前的使用份額上,已經有快速追平Maven的趨勢,而Spring Boot的新版本采用Gradle進行構建后,勢必會為Gradle的推廣起到正面示范效果,

2.2、Spring Cloud更新
隨著Spring Boot的更新,Spring Cloud也發布了新的版本,2020年Spring Cloud發布了2020.0版本,該版本并沒有再使用之前Spring Cloud版本的命名方式(上一個Spring Cloud的版本命名為Hoxton,這些版本名都是以英國倫敦地鐵站進行的命名),新版本采用日歷化版本命名為2020.0.X,該版本中正式去掉了多個netflix集成的組件,例如netflix-hystrix、netflix-ribbon、netflix-zuul、netflix-turbine,只有netflix eureka得以保留(并且已經不推薦使用),可見netflix在Spring Cloud的新版本中所占比重已經是是越來越低了,
實際上Spring Cloud替換netflix各個組件的動作在之前的版本中已逐漸清晰,Spring Cloud官方也給出多個組件的替換方案(列舉這些替換方案后,可以看到,Spring大社區的技術堆疊更新真的很快,稍不留神就容易遺漏更新,再稍不留神就容易內卷):
-
服務注冊中心:
Nacos,來自于SpringCloudAlibaba,之前如果已經在專案中使用的Consul,那么建議繼續使用;如果是新的專案或產品,建議切換到Nacos上來;其它還在支持的組件包括zookeeper、Consul;Eureka已經不建議使用,如果仍然在專案或者產品上使用,則可以考慮以最小的技術代價盡快完成升級,個人認為Nacos之所以會后來居上,它的集成度很高,顯著減少了使用者的學習成本是很重要的一個方面 -
服務呼叫:
openFegin,有的讀者容易混淆openFegin和Fegin,這兩者不是一回事,Fegin是netflix提供給Spring社區的組件,目前已被openFegin替換掉 -
呼叫負載:
LoadBalancer,在新版本中已經正式替換掉Ribbon -
熔斷與升降級:
Resilience4J和Sentienl都是最新版本中官方推薦的可選版本,其中Sentienl來源于SpringCloudAlibaba,國內的使用資料和討論資料也更多一些,建議可以使用Sentienl替換Hystrix,當然,如果讀者所在組織的替換成本比較高,那么建議可以分步驟進行,畢竟Hystrix之前存在了較長一段時間 -
服務網關:
實際上個人來說,之前各個專案和產品中使用zuul還是用得比較順手的,但后面隨著更多的產品和專案的研發執行,作者也開始轉向gateway的使用,確實好用,推薦使用 -
服務配置:Config組件依然存在于Spring Cloud的最新版本中,但如果讀者所在組織使用的是Naos,那么建議可以使用Nacos進行功能替換
其余不再列舉,總結一下Spring Cloud的發展趨勢:組件集成度逐漸升高,初始版本中由netflix提供的各種組件已被逐步移除(主要原因是后者更新頻度無法滿足Spring社區的要求),SpringCloudAlibaba提供的組件在Spring社區所占份額逐步提升,甚至可以猜測不久的將來SpringCloudAlibaba和原生Spring Cloud兩者的技術線路會逐步合并,實際上讀者直接使用SpringCloudAlibaba就是一個不錯的選擇
3、周邊動態
3.1、IDE工具更新:
Eclipse最近幾年使用份額掉的非常厲害,最主要的原因就是大多數開發人員轉向了 Intellij IDEA,雖然后者的商用版是付費的,但并不影響開發人員的使用熱情(你懂的),不過個人認為Eclipse和IDEA兩個主要的開發工具并沒有誰絕對勝出的說法,廠商支持和社區活躍度起到了主要的影響作用,選擇哪個工具還是看個人喜好,畢竟想靠換一個工具就get新技能的想法有些幼稚,
2020年12月Intellij發布了IDEA的最新版本2020.3(包括多個編輯器),這樣一來2020年Intellij IDEA一共就發布了3個可用版本,這個版本新增/修改了多個特性,包括:
-
歡迎頁發生了明顯的變化,在歡迎頁上新增了學習選項卡,以便于使用者對IDEA的使用學習,
-
IDEA對Git的支持已經非常完整了,直接將Git選項集成到了頂層選單中,并且在搜索選項卡中新增了單獨的Git搜索結果項,
-
其它優化項諸如代碼表情、閱讀器模式、除錯功能改進、性能分析器、記憶體快照等等,

3.2、Centos 8 將很快停止維護
CentOS 8將于2021年停止更新,不過CentOS 7還是會支撐到2024年,所以目前使用量最大的CentOS 7版本的用戶暫時不會受到影響,另外CentOS 8 停止更新后,使用者可以選用CentOS Stream 8在非生產環境進行替換,不過,個人認為最好的選擇是直接切換到Ubuntu server,
3.3、企業應用方面,中臺化大行其道
小前臺、大中臺實際上是阿里2015年開始在內部推行的技術戰略,到了18年各個行業看著阿里的成功經驗后也開始逐步解決這樣的資源集中化解決方案,零售、物流、快消品、耐消品、互金等等行業,都有一批企業開始試行中臺化線路,還有一批IT企業也開始精耕于企業級中臺化解決方案,并向客戶大肆宣傳自己的成功案例,但是真的所有企業都適合做中臺嗎?筆者持懷疑態度,要知道阿里所宣推的中臺,也只是電商行業的中臺,簡稱電商中臺,
單純從技術層面來考慮,中臺化戰略涉及到對企業中若干系統的整合問題,但并不是所有企業都具有阿里那樣快速的系統迭代特性,就筆者個人所接觸的客戶,一些客戶還在使用10年前的老系統,這些系統的集成將是比較困難的技術問題;從業務層面考慮,并不是所有的企業都有幾十個業務系統,上千個業務流程,對單一幾個系統的中臺化是否可以達到簡化業務的目的?從IT團隊人力資源的角度看,算了,不看了,
一年的時間又過去了,疫情的影響無論是對個人還是行業都是很明顯的,程式員應該要多多考慮如何避免內卷的問題,要多多考慮自身抵御風險的能力,不要在舒適區待得太久,2021,與君共勉,
轉載請註明出處,本文鏈接:https://www.uj5u.com/houduan/248087.html
標籤:java
