很有意思的一個事情是，研發(fā)同學(xué)往往并不直接與客戶打交道，多數(shù)市場動向和認知觀察也往往來自于市場部門或開發(fā)者關(guān)系，但技術(shù)發(fā)展的趨勢往往卻與商業(yè)化直接掛鉤，這就導(dǎo)致了一個很有意思的現(xiàn)象，即——運營/市場拿著研發(fā)一半的工資，卻還要時刻掌握市場動向，行業(yè)脈搏，用工程師能聽懂的語言反哺給研發(fā)，最終保證技術(shù)發(fā)展、產(chǎn)品迭代的路線不至于出現(xiàn)大的紕漏。
這對于做開發(fā)者社區(qū)的同學(xué)來說，是先天的弊病和必須的要求，也是開發(fā)者運營同學(xué)實現(xiàn)個人品牌能力和增值的一大出路。所以，其實各個行業(yè)都類似，愿意保持思考，持續(xù)學(xué)習(xí)的人，總是可以跑贏很多人，研發(fā)同理。
廢話不多說，切入今天的正題。
1、集中式基礎(chǔ)設(shè)施：云優(yōu)先是新的規(guī)范
同往年一樣，第一條預(yù)測依舊跟云有關(guān)，今年在基礎(chǔ)設(shè)施這個關(guān)鍵詞前面多出了一個集中式（Centralized）的前綴，這跟當前云計算行業(yè)的下沉還是有關(guān)系的，如果關(guān)注互聯(lián)網(wǎng)行業(yè)比較多的人，可能會覺得分布式云是現(xiàn)在的發(fā)展趨勢，但其實對于正在數(shù)字化轉(zhuǎn)型的非互聯(lián)網(wǎng)行業(yè)而言，集中式的基礎(chǔ)設(shè)施仍舊是第一選擇。
2022年，仍舊會是公有云快速發(fā)展的一年，Gartner預(yù)測2022年公有云的收入將增長16%，在互聯(lián)網(wǎng)以外的各個行業(yè)，金融、政務(wù)、出行、工業(yè)、民生等多個行業(yè)，公有云都會得到有效的利用。所以如果你是非互聯(lián)網(wǎng)企業(yè)的決策者或從業(yè)者，現(xiàn)在開始認真關(guān)注云計算還來得及。
2、去中心化基礎(chǔ)設(shè)施：邊緣的云
邊緣計算開始被廣泛關(guān)注，大概也就是最近兩年的事情，我看了一下2019年做的那篇趨勢預(yù)測里，其實沒有寫邊緣計算，但2021年的版本里已經(jīng)有了。跟公有云希望將存儲、計算能力和AI/ML集中在一個中心位置（可用區(qū)域）的特點不同，邊緣計算本身是一種去中心化的方式，它希望將存儲、計算能力和AI/ML部署在靠近用戶的地方。低延遲場景(游戲)、低網(wǎng)絡(luò)帶寬(離岸站點)、無網(wǎng)絡(luò)、監(jiān)管要求、實時用例(聯(lián)網(wǎng)車輛)、智能設(shè)備(物聯(lián)網(wǎng))這些都是需要邊緣計算的場景。
再加上5G和Web 3等關(guān)鍵技術(shù)的興起，邊緣計算在2022及以后得到廣泛采用是很合理的預(yù)判。事實上最近兩年各大云廠商已經(jīng)在開始有意識地推邊緣計算的能力和產(chǎn)品了，我印象中國內(nèi)幾大云廠商都有相關(guān)的案例，比如我之前采訪過的華為云的KubeEdge。
Kamaruzzaman提到了一項比較關(guān)鍵的動議——“State of the Edge”，旨在標準化邊緣計算技術(shù)?！皹藴驶边@個詞是我特別敏感的一個點，因為從商業(yè)化的角度看，在沒有實現(xiàn)事實標準之前，商業(yè)化的拓展往往是雜亂無序或者說沒有核心優(yōu)勢的，而形成事實上或人為認定的標準以后，商業(yè)化的動向才能更為明朗。畢竟三流企業(yè)做產(chǎn)品，一流企業(yè)做標準。
3、公有云：多云將獲得更多的動力
阻礙企業(yè)上云的一大絆腳石，就是廠商鎖定的問題。畢竟云廠商在商業(yè)信譽這塊上，總是或多或少存在一些黑歷史，要么硬盤壞了，要么剽合作伙伴方案，要么抄開源項目代碼。你把企業(yè)安身立命的核心資產(chǎn)、數(shù)據(jù)都放在某一家云上，且不說安全的問題，以后要想遷移都是個麻煩。
所以多云、混合云的發(fā)展趨勢是實實在在肉眼可見的，Kamaruzzaman提到了很多致力于提供云服務(wù)中立性的API服務(wù)，比如MinIO（兼容S3）、Aviatrix（云原生網(wǎng)絡(luò)）、Volterra（分布式云服務(wù)）、LightOS（云原生存儲）等。
還有一點比較有意思的是，Google正在致力于將他們的流行服務(wù)，比如Big Query引入到其公有云競爭對手AWS、Azure里，但這種現(xiàn)象在國內(nèi)的云計算行業(yè)是否有類似案例或者說未來會不會有類似案例，我個人表示懷疑……
4、容器：K8s將成為基礎(chǔ)，而Docker將會反彈
如果要對現(xiàn)代IT產(chǎn)業(yè)的關(guān)鍵技術(shù)做個排名，容器毫無疑問將占據(jù)一席之地。在容器化技術(shù)的普及化中，K8s發(fā)揮了巨大的作用。背靠大廠（Google）、足夠努力、精心設(shè)計、快速迭代，才有了今天成為事實標準的K8s。
但另一方面，隨著K8s技術(shù)的成熟，未來關(guān)于K8s本身的吸引力會持續(xù)減少，這有點類似于跨越鴻溝理論中的技術(shù)采用生命周期，K8s我認為已經(jīng)到了晚期大眾這個階段。所以Kamaruzzaman表示，K8s已經(jīng)成為現(xiàn)代軟件開發(fā)的引擎，但也由于其本身的成熟度而導(dǎo)致進展緩慢。從這個角度看，有點類似于Java。
Docker是另一個在容器化歷史進程中發(fā)揮了關(guān)鍵作用的技術(shù)，不幸的是，即便在全盛時期，Docker也沒有找到商業(yè)化的終南捷徑，加上公司一系列的騷操作，在與K8s的正面對決中敗下陣來。
2022年起，Docker宣布推出新的訂閱模式，繼續(xù)做著商業(yè)化的艱難探索。坦白說，這個小標題預(yù)測的結(jié)論并非定論，更多是Kamaruzzaman基于Docker的歷史功績提出的美好祝愿，我其實也一樣。Docker是我對開源行業(yè)產(chǎn)生濃厚興趣的開始，希望它能有一個好的未來。
延展閱讀：
Docker麻煩大了
5、網(wǎng)絡(luò)安全：每個人都會認真對待安全
對初創(chuàng)公司或者中型公司來說，網(wǎng)絡(luò)安全就像“房間里的大象”，他們可以看到網(wǎng)絡(luò)安全的需求，卻沒有足夠的資源去實現(xiàn)他。這其實也是公有云能迅速落地下沉的一大原因，初創(chuàng)企業(yè)不需要自己去搭建底層的基礎(chǔ)設(shè)施，也省去了網(wǎng)絡(luò)安全的防護，只要部署在公有云上就行，其他的事交給云廠商。
可當云廠商遭到網(wǎng)絡(luò)攻擊，或者出現(xiàn)故障時，受到影響的就絕不只是一家公司而已。事實上，2021年曝出來的云廠商高危漏洞也不在少數(shù)，2022年公有云廠商和Linux都要在安全方面更努力地工作。
除了云安全，另一個常見的網(wǎng)絡(luò)安全來源于開源軟件。之前奇安信有過相關(guān)數(shù)據(jù)報告，90%的開源軟件存在安全漏洞，這對于在開源軟件基礎(chǔ)上構(gòu)建起來的互聯(lián)網(wǎng)本身就是個令人不寒而栗的問題。幸運的是，高危漏洞的利用沒有那么容易。不幸的是，很多世界流行的開源軟件，背后的維護者甚至只有兩三個人，比如2021年最受關(guān)注的log4j漏洞，影響了全世界近一半的IT公司。
我們需要思考一個問題，為什么世界流行的開源項目卻得不到應(yīng)有的收益？為眾人抱薪者，不可使其凍斃于風(fēng)雪。
6、區(qū)塊鏈：加密貨幣之外的生活終于開始了
區(qū)塊鏈經(jīng)常與加密貨幣聯(lián)系在一起，每次有人被加密貨幣嘎了腰子，就有人開始痛罵區(qū)塊鏈技術(shù)。但從技術(shù)上來講，加密貨幣只是區(qū)塊鏈技術(shù)的一個實現(xiàn)方式，卻并非區(qū)塊鏈的全部或唯一用例。
2021年區(qū)塊鏈一個非常流行的新用例是NFT（Non-Fungible Tokens），之前勇士隊球星庫里花了18萬美元買了一張NFT的頭像就火出了圈。雖然，我也不懂這玩意兒貴在哪了……
NFT目前更多用在數(shù)字藝術(shù)方面，但顯然可以期待它未來的使用場景。從這個點延伸出去可以看到，區(qū)塊鏈技術(shù)正在越來越為人所正視，注意是正視。IDC預(yù)測2022年區(qū)塊鏈技術(shù)的解決方案增長將達到75%，考慮到目前該項技術(shù)的普及程度，我覺得這個數(shù)字不算盲目樂觀。
區(qū)塊鏈一個為人所詬病的點在于能源消耗，在國內(nèi)雙碳政策的前提下，區(qū)塊鏈要想獲得長遠發(fā)展，必然還是需要做出一些改變的，像以太坊那樣，在2022年由能源密集型的“proof of work”模型轉(zhuǎn)向綠色的“proof of stake”模型。
7、機器學(xué)習(xí)：AutoML和無代碼人工智能將使機器學(xué)習(xí)民主化
我之前策劃「稀土開發(fā)者大會」的時候，用過一句文案叫「機器都在學(xué)習(xí)，你憑什么例外」。這個點說的就是機器學(xué)習(xí)，但從實際的行業(yè)發(fā)展來看，機器學(xué)習(xí)的應(yīng)用規(guī)模還是受到不小的制約，最大的原因是——搞機器學(xué)習(xí)的專家太少了。第二個原因是——大多數(shù)公司不需要完全的機器學(xué)習(xí)，有限的使用就夠了。
AutoML就是在有限情況下實現(xiàn)機器學(xué)習(xí)使用的一種方式。某種意義上，它就相當于低代碼/無代碼，不同之處在于，低代碼/無代碼是降低開發(fā)的門檻，而AutoML是降低機器學(xué)習(xí)的使用門檻。
8、人工智能：狹義人工智能將被廣泛采用
我最近在看阿西莫夫的科幻系列，里面提到過的「機器人三大準則」、由機器人協(xié)助建立的行星文明等等故事，講述的就是人工智能的終極目標之一——讓AI可以和人一樣聰明，甚至更聰明。但從AI發(fā)展的60多年歷程里，我們離這個目標還差得遠。
跟機器學(xué)習(xí)一樣，深度學(xué)習(xí)在過去十年間獲得了大量采用和快速增長，預(yù)計在未來仍將如此。人工智能發(fā)展的終極目標在肉眼可見的當前觸不可及，但讓人工智能代理在特定領(lǐng)域協(xié)助/增強人類還是問題不大的。
9、深度學(xué)習(xí)庫：TensorFlow將繼續(xù)統(tǒng)治
深度學(xué)習(xí)的輪子有很多，但你基本上可以只看這兩個：Google的TensorFlow，Meta的PyTorch。
TensorFlow在其2.0版本中進行了自我更新，并引入了動態(tài)圖形、Python友好和許多其他變化。它還提供了Tensorflow.js以在瀏覽器中使用AI庫。其另一個創(chuàng)新是Tensorflow Lite，它提供了在移動和Web上部署Tensorflow的功能。Tensorflow還發(fā)布了Tensorflow Extended(TFX)，這是一個用于部署生產(chǎn)ML管道的端到端平臺。
PyTorch是另一個主要的人工智能庫，它引入了動態(tài)圖形和Python，對開發(fā)人員也更友好。它還發(fā)布了PyTorch Mobile，支持在Android/iOS設(shè)備上使用PyTorch。它通過PyTorch Profiler為開發(fā)人員提供了更多的友好性來調(diào)試大型AI模型。
從Stack Overflow的調(diào)查數(shù)據(jù)來看，TensorFlow繼續(xù)保持統(tǒng)治地位似乎并沒有什么懸念。
10、數(shù)據(jù)庫：多模型、多用途數(shù)據(jù)庫正在興起
過去幾年間，數(shù)據(jù)庫領(lǐng)域的一個趨勢就是用一種特定的數(shù)據(jù)庫去匹配特定的用例，比如：
RDBMS：用于結(jié)構(gòu)化數(shù)據(jù)的事物
Wide-Column Database：用于低延遲，分布式數(shù)據(jù)庫
Key-Value Store：用于分布式緩存
Graph Database：用于極端關(guān)系數(shù)據(jù)
Document Database：用于具有半結(jié)構(gòu)化數(shù)據(jù)的事物
Distributed SQL：用于具有事務(wù)保證的低延遲，分布式數(shù)據(jù)庫
OLAP Database：用于數(shù)據(jù)倉庫和數(shù)據(jù)分析
這種方法的一個缺點是，我們經(jīng)常需要為一個應(yīng)用程序使用多個數(shù)據(jù)庫。現(xiàn)在有一個新的趨勢，即每個數(shù)據(jù)庫將提供一個以上的模型并服務(wù)于一個以上的用例。PostgreSQL(Multi-Model)、Azure CosmosDB(Multi-Model,Multi-purpose)、SingleStore(OLAP和OLTP)是這些數(shù)據(jù)庫的先驅(qū)。
11、數(shù)據(jù)密集型計算：Spark VS公有云
Kamaruzzaman介紹道，Apache Spark幾乎已經(jīng)取代Hadoop生態(tài)系統(tǒng)成為默認的數(shù)據(jù)密集型計算框架。Spark還使用相同的API提供接近實時的流處理。
另一個獲得很多關(guān)注的開源框架是Apache Beam，其提供了一個統(tǒng)一的編程模型來定義和執(zhí)行數(shù)據(jù)處理管道：批處理和流處理。這個背后的身影少不了GCP、Azure和AWS。
所以如果你不想用云，或許只有Spark一個選擇。
12、實時流計算：Flink VS公有云
這個點的意思跟上一條頗為類似，簡單來說就是，實時流計算這里，除了Flink啥都不推薦。即便要在公有云上用，也建議用Flink，感覺無腦上就行了。話說回來，確實在這個領(lǐng)域里我目前也沒見過有能跟Flink掰掰手腕的輪子。
13、DevOps：現(xiàn)代DevOps的智能可觀測性
幾年前，可觀測性只對大型企業(yè)至關(guān)重要。然而，伴隨著云本地開發(fā)和微服務(wù)架構(gòu)的迅速崛起，可觀測性對整個現(xiàn)代軟件開發(fā)都至關(guān)重要。除了傳統(tǒng)的日志記錄、監(jiān)控、跟蹤，還需要K8s集群的遙測、拓撲數(shù)據(jù)等等。
其實DevOps這種理念一直處在持續(xù)的發(fā)展中，當它跟AI結(jié)合時就變成了AIOps，當它強調(diào)安全時，就有了DevSecOps，輪子的實現(xiàn)有各種形態(tài)，歸根結(jié)底還是看需求是什么。
14、快速應(yīng)用開發(fā)：低代碼/無代碼(LCNC)將繼續(xù)蓬勃發(fā)展
低代碼/無代碼（Low Code/No Code，簡稱LCNC）旨在降低開發(fā)Web/移動應(yīng)用的障礙，而無需開發(fā)人員（或少量開發(fā)人員）。在未來的幾年里，我們?nèi)匀恍枰_發(fā)人員來開發(fā)應(yīng)用程序。但也有很多用例表明，低代碼/無代碼框架/工具確實可以顯著加快應(yīng)用程序開發(fā)。
整個2021年稱之為低代碼元年都不為過，這一年光是我見過的低代碼創(chuàng)業(yè)公司就不下三五家，一場關(guān)于低代碼是否業(yè)界毒瘤的爭論更是引爆了行業(yè)沸點。預(yù)計2022年，這些場景下會有更多低代碼/無代碼的身影：
Web/移動App開發(fā)
網(wǎng)站和登陸頁面
使用對話流的智能聊天機器人
電子商務(wù)
機器學(xué)習(xí)
人工智能(視頻、音頻、圖像)
工作流管理
使用RPA的過程自動化
15、軟件架構(gòu)：面向企業(yè)的微服務(wù)和微前端
目前主流的后端架構(gòu)有三種選擇：單體、微服務(wù)和Serverless，三者各有優(yōu)勢、劣勢和適用的場景。對于微服務(wù)而言，其是云原生場景下絕佳的架構(gòu)選擇，從企業(yè)發(fā)展角度來看，不論是上云后的改造，還是云原生的架構(gòu)設(shè)計，都以微服務(wù)為首選。
前端領(lǐng)域的程序復(fù)雜性往往受到輕視，而微前端的思想內(nèi)核跟微服務(wù)是一樣的，都是為了解決復(fù)雜性而生，化整為零。因此可以暢想的是，微前端也會是未來前端開發(fā)的首選架構(gòu)模型，另一個好消息是，主流的JS框架都支持微前端。
16、軟件開發(fā)：人工智能將協(xié)助開發(fā)人員和QA
軟件開發(fā)本身很有意思的一個地方在于，開發(fā)人員不喜歡做那些乏味的、可預(yù)測的、重復(fù)的臟活累活，所以各種輪子應(yīng)運而生。研發(fā)們享受的是創(chuàng)作解決問題的解決方案，而非享受問題。人工智能在實現(xiàn)終極目標之前，更多的價值往往就體現(xiàn)在這些地方上，比如使用GPT-3和NLP庫自動地完成這些任務(wù)。
另外就是去年剛推出的一些自動生成代碼的工具，比如GitHub的Copilot。很多人喜歡玩梗說，AI已經(jīng)可以自己寫代碼，自己Debug了，程序員還有人要嗎？但實際上目前AI的能力仍舊是狹義層面的，但如果你只能、只會做臟活累活，那你確實比較危險，不是嗎？
17、編程語言（主流）：Python將引領(lǐng)潮流
我剛?cè)胄心菚海琍ython還沒今天這么火，那個時候大家討論的是Java和C語言，甚至Go語言在中國的熱度感覺都不比Python差?？梢凰仓g，Python就在TIOBE編程語言排行榜上干到了第一名：
Python具有簡潔、解釋性、動態(tài)、門檻低等特性（然而我卻沒學(xué)會，從入門到放棄），這些在Python之禪里都有很直觀的體現(xiàn)，更關(guān)鍵的是，Python并不僅僅局限在軟件開發(fā)行業(yè)里，很多做數(shù)據(jù)、圖表的行業(yè)同樣可以用Python實現(xiàn)很多工作。加上數(shù)據(jù)科學(xué)的火熱，Python的火爆不難理解。2021年P(guān)ython的登頂不會是曇花一現(xiàn)，懸念或許在于，以后誰會把它頂下來？我個人期待Rust。
18、編程語言（企業(yè)）：Java反擊
主流的企業(yè)級編程語言，很長一段時間里代名詞就是Java。Java的語言設(shè)計，JVM的強大，共同構(gòu)筑了Java生態(tài)。但在云原生興起以來，Java其實受到了非常大的挑戰(zhàn)。我年前發(fā)過一條朋友圈專門聊過這個話題：
目前看有兩個技術(shù)趨勢會對Java造成比較大的影響，一個是云原生，一個是Serverless。造成影響的原因跟Java語言的特性有關(guān)，這門語言設(shè)計就是為了大型應(yīng)用復(fù)雜場景，而云，尤其是Serverless，更加適合輕量化、業(yè)務(wù)邏輯簡單的應(yīng)用。話說回來，其實制約云原生和Serverless發(fā)展的，也恰恰是在大型應(yīng)用復(fù)雜場景下的管理問題、安全問題。
一個好消息是：Java社區(qū)一直在持續(xù)地迭代創(chuàng)新，保證Java的生命力。比如GraalVM等現(xiàn)代化的特性，在Java近幾年保持周期發(fā)布的當下，憑借現(xiàn)代化特性的更新和嚴格且無與倫比的向后兼容性，你可以不用再問Java老矣，尚能飯否。而是，接著奏樂，接著舞！
19、客戶端Web框架：面向企業(yè)的React和Angular
前端三大框架早已是耳熟能詳?shù)拇嬖冢簛碜訫eta的React，來自Google的Angular和來自尤雨溪的Vue。Kamaruzzaman給出React和Angular會在企業(yè)中得到更多重用，而非Vue的原因是：前兩者背靠兩大企業(yè)，而Vue過于依賴尤雨溪，且提到了Vue的安全考慮。
我不知道這個安全考慮指的是軟件方面的安全，還是地緣方面的安全，這里不做評價。但我想提的是，如果Vue在過于依賴尤雨溪的情況下，仍舊做到了如此流行，豈非更加說明Vue的牛逼所在？你覺得呢？
20、服務(wù)器端框架（Java）：用于微服務(wù)和無服務(wù)器應(yīng)用程序的本地框架
Spring MVC/Spring Boot是Java里最主要的服務(wù)器端框架，它遇到的問題跟Java遇到的問題是伴生問題，因為Java受到了云原生趨勢的挑戰(zhàn)，導(dǎo)致了它的問題。在Redhat推出Quarkus后，云原生開發(fā)的首選框架易主，因為后者使用了GraalVM而非傳統(tǒng)的OpenJDK。終于，Spring也聲明了將發(fā)布Spring Native，同樣使用GraalVM進行云原生開發(fā)。
2022年如果開發(fā)云原生Java應(yīng)用程序，可以考慮使用Java原生框架。如果場景仍舊是單體Java應(yīng)用開發(fā)，繼續(xù)使用傳統(tǒng)框架亦無不可。
21、應(yīng)用開發(fā)：更靈活的原生應(yīng)用
移動應(yīng)用開發(fā)一直是個龐大的市場，并且仍將持續(xù)膨脹下去。目前主流的移動應(yīng)用開發(fā)有四種模式：原生開發(fā)、跨平臺開發(fā)、混合開發(fā)和云開發(fā)。
原生開發(fā)和跨平臺開發(fā)是應(yīng)用最廣的開發(fā)模式，前者提供了最大的靈活性，后者提供了“Write once，Run everywhere”的誘人可能。
去年寫過一篇蘋果發(fā)布會的文章蘋果：沒想到吧，我自己做了“小程序”，里面借著蘋果生態(tài)分析了一下原生開發(fā)的發(fā)展，重點在于其軟硬件的協(xié)同。Kamaruzzaman預(yù)測2022年原生開發(fā)將占據(jù)主流，重點在于跨平臺開發(fā)不如原生靈活。未來如何，且走且看。
22、API技術(shù)：REST、gRPC和GraphQL將共存
現(xiàn)代軟件開發(fā)通常是API驅(qū)動的開發(fā)?，API輪子可以說是多如牛毛，但知名度最高的也就這三個了：REST、gRPC和GraphQL。
這三個主流API技術(shù)，一個最古老，同時也是最成熟、最廣泛使用（REST）；一個由Google創(chuàng)建，在服務(wù)和服務(wù)通信方面更快更高效（gRPC）；一個由Meta開發(fā)，以為特定的用例定義數(shù)據(jù)結(jié)構(gòu)的形狀，并在一次訪問中獲取所有數(shù)據(jù)。
這簡直是完美體現(xiàn)軟件開發(fā)沒有銀彈一詞的場景，各有各的擅長，也各有各的弊病，企業(yè)按需使用，每個輪子都有前景。我們都有光明的未來！
