這段時間一直在忙著工作上的事情和新書的籌備。但都2021年了，怎么都應(yīng)該寫一點，算不上總結(jié)回顧，只能算閑聊胡扯。

2020年TIOBE’s對于各種編程語言排名情況的總結(jié)是：“Python is TIOBE’s Programming Language of 2020”。這無疑是對我自己這個寫了20年Java程序的老屌絲相當有震撼力的一句話，曾幾何時自己調(diào)侃delphi、調(diào)侃Ruby的樣子和近些年自己被調(diào)侃的樣子極為相似。

Python的快速發(fā)展、Java的被趕超、Ruby的夕陽余暉有其語言自身的因素，也有各大廠商推波助瀾的因素，還有其生態(tài)圈發(fā)展情況等等因素，但筆者認為那些都是表面現(xiàn)象。而最大影響因素是由社會對信息化應(yīng)用、數(shù)字化應(yīng)用的需求所決定的。一門高級語言是不是有活力，主要是看它能不能低成本解決各行業(yè)對各類軟件方案進行快速復(fù)制的要求。這些成本可以包括人力資源、單位時效、需求匹配度、行業(yè)所需的運行效能各個方面。

而作為程序員，特別是生活在當前物質(zhì)環(huán)境下的程序員，我們對于一門語言的選擇往往取決于建立在此基礎(chǔ)上的下一維度的考量，例如就業(yè)機會如何、學(xué)習(xí)成本如何、薪資水平如何、持續(xù)性如何、內(nèi)卷風(fēng)險如何甚至還包括行業(yè)趨勢的押注。就基本盤來看Java和Python這兩門語言在各自擅長的領(lǐng)域表現(xiàn)得都還不錯，不過也相互向?qū)Ψ缴瞄L的領(lǐng)域進行試探（這里的Java泛指JVM系列語言，包括但不限于Groovy、Scala、Kotlin）。之前Java和C#不也是這樣相互試探，互摸過河的嗎？
1、關(guān)于Java版本

Java社區(qū)今年發(fā)布了JDK14和JDK15兩個版本，但是目前國內(nèi)使用Java的群體，大都使用的是JDK8或以下版本，將JDK11應(yīng)用于生產(chǎn)環(huán)境的組織還是少數(shù)（但越來越多），即使使用Oracle JDK 11完成的系統(tǒng)開發(fā)大多也會運行在OpenJDK環(huán)境下。這主要的原因還是由于大家關(guān)注的主要是JDK的LTS版本，而JDK8和JDK11這兩個LTS版本，Oracle分別承諾會一直提供更新支撐到2030年和2026年（但還需要注意OpenJDK相關(guān)停更時間）。如果讀者所在組織依然還在使用JDK8以前的版本，這里建議可以至少升級到JDK8了。

今年發(fā)布的JDK14和JDK15兩個版本，雖然不是TLS版本，但是作為JDK17 LTS發(fā)布前的特性預(yù)覽，大家可以通過這兩個版本中發(fā)布的各種重要特性窺探到Oracle對于Java后續(xù)發(fā)的規(guī)劃思路。從JDK 9開始，Oracle JDK每半年就會更新一次，每次發(fā)布新的Oracle JDK后其對應(yīng)的Open JDK也會隨之進行半年時間的更新。
在這里插入圖片描述
在JDK 14、JDK 15兩個版本中個人覺得比較重要的幾個特性更新包括：

    關(guān)于垃圾回收器的更新：CMS垃圾回收器正式被剔除，ParallelScavenge + SerialOld GC 的組合模式被棄用，ZGC垃圾回收器轉(zhuǎn)正，G1回收器得到優(yōu)化后依然是默認的垃圾回收器。

    關(guān)于模式匹配語法的使用：模式匹配語法已經(jīng)是連續(xù)兩次發(fā)布預(yù)覽版本，那么大概率會作為正式特性出現(xiàn)在JDK17版本中。匹配模式是對instanceof修飾符的語法優(yōu)化。

    關(guān)于NullPointerExceptions異常的完善：更完善的NullPointerExceptions異常將快速幫助使用者定位出現(xiàn)空指針的位置，既是使用多個連續(xù)方法進行調(diào)用時，也可以快速定位。

    依賴封閉/接口封閉：實際上接口封閉功能在JDK15之前的版本就有內(nèi)部應(yīng)用，這個版本只是將接口封閉功能作為預(yù)覽特性提供給最終使用者使用。個人估計在穩(wěn)定的JDK17版本中，該特性大概率會作為正式特性被發(fā)布。

    record緊湊語法：該特性也已經(jīng)連續(xù)兩次發(fā)布預(yù)覽版本了，也是大概率會作為正式特性在JDK17版本中進行發(fā)布。個人疑惑，緊湊語法不會是Oracle團隊借鑒了Lombok的功能特色吧~~

