阿里雲智慧總裁張建鋒在2021雲棲大會分享

2021 年，雲原生取得很多重要進展。2022 年又有哪些值得關注的趨勢？阿里雲資深技術專家李國強（嶄巖）做客 InfoQ 影片號，對雲原生趨勢做了最新的解讀。以下根據直播內容整理，有不改變原意的刪減，完整內容可點選[此處](https://www.infoq.cn/video/zWxJ15PNDVtElqd1sgXL)檢視回放，以下內容轉載自 InfoQ，並補充了相關參考內容，供讀者更全面地瞭解和學習。

**2021 年，雲原生領域發生了哪些您比較印象深刻的事情？**

觀點：在 2020 年的時候，雲原生理念就被提到得越來越多，但我覺得真正呈現出爆發形態、真正被所有的雲廠商、使用者廣泛使用的是在 2021 年。2021 年發生了很多印象深刻的事情，可以挑兩件跟大家分享。

第一個，分散式雲在 2021 年有了比較大的爆發。不管是使用者使用還是各個雲廠商的技術支援方面，都呈現出了非常火熱的趨勢。為什麼呢？我覺得這跟大家業務形態的發展聯絡非常緊密。直播、5G、IoT 等領域的興起，讓業務對於雲的形態需求更高，大家希望雲能夠更貼近資料的產生點，因此相應的邊緣雲、本地雲、混合雲的形態越來越多。現在，整個雲端計算有一個很重要的趨勢，就是呈現一雲多形態的模式，使用者在各個地方都能用到雲端計算的能力。但這也對雲的基礎設施提出了比較大的挑戰。使用者以前就是用一朵雲，管理複雜度是可以接受，但多朵雲形態後，挑戰難度就比較大了。

雲原生技術天然能夠比較好地解決雲變成多形態後的統一介面管理問題，包括混合雲帶來的複雜度挑戰。所以各個雲廠商在這方面的投入非常大。亞馬遜的 EKS Anywhere 在今年 9 月上線，阿里雲也在今年 9 月釋出了 ACK Anywhere，兩者本質上都是提供更加完備的方案讓使用者可以在一朵雲的模式下使用多朵雲。業務場景驅動了技術的普遍落地。

![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/82c029f178c7450988cee5d8e89862a5~tplv-k3u1fbpfcp-zoom-1.image)

第二個，2021 年，頭部網際網路公司的雲原生落地到達了一個里程碑式的關鍵節點，代表性事件就是各大網際網路公司基本完成了雲原生化，所有業務百分之百上雲。如今，雲原生的核心技術如容器、微服務、服務網格等的可用性和成熟度都已經可以支撐起頭部網際網路的體量。每個行業的雲原生進度不一樣，頭部網際網路公司跑得比較靠前，基本都做到了全面雲原生化。未來幾年，其他行業會逐步追隨網際網路的腳步全面走向雲原生化。

**有人說，雲原生乃至整個雲端計算就是標準之爭。您怎麼看待這句話？這場“戰爭”您認為結束了嗎？**

觀點：這個是蠻有意思的話題。實際上，現在雲原生領域的開源是非常火的。CNCF 裡面有非常多的開源專案，裡面的專案已經超過一千了。這麼多開源專案的標準到底和雲端計算公司是什麼關係？在我個人看來，我不會把它定義為標準之爭，因為標準演進的作用對於雲廠商和使用者來講都是非常關鍵，只有標準化後，才能真正實現規模化和效率的提升。未來，不管是雲廠商還是其他企業，大規模、高效率的方向一定是標準化。

在雲原生領域有幾個比較關鍵的標準。最早出現的是容器，解決了應用打包標準化和應用釋出標準化的問題。在此之前，虛擬機器等方式的標準化程度是不夠的，Docker 終結了這一問題。隨著 Docker 的不斷演進和推廣，在應用編排、資源排程等又出現了新的問題，當時的 Docker  Swarm、Mesos 和 Kubernetes 互相競爭，最後 Kubernetes 勝出，並帶來了新的資源編排方面的事實標準。今天的 Kubernetes 已經成為一個事實標準。而應用層之前也是百家爭鳴的情況，每個企業都在做自己的雲原生應用，現在有越來越多的開源聲音和標準出現，如 Open  Application  Model 等，大家都在嘗試定義應用層的標準。

[KubeVela 1.1 釋出，開啟混合環境應用交付新里程碑](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247516026&idx=1&sn=c89c579db5afe83956eeb8ef6646b17a&chksm=fae6b4b5cd913da319f7f598f2990c6201721ac6e8f25555e4fd6103736b4044b7297b372b16&scene=21#wechat_redirect)

2000 年或者更早的時候，標準化的玩法是，一些組織設立標準委員會去制定。今天標準的定製流程更多的是先有開源專案，當開源成為事實標準後，大家來 Follow。國內還會有一些相關的部門參與標準的制定和推廣。對我來講，標準化更多的是企業和生態的協作，推動整個雲端計算和雲原生技術體系更加規模化和普適化。

**雲原生領域有什麼趨勢會延續到 2022 年？**

觀點：雲原生領域真的是太豐富了，有非常多的東西會延續到下一年，包括前面講到的分散式雲。我還是非常看好分散式雲裡的邊緣計算場景的，為什麼呢？因為這個場景正變得越來越豐富。例如，大家現在看文字內容越來越少，音影片越來越多，因此影片處理業務發展非常快，對邊緣計算的需求會越來越強烈。

邊緣計算作為雲端計算的延展會被應用到更多領域，同樣也會給基礎設施帶來很多的挑戰，比如有的邊緣側網路可能是弱網路，計算資源也不豐富，基礎設施怎樣在這種情況下發揮作用。雲邊協同的時候如何解決運維等問題。邊緣架構之下，容器在網路打通、彈性負載等方面可以發揮比較大的作用。這方面，雲廠商的投入也比較大，多個開源的專案如 OpenYurt、KubeEdge 等多個邊緣側開源專案進入 CNCF。2021 年，邊緣技術在從業務側和開源側的爆發比較強，我期望 2022 年無論是開源社群還是雲廠商的支援能力都可以有較大的變化和進展。

[OpenYurt 深度解讀｜開啟邊緣裝置的雲原生管理能力](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247516929&idx=1&sn=d27d3752d58219a44585bee740d4fc22&chksm=fae688cecd9101d8b0414dba583cb81ad11ee8c90a5194eff5587a769e5ebea53031a9471b46&scene=21#wechat_redirect)****

**有沒有邊緣計算的應用案例可以分享？**

觀點：案例是非常多的。網際網路業務中，大家熟知的像 CDN、音影片處理都是典型的邊緣場景。舉例來說，很多園區或工廠等會有影片採集，之後企業會做深入分析。工廠、園區、居民樓等是否能監測到安全違規行為就需要在影片採集後進行分析，最終發現問題。以前的流程是先採集影片，然後上傳到中心雲或者本地伺服器進行處理，但這已經不能滿足企業的需求了。現在，企業希望採集完後能夠就近處理這些影片資料，而不需要再上傳到中心雲端，以滿足網路延遲需求，以及降低網路傳輸的成本。這種場景下，邊緣容器能夠對不同場景進行算力管理，包括演算法下沉。

再比如電力行業有變電站這種分散在全國各地的基礎設施，如何對這些基礎設施進行算力管理、將業務快速部署到一些邊緣節點等屬於邊緣領域。以前變電站基礎設施升級可能需要人親自到那個地方去，效率很低。在雲原生化後，基礎設施管理及其上面的應用管理、演算法等都能用雲原生的方式解決，效率會大大提升。

[深信服智慧邊緣計算平臺與 OpenYurt 落地方案探索與實踐](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247520471&idx=1&sn=405215f007dffe2722dc21ba84497dd7&chksm=fae69b18cd91120e8d73d992f3db4d0a7df0d95b5b9c30654b374202ed38b69dd9bfbe49f42a&scene=21#wechat_redirect)

**隨著接入的服務越來越多，K8s 配置也越來越複雜。本來是解放生產力，現在好像被束縛了。您如何看待這個現象？這一年，大家對容器的應用還提出了哪些新的挑戰嗎？**

觀點：這個蠻有意思的。K8s 解決的是容器編排和資源排程問題，而這個問題對於企業來講本來就是非常複雜的，只不過 K8s 嘗試用雲原生的方式去重新定義應用的編排和資源排程，而且是比原來方案更好。現在，K8s 上的業務型別越來越豐富，從最初的無狀態到後來的有狀態，如今像 AI 這樣比較複雜的計算引擎也都放在 K8s 之上了，這就是一個相互促進的過程，這上面的負載型別越來越多，整個 K8s 體系也確實變得越來越複雜，但它能夠管理的東西也越來越多。如果未來使用者完全使用容器，那容器的複雜度必然會提升。

但對於企業和雲廠商來講，要做的就是在容器能做更多事情後去降低它的複雜度，要不然容器的門檻就會非常高。現在，各個廠商都在考慮從智慧運維角度做更多的努力。比如在叢集管理方面，如何用智慧運維的方式發現當前執行中的一些狀況，並且能夠給出處理辦法。現在也有智慧應用畫像和資源畫像方式提高資源利用率。智慧運維也是一個比較熱的方向。

還有一點，整個技術棧的變化會帶來整個企業組織的變化，很多時候是顛覆性的變化。

圍繞容器的生態可以認為是近十年最重要的 IT 技術的變革，它必然會引起一系列的變化，包括企業內部組織的變化。我們會看到，不僅整個運維管理體系在變化，企業內部也會出現新的組織形態，比如 Google 提出的 SRE 團隊就是為可用性負責。現在很多深度使用雲原生的企業，包括阿里，都有專門的 SRE 團隊，這個團隊會負責整個可用性相關能力的建設。其次，企業也會出現一些平臺橫向性的部門，基於雲原生體系去支撐上方業務的部門。以前有些企業可能是偏豎井式的業務單元，即一個業務單元下面有支撐團隊，容器包括 K8s 會讓企業內部有更多平臺橫向型部門的出現。這也是解決複雜度的一個方法，因為不是每個縱向的業務部門都有足夠的資源投入和專業度去解決這個問題。企業足夠大的時候一定要考慮在 SRE 層和平臺建設層形成橫向部門，進行職能分離。

**您預計，容器在 2022 年的技術研發重點會是什麼？對其未來的應用有哪些展望？**

觀點：今年還有一個很火的詞：綠色低碳。另外，今年整個網際網路有點像進入寒冬期，很多網際網路公司都提出了降本增效。降本已經成為很多企業 CTO 非常重要的 KPI，也成為技術發展的一個必然趨勢。

就降本角度來講，企業能做的事情非常多。從偏底層看，很多雲廠商和頭部網際網路公司在自研晶片，這塊的投入是非常大的，但軟硬一體確實會帶來降本增效。還有比較火的就是容器化作業系統，這個領域大概有六七年的歷史了，也是基礎設施層面一個比較重要的最佳化方法。

彈性是很多企業使用廣泛的降本增效的方法，特別是和雲廠商結合之後，彈性應用更加廣泛。目前，很多網際網路公司在嘗試離線上混部技術，本質上還是提高機器利用率。之前各個廠商在自建機房或者雲上購買伺服器的利用率往往都低於 10%。這個利用率並不高，很多企業嘗試去推高這個水平線，但推高水平線必然會帶來很多技術挑戰，比如利用率高了之後，多種負載混合跑時，是否會互相影響。幾大廠商都在透過開源或商業化產品形式嘗試輸出離線上混部（多種負載混合部署）技術，我相信離線上混部技術在明年將迎來進一步的產品化。

現在有一個概念叫 FinOps，即面向成本的應用和管理。這方面，目前在做的就是成本視覺化，比如瞭解企業內部幾個部門分別在雲廠商或本地機房成本是多少、不同業務成本是多少等。

開源方面有一個專案 Kubecost，從開源角度去提供這樣的能力。雲廠商會在容器服務裡提供“成本中心”，幫助使用者把雲賬單和叢集關聯起來，能清晰地看到每個部門、每個業務的成本，甚至據此給出一些建議。這很適合不同業務混合部署場景。成本管理明年也會看到一些發展。

還有一個比較有意思的事兒，國外雲廠商提出來一個概念叫 Carbon Bills，就是碳賬單，它把企業成本消耗都轉成了碳賬單的形式，這也是個比較有意思的方向。

降本這件事情是所有企業永遠的訴求，不過當企業在高速發展的時候這個訴求沒有那麼強烈，會以業務先行。隨著業務進入平穩期或者遇到困難時，降本需求會更明顯。

**Serverless 的應用場景多樣化差異比較明顯，這會影響該技術的通用性和可複用性嗎？為什麼？**

觀點：Serverless 也是最近大家談得比較多的話題。首先想先和大家聊聊什麼是 Serverless，因為每個人對 Serverless 的理解不一樣。有些人會把 Serverless 簡單理解為函式計算，確實最早時候亞馬遜推出的 AWS Lambda 就是函式式計算產品，並把它定義為 Serverless。但實際上，今天的 Serverless 範圍確實越來越廣，Serverless 本質上來講是一種設計理念，已經不僅僅是函式計算範疇了。

現在，市面上有面向函式計算的 Serverless 產品，也有面嚮應用的 Serverless 產品，如國外雲廠商推出的 App Runner、國內的 Serverless 應用引擎等，讓使用者對偏傳統的應用不需要做改造就可以使用 Serverless 架構，也不用關心底層的 IaaS 基礎設施。此外，還有面向 K8s 的 Serverless 產品，使用者可以透過 K8s 的介面使用 Serverless，還有面向容器的 Serverless，即用來交付容器例項的 Serverless。這些產品的本質都是讓使用者以一個介面使用雲資源，而不必關心底下的基礎設施。Serverless 多樣化給使用者帶來了更多的選擇。

還有一個比較大的趨勢就是越來越多的雲產品也在變得 serverless 化。如果大家關注了亞馬遜的 re:Invent 就會發現，很多雲產品本身也在 Serverless 化，比如推出了 Kafka 的 Serverless 版本。這意味著，使用者在實際使用雲產品時，完全不需要關注雲產品本身的規模，直接按照按量付費即可。

[打破 Serverless 落地邊界，阿里雲 SAE 釋出 5 大新特性](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247516957&idx=1&sn=1642d2aeaacaf6e8519a1b78271b1854&chksm=fae688d2cd9101c4bbcadf21f4b91151e2df0d882b6e9ffb49e04ddb1d3d948c131c154a09ac&scene=21#wechat_redirect)

雲產品本身的 Serverless 化也帶來了多樣性，在我看來，這個多樣性是 Serverless 理念在使用者使用介面和產品形態上不斷豐富帶來的，也在不斷推動行業的標準化程式，使用者在使用多種多樣的 Serverless 產品時，也能用標準的形式去使用各個雲廠商的產品。比如函式計算領域，它的觸發會是越來越標準的 http 模式，可觀測效能夠與 Prometheus、OpenTelemetry 等開源技術結合，這些都會讓 Serverless 產品標準化程度也越來越高。

使用者需求的多樣化是與 Serverless 產品的標準化結合在一起的，並且這是一個必經的過程，這樣才能有越來越多的使用者使用。

**我們在 2019 年就說 Serverless 的未來已來，在您看來這個“未來”真的來了嗎？**

觀點：Gartner 釋出過技術成熟度曲線，一個新技術都會經歷上升期、膨脹期、幻滅期，最後到平穩期。在我來看，Serverless 技術現在已經度過幻滅期，開始進入平穩期。前幾年應該是 Serverless 最火的時候，當時大家對 Serverless 非常推崇，那時是處於膨脹期。前面提到的場景多樣化也與此相關，膨脹期裡說的場景越來越多，在真正進入幻滅期後，落地的場景會越來越多。

我舉個例子，大家就能夠看到 Serverless 落實應用是不是真的已經比較多了。

首先是阿里自己在 2021 年雙十一的時候，大量的前端應用實際上是用 Serverless 框架實現的。這是一個比較典型的 Serverless 場景，比較容易落地。阿里內部跨很多業務部門，基於 Node.js 框架的前端業務，如今全部是用 Serverless 框架開發部署、使用的，這也支撐了雙十一的海量應用。Serverless 帶來了非常高的開發效能和極致彈性的提升。

另外，音影片處理用 Serverless 架構的使用者也非常多。某音樂服務廠商今年在阿里公共雲上用函式計算進行音影片處理，包括音訊轉碼、自動識別等。廠商選擇 Serverless 是因為其彈效能力。比如剛拿到一批歌曲的版權後，廠商要快速地對所有歌曲進行碼質的轉換，這就屬於爆發式的彈性需求，也是一種並行的批次式任務，而 Serverless 可以處理得很好。還有像影片 APP 的企業用微服務架構，這樣基礎設施運維投入也會比較高。有的企業會選擇面向應用的 Serverless 產品，比如阿里雲的 Serverless 應用引擎將微服務部署到平臺上，不需要做任何基礎設施管理。這個是現在 Serverless 真正的價值。

[網易雲音樂音影片演算法的 Serverless 探索之路](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247517449&idx=1&sn=3669b32e5a73f2d6119b86b1b7c2c5bb&chksm=fae68ec6cd9107d039cff6e345a2f0458ef6aeb6bc35c4fe25582d326d02104e04fb6480f3e8&scene=21#wechat_redirect)

**雲原生對程式語言會有特別的要求嗎？**

觀點：不知道大家是否瞭解，國內後端開發最火的語言是什麼？還是 Java。但如今，多語言是必然趨勢。很多公司在用 Go 作為主要開發語言，PHP 的使用也非常廣泛。每種語言的特點不太一樣，很多企業會根據業務需要選擇一種合適的語言。這時可能會出現多種語言，業務部門覺得用 Go 比較好，偏前端的想要 PHP 或者 Node.js，多語言在企業內部越來越普遍。

開發人員想用什麼語言就用什麼語言，但是運維人員就會面臨很大的挑戰，如多語言環境下的服務治理怎麼能統一做等。目前，雲原生領域推出了像 Service  Mesh 這樣的技術去做多語言的服務治理。就整個生態來講，目前最成熟的後端語言還是 Java，招聘 Java 人才也比較容易，而 Go 也有非常好的增長趨勢。未來，企業對於多語言的容忍程度會越來越高。

Java 之前在阿里基本處於統治地位，但現在阿里內部也多語言了。阿里收購了非常多的企業，如餓了麼、飛豬、高德等，但不可能讓所有併購進來的公司都改變程式語言，這是很難的。由於公司併購，阿里內的程式語言已經變得多元化了。企業足夠大的話，就一定是多語言的。如果是初創公司或者體量還不夠大，語言統一確實能帶來便捷。

**網友問到說雲原生很火，可能不用雲原生顯得不高階，比如 Mesh。您怎麼看待網友的這個疑問？**

觀點：雲原生領域的火是市場和業務驅動帶來的。技術發展的豐富度也會帶來選型難的問題，即有選錯路線的風險，這是真實存在的。今天雲原生技術很火，剛才也提到 CNCF 有上千個專案，使用者該用哪個？這確實是每個企業都會考慮的問題。在我看來，要選適合自己，但前提是有相應的技術場景支撐。至於該不該選 Mesh，這最終取決於企業的業務訴求。

比如偏穩健的團隊要很穩地去落地而且支援單語言，這時選擇比較成熟的 SpringCloud 和 Dubbo 是比較好的選擇。但如果團隊是面向多語言或面向未來去選架構，有些企業就會選 Mesh。Mesh 經過幾年的演進，開源社群的相對成熟，像 Istio 基本上已經成為事實標準，很多企業已經用這些技術生產，並不太需要去擔心 Mesh 是不是泡沫，它的泡沫階段已經過去了，已經到了可以實打實進行生產的階段了。

[服務網格 ASM 年終總結：終端使用者如何使用服務網格？](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247521816&idx=1&sn=81433ecb4d08d3146bf607e1d9f1a8d7&chksm=fae69dd7cd9114c153f17460be3fde03e542a9fb73e6819e7dc36a1d96563b84e5366c86607b&scene=21#wechat_redirect)

**服務網格的目標是成為雲原生的網路基礎設施。您覺得這個目標進行到哪一步了？下一步的研發和應用重點分別是什麼？**

觀點：剛才回答網友的問題也大概講到了我的一個觀點，就是服務網格技術逐漸成熟，Envoy 和 Istio 也是越來越普遍。CNCF 之前調研服務網格的使用率已經 27% 了，這已經很好了。頭部網際網路公司現在已經在用 Istio，或者在社群上做自研。螞蟻在前幾年宣佈整個核心業務 Mesh 化，阿里巴巴集團面臨多語言治理問題也在 Mesh 化。如果需求匹配也有技術儲備，是可以嘗試使用 Mesh 的。

不過，現在技術應用到生產中，社群技術版本還需要面對一些挑戰，比如存量系統的逐步過渡。Istio 整套體系和 K8s 生態關聯很緊密，但是很多企業的虛擬機器可能還沒有完全過渡到容器，存在部分虛擬機器，那怎麼能讓服務網路支援虛擬機器？有些企業可能是多種微服務框架混存的，有的已經使用 SpringCloud 了，那麼 Mesh 能不能和 SpringCloud 進行打通？社群在這方面的方案還不是特別全面。另外，Service Mesh 要上生產，非常重要一點就是可觀測性。完全自建的企業就會面臨這樣的技術挑戰。

企業要真正自己去構建 Mesh 體系，需要有技術儲備和相關人才。另外，企業也可以藉助雲廠商的力量。目前的幾個雲廠商都有 Mesh 方面的雲產品，比如阿里雲就有提供 Service Mesh 託管等服務。企業可以先根據自己的業務維度判斷技術團隊的能力，再決定是完全自建還是藉助雲廠商的能力。

**有網友問到，阿里都有哪些可觀測性方面的技術元件？**

觀點：可觀測性也是雲原生非常重要的一個領域，是企業上生產的必備搭檔。

目前，可觀測性方面有兩個比較大的趨勢。第一個大的趨勢就是全棧的可觀測性。業務中常常面臨的挑戰是使用者上報了一個問題，企業如何快速用可觀測性的方式在整個鏈路判斷出是哪裡的問題。現在，架構越來越複雜，企業可能要從使用者側開始，比如從前端到應用層、再到基礎設施層等等，需要的是整套鏈路的診斷能力。所以可觀測性的一個重要的趨勢就是打通整條鏈路。

另外一個非常重要的趨勢就是指標體系的打通。可觀測性領域有 Metric、tracing 和 Loggin 三大資料，這三大資料以前有點各做各的，但今天的使用者對將三大資料打通做統一監控有非常大的訴求。比如當一個問題出現的時候，可能是 Metric 發現了指標有異常，這時開發人員可能希望看下 Metric 異常對應的交易的日誌，看到日誌之後可能想看這個交易對應的整條鏈路的情況。在可觀測性場景下，大家對統一監控資料的需求越來越強烈。剛才聽眾問到阿里在這塊正在做什麼，其實就是圍繞上面說到的兩點提供全面的託管服務，比如 Prometheus，Grafana 的託管產品。

[年度盤點｜2021 年阿里雲可觀測實踐回顧](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247521597&idx=1&sn=5bdf09b6d04d8805e835aaebef1886d6&chksm=fae69ef2cd9117e47f29a9b66b787f1972c556e49bfa29a03b4066f59ff9232f648ae6f69d54&scene=21#wechat_redirect)

**社群也有人問到，開發測試人員對容器技術不熟練的話，企業如何探索雲原生？**

觀點：我覺得整個上雲的過程是要根據企業的情況和模式來做。業界有一個普遍的說法就是會把上雲分成幾個階段。首先，最簡單的辦法就是 Rehosting，即把原來的線下機房搬到雲上來。原來線下是虛擬機器，到雲上也是虛擬機器，這給企業帶來的往往是財務上的變化，原來擁有的是資產，現在變成了雲上服務。這對企業來說就是平移，整體價值稍微低一點，但成本也是最低的，基本上不需要對業務進行改造，運維模式也不需要變化。所有企業都可以做。

第二步是 Replatform。這與雲原生一些理念就有關聯了，比如將原來的虛擬機器變成容器化模式。Replatform 的一個典型特點就是，企業不需要對應用進行改造，只需要對系統運維模式進行改變。很多時候對應用進行改造的代價和成本是比較高的。容器化一般並不需要對企業的應用進行改造。另外就是考慮從自己建設的開源工具變成使用雲廠商的產品，比如原來自建 MySQL，變成雲廠商的 RDS 等。企業可以真正看到雲原生帶來的降本增效成果。

從團隊建設角度來說，還是需要有懂 K8s 的人。K8s 的學習資料還是非常多的，InfoQ、CNCF 官網、開源社群的官網，還有阿里雲都有大量的資料可以讓使用者使用。

最後一個階段也是很多企業在做的，就是 Refactor，即重構，企業整個應用架構往往發生一些變化，包括 Serverless 化，微服務化等。這個階段會涉及應用改造，但也才是真正能夠讓應用側發揮雲優勢的時候。企業可以結合自己的特點，選擇逐步的雲原生化。

另外，企業還要看自己的業務型別。現在有一個叫“雙態 IT”的理念，就是講穩態和敏態。穩態是企業內部變化不是很大的業務，對於這類業務，我們建議只需要做 Replatform 就可以，因為它的迭代速度沒有那麼快，業務改動也不是很大，但需要透過容器化等模式增強它的穩定性和彈性等。而敏態業務還有快速的迭代，這時可能會建議做 Refactor，如微服務化等，這樣可以提升整個研發效率。

企業要根據自己的業務型別和技術儲備等，綜合考慮自己雲原生化的方式。

**雲原生體系越來越大，開發人員要學習的東西也越來越多，您有什麼學習建議給到大家嗎？**

觀點：確實要學的東西很多，而且更新迭代非常快，我是建議大家換個角度學習。自學當然沒有問題，網上有各種各樣的資料。但有一點，大家在做雲原生能力落地的時候一定要從業務驅動的視角去做。

[雲原生，開發者的黃金時代](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247514651&idx=2&sn=06b137ac8a06403572cb3ea003c77eeb&chksm=fae6b1d4cd9138c2d6ddf29dbcbe15b9fb69f1de2a064bab8fa3651e9d8294b0615d8874df9d&scene=21#wechat_redirect)

我看到有些企業是為了技術而去做雲原生，這樣最後不一定有好的結果，更多時候還是先從業務價值角度出發考慮要做什麼事情，再選擇相應的技術。一方面，企業有業務驅動，便會有足夠多的資源投入。另一方面，企業在做技術選型和落地的時候會有足夠多的實踐。

從領域來講，我給大家的建議就是先把基礎打好，之後再完善一些生產必備的技能。容器技術是所有的基石，在這之後是一些比較關鍵的像可觀測性、CICD、微服務等企業內部落地真正需要的一些關鍵技術。

技術盤點：2022 年容器、Serverless、可觀測、服務網格有哪些值得關注的趨勢？

相關文章