去年我寫過一篇 牛年 dotnet 雲原生技術趨勢[1]，今天再來寫一篇虎年雲原生落地技術趨勢，去年侷限在 .NET 平臺上的雲原生落地，我今年在去年探索雲原生落地的基礎上從多語言云原生技術落地的趨勢來談談。
在2020年的時候，雲原生理念就被提到得越來越多，但是真正呈現出爆發形態、真正被所有的雲廠商、使用者廣泛使用的是在 2021年。國內三大雲廠商都在2020年釋出了雲原生2.0路線圖，而且這些頭部廠商的雲原生落地到達了一個里程碑式的關鍵節點，代表性事件就是各大網際網路公司基本完成了雲原生化，所有業務百分之百上雲。雲原生的核心技術如容器、微服務、服務網格等的可用性和成熟度都已經可以支撐起頭部網際網路的體量。每個行業的雲原生進度不一樣，頭部網際網路公司跑得比較靠前，基本都做到了全面雲原生化。未來幾年，其他行業會逐步追隨網際網路的腳步全面走向雲原生化。
隨著直播、5G、IoT 等領域的興起，讓業務對於雲的形態需求更高，大家希望雲能夠更貼近資料的產生點，因此相應的邊緣雲、本地雲、混合雲的形態越來越多。現在，整個雲端計算有一個很重要的趨勢，就是呈現一雲多形態的模式，使用者在各個地方都能用到雲端計算的能力。但這也對雲的基礎設施提出了比較大的挑戰。使用者以前就是用一朵雲，管理複雜度是可以接受，但多朵雲形態後，挑戰難度就比較大了。
雲原生技術天然能夠比較好地解決雲變成多形態後的統一介面管理問題，包括混合雲帶來的複雜度挑戰。下面兩張圖是我在2021年實踐雲原生的一個路線圖總結：
CNCF 裡面有非常多的開源專案，裡面的專案已經超過一千了。這些開源專案圍繞著雲端計算在展開競爭，CNCF 孵化專案成熟度模型分為三個級別，分別對應到鴻溝理論劃分的三個目標客群：
- 沙箱級（ Sandbox ）：對應創新者群體
- 孵化級（ Incubating ）：對應早期使用者群體
- 畢業級（ Graduated ）：對應早期多數群體
專案從孵化級向畢業級過渡最為關鍵，需要跨越鴻溝（ The Chasm ）。在此跨越過程中，孵化專案需要向有影響力的公司和組織證明自己提供的能力能夠改進生產流程、提升效率、降低成本，並且足夠穩定可靠以保證在生產環境使用。截至2022年2月3日，從 CNCF 成功畢業的專案有16個，進入孵化級別的是27個專案，具體參看 CNCF 的畢業和孵化專案[2]。
在2022年雲原生在各行各業開始進入全面落地階段，CNCF 在推進雲原生髮展過程中已經形成了幾大比較關鍵的標準：
雲原生實踐在支援多語言這個技術方案上還有 Service Mesh ，Service Mesh 出現的時間上比 Dapr 更長久， 目前也處於混戰階段，Istio 並不在 CNCF 社群裡，微軟聯合眾多廠商在 CNCF 裡提出了 SMI ( Service Mesh Interface ), 主要的 Service Mes 框架都實現了 SMI，微軟主導的 Open Service Mesh 遵循 SMI 規範，最近也釋出了1.0 版本，我昨天體驗後寫了一篇體驗文章體驗正式釋出的 OSM v1.0.0 版本[5]，Open Service Mesh 相對於 Istio 來說，確實很輕量。SMI 處理了所有你期望的標準服務 Mesh 功能，包括使用 mTLS 確保服務之間的通訊安全，管理訪問控制策略，服務監控等，Dapr 和 OSM 是非常好的一個實踐多執行時架構的組合。
最早出現的是容器，解決了應用打包標準化和應用釋出標準化的問題。在此之前，虛擬機器等方式的標準化程度是不夠的，Docker 終結了這一問題。隨著 Docker 的不斷演進和推廣，在應用編排、資源排程等又出現了新的問題，當時的 Docker Swarm 、Mesos 和 Kubernetes 互相競爭，最後 Kubernetes 勝出，並帶來了新的資源編排方面的事實標準。現在 Kubernetes 已經成為一個事實標準。而應用層之前也是百家爭鳴的情況，每個企業都在做自己的雲原生應用，現在有越來越多的開源標準出現，如 OAM ( Open Application Model ) 和 SMI( Service Mesh Interface ) 等，大家都在嘗試定義應用層的標準, OAM 和 SMI 尚未形成事實標準，他們有成為事實標準的潛力。
2022年就是非常關鍵的一年，在雲原生專案落地的過程中以 OAM 標準的代表專案 Dapr 目前在多執行時框架領域是一個非常耀眼的專案，落地的案例也非常多了。雲原生的多語言是必然趨勢。國內後端開發最火的語言是 Java ，已經有很多公司（騰訊、位元組）在用 Go 作為主要開發語言，PHP 的使用也非常廣泛。每種語言的特點不太一樣，很多企業會根據業務需要選擇一種合適的語言。這時可能會出現多種語言，業務部門覺得用 Java/C# 比較好，偏前端的想要 PHP 或者 Node.js，多語言在企業內部越來越普遍。開發人員想用什麼語言就用什麼語言，但是運維人員就會面臨很大的挑戰，如多語言環境下的服務治理怎麼能統一做等。Java 之前在阿里基本處於統治地位，但現在阿里內部也多語言了。阿里收購了非常多的企業，如餓了麼、飛豬、高德等，但不可能讓所有併購進來的公司都改變程式語言，這是很難的。由於公司併購，阿里內的程式語言已經變得多元化了。企業足夠大的話，就一定是多語言的。如果是初創公司或者體量還不夠大，語言統一確實能帶來便捷。所以阿里和微軟主導了開源專案 Dapr，詳細內容可以參看 Dapr 在阿里雲原生的實踐[3], 高德 Serverless 平臺建設及實踐[4]。
國內有很多企業已經在虛擬機器、物理機環境使用 Spring Cloud，這些企業轉向雲原生時，如果還是簡單把 spring cloud 部署到 kubernetes 環境，spring cloud 的很多基礎架構能力是和 kubernetes 相重疊的，想充分享受 kubernetes 帶來的自動化方面的能力，最好的選擇是卸下Spring Cloud，通過 Dapr 提供的分散式能力讓解決方案在各種環境中自由適配，而且 Spring Boot 版本可自主升級，不再與 Spring Cloud 存在相容性問題。
我看到有些企業是為了技術而去做雲原生，這樣最後不一定有好的結果，更多時候還是先從業務價值角度出發考慮要做什麼事情，再選擇相應的技術。一方面，企業有業務驅動，便會有足夠多的資源投入。另一方面，企業在做技術選型和落地的時候會有足夠多的實踐。從領域來講，我給大家的建議就是先把基礎打好，之後再完善一些生產必備的技能。容器技術是所有的基石，在這之後是一些比較關鍵的像可觀測性、CICD、微服務等企業內部落地真正需要的一些關鍵技術。
- 牛年 dotnet 雲原生技術趨勢：https://www.cnblogs.com/shany...
- CNCF的畢業和孵化專案:
https://www.cncf.io/projects/ - Dapr 在阿里雲原生的實踐：
https://developer.aliyun.com/... - 高德 Serverless 平臺建設及實踐：
https://xie.infoq.cn/article/... - 體驗正式釋出的 OSM v1.0.0 版本：
https://www.cnblogs.com/shany...