2、Spring生態(tài)
2.1、Spring Boot更新

2020年11月，Spring Boot發(fā)布了2.4.0版本，這是一個GA版本也就是正式發(fā)布版本，而且Spring Cloud也做了對應(yīng)匹配的更新。2.4.0版本開始支持JDK15的特性，但這個版本并不建議各位在正式環(huán)境立即更新。

實際上Spring Boot今年一共維護了兩個大版本2.3.1——2.3.6版本，以及2.4.1版本。作者目前在實際工作中使用最多的版本還是2.2.X的版本，而2.3.X的版本在最新的幾個項目中也有采用。從Spring 2.3.X版本開始，Spring Boot的構(gòu)建方式從Maven切換到了Gradle，這個是筆者之前的猜想是一樣的，作者在幾年前就在項目構(gòu)建過程中力推使用Gradle，并且在實施過程中得到很好的效果證明。

Gradle在多年前的使用份額上，已經(jīng)有快速追平Maven的趨勢，而Spring Boot的新版本采用Gradle進行構(gòu)建后，勢必會為Gradle的推廣起到正面示范效果。
在這里插入圖片描述
2.2、Spring Cloud更新

隨著Spring Boot的更新，Spring Cloud也發(fā)布了新的版本。2020年Spring Cloud發(fā)布了2020.0版本，該版本并沒有再使用之前Spring Cloud版本的命名方式（上一個Spring Cloud的版本命名為Hoxton，這些版本名都是以英國倫敦地鐵站進行的命名），新版本采用日歷化版本命名為2020.0.X。該版本中正式去掉了多個netflix集成的組件，例如netflix-hystrix、netflix-ribbon、netflix-zuul、netflix-turbine，只有netflix eureka得以保留（并且已經(jīng)不推薦使用），可見netflix在Spring Cloud的新版本中所占比重已經(jīng)是是越來越低了。

實際上Spring Cloud替換netflix各個組件的動作在之前的版本中已逐漸清晰，Spring Cloud官方也給出多個組件的替換方案（列舉這些替換方案后，可以看到，Spring大社區(qū)的技術(shù)棧更新真的很快，稍不留神就容易遺漏更新，再稍不留神就容易內(nèi)卷）：

    服務(wù)注冊中心：
    Nacos，來自于SpringCloudAlibaba，之前如果已經(jīng)在項目中使用的Consul，那么建議繼續(xù)使用；如果是新的項目或產(chǎn)品，建議切換到Nacos上來；其它還在支持的組件包括zookeeper、Consul；Eureka已經(jīng)不建議使用，如果仍然在項目或者產(chǎn)品上使用，則可以考慮以最小的技術(shù)代價盡快完成升級。個人認為Nacos之所以會后來居上，它的集成度很高，顯著減少了使用者的學(xué)習(xí)成本是很重要的一個方面

    服務(wù)調(diào)用：
    openFegin，有的讀者容易混淆openFegin和Fegin，這兩者不是一回事，F(xiàn)egin是netflix提供給Spring社區(qū)的組件，目前已被openFegin替換掉

    調(diào)用負載：
    LoadBalancer，在新版本中已經(jīng)正式替換掉Ribbon

    熔斷與升降級：
    Resilience4J和Sentienl都是最新版本中官方推薦的可選版本，其中Sentienl來源于SpringCloudAlibaba，國內(nèi)的使用資料和討論資料也更多一些，建議可以使用Sentienl替換Hystrix，當然，如果讀者所在組織的替換成本比較高，那么建議可以分步驟進行，畢竟Hystrix之前存在了較長一段時間

    服務(wù)網(wǎng)關(guān)：
    實際上個人來說，之前各個項目和產(chǎn)品中使用zuul還是用得比較順手的，但后面隨著更多的產(chǎn)品和項目的研發(fā)執(zhí)行，作者也開始轉(zhuǎn)向gateway的使用。確實好用，推薦使用

    服務(wù)配置：Config組件依然存在于Spring Cloud的最新版本中，但如果讀者所在組織使用的是Naos，那么建議可以使用Nacos進行功能替換

