阿里云智能總裁張建鋒在2021云棲大會分享

2021 年，云原生取得很多重要進展。2022 年又有哪些值得關注的趨勢？阿里云資深技術專家李國強（嶄巖）做客 InfoQ 視頻號，對云原生趨勢做了最新的解讀。以下根據直播內容整理，有不改變原意的刪減，完整內容可點擊??此處??查看回放，以下內容轉載自 InfoQ，并補充了相關參考內容，供讀者更全面地了解和學習。

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

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

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

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

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

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

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

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

??KubeVela 1.1 發布，開啟混合環境應用交付新里程碑??

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

云原生領域有什么趨勢會延續到 2022 年？

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

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

??OpenYurt 深度解讀｜開啟邊緣設備的云原生管理能力??****

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

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

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

??深信服智能邊緣計算平臺與 OpenYurt 落地方案探索與實踐??

隨著接入的服務越來越多，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 大新特性??

云產品本身的 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 探索之路??

云原生對編程語言會有特別的要求嗎？

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

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

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

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

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

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

??服務網格 ASM 年終總結：最終用戶如何使用服務網格？??

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

觀點：剛才回答網友的問題也大概講到了我的一個觀點，就是服務網格技術逐漸成熟，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 年阿里云可觀測實踐回顧??

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

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

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

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

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

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

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

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

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

??云原生，開發者的黃金時代??

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

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

總結

以上是生活随笔為你收集整理的技术盘点：2022 年容器、Serverless、可观测、服务网格有哪些值得关注的趋势？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。