其余不再列舉，總結(jié)一下Spring Cloud的發(fā)展趨勢：組件集成度逐漸升高，初始版本中由netflix提供的各種組件已被逐步移除（主要原因是后者更新頻度無法滿足Spring社區(qū)的要求），SpringCloudAlibaba提供的組件在Spring社區(qū)所占份額逐步提升，甚至可以猜測不久的將來SpringCloudAlibaba和原生Spring Cloud兩者的技術(shù)線路會逐步合并。實際上讀者直接使用SpringCloudAlibaba就是一個不錯的選擇
3、周邊動態(tài)
3.1、IDE工具更新：

Eclipse最近幾年使用份額掉的非常厲害，最主要的原因就是大多數(shù)開發(fā)人員轉(zhuǎn)向了 Intellij IDEA，雖然后者的商用版是付費的，但并不影響開發(fā)人員的使用熱情（你懂的）。不過個人認為Eclipse和IDEA兩個主要的開發(fā)工具并沒有誰絕對勝出的說法，廠商支持和社區(qū)活躍度起到了主要的影響作用，選擇哪個工具還是看個人喜好，畢竟想靠換一個工具就get新技能的想法有些幼稚。

2020年12月Intellij發(fā)布了IDEA的最新版本2020.3（包括多個編輯器），這樣一來2020年Intellij IDEA一共就發(fā)布了3個可用版本。這個版本新增/修改了多個特性，包括：

    歡迎頁發(fā)生了明顯的變化，在歡迎頁上新增了學(xué)習(xí)選項卡，以便于使用者對IDEA的使用學(xué)習(xí)。

    IDEA對Git的支持已經(jīng)非常完整了，直接將Git選項集成到了頂層菜單中，并且在搜索選項卡中新增了單獨的Git搜索結(jié)果項。

    其它優(yōu)化項諸如代碼表情、閱讀器模式、調(diào)試功能改進、性能分析器、內(nèi)存快照等等。
    在這里插入圖片描述

3.2、Centos 8 將很快停止維護

CentOS 8將于2021年停止更新，不過CentOS 7還是會支撐到2024年，所以目前使用量最大的CentOS 7版本的用戶暫時不會受到影響。另外CentOS 8 停止更新后，使用者可以選用CentOS Stream 8在非生產(chǎn)環(huán)境進行替換。不過，個人認為最好的選擇是直接切換到Ubuntu server。
3.3、企業(yè)應(yīng)用方面，中臺化大行其道

小前臺、大中臺實際上是阿里2015年開始在內(nèi)部推行的技術(shù)戰(zhàn)略，到了18年各個行業(yè)看著阿里的成功經(jīng)驗后也開始逐步解決這樣的資源集中化解決方案。零售、物流、快消品、耐消品、互金等等行業(yè)，都有一批企業(yè)開始試行中臺化線路。還有一批IT企業(yè)也開始精耕于企業(yè)級中臺化解決方案，并向客戶大肆宣傳自己的成功案例。但是真的所有企業(yè)都適合做中臺嗎？筆者持懷疑態(tài)度。要知道阿里所宣推的中臺，也只是電商行業(yè)的中臺，簡稱電商中臺。

單純從技術(shù)層面來考慮，中臺化戰(zhàn)略涉及到對企業(yè)中若干系統(tǒng)的整合問題，但并不是所有企業(yè)都具有阿里那樣快速的系統(tǒng)迭代特性，就筆者個人所接觸的客戶，一些客戶還在使用10年前的老系統(tǒng)，這些系統(tǒng)的集成將是比較困難的技術(shù)問題；從業(yè)務(wù)層面考慮，并不是所有的企業(yè)都有幾十個業(yè)務(wù)系統(tǒng)，上千個業(yè)務(wù)流程，對單一幾個系統(tǒng)的中臺化是否可以達到簡化業(yè)務(wù)的目的？從IT團隊人力資源的角度看，算了，不看了。

一年的時間又過去了，疫情的影響無論是對個人還是行業(yè)都是很明顯的，程序員應(yīng)該要多多考慮如何避免內(nèi)卷的問題，要多多考慮自身抵御風(fēng)險的能力，不要在舒適區(qū)待得太久。2021，與君共勉。
————————————————
版權(quán)聲明：本文為CSDN博主「說好不能打臉」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/yinwenjie/article/details/112424912