背景

時間過得很快啊，一轉(zhuǎn)眼已經(jīng)到了 2024 年，還記得 15 年剛工作那會掌握個 SSM/H(Spring/Struts2/Mybatis/Hibernate) 框架就能應(yīng)付大部分面試了。

現(xiàn)在 CS 專業(yè)的新同學(xué)估計都沒聽說過 SSM??

恰好從我剛開始工作時的移動互聯(lián)網(wǎng)熱潮到電商->共享經(jīng)濟(jì)->toB 大熱->如今我都經(jīng)歷了一遍，技術(shù)棧也有由最開始的單體應(yīng)用+物理機(jī)發(fā)展到現(xiàn)在的 kubernetes 云原生架構(gòu)。

當(dāng)然中途也經(jīng)歷了幾個大的階段：SOA服務(wù)化-> 微服務(wù)-> 云原生-> 服務(wù)網(wǎng)格-> 無服務(wù)等幾個階段。

最近一份工作又主要是在做基礎(chǔ)架構(gòu)，我認(rèn)為了解的還算是比較全面的，所以本文我就以我的視角分享下我們在 2024 年應(yīng)當(dāng)使用哪些云原生技術(shù)棧，因?yàn)樯婕暗降募夹g(shù)組件比較多，就不過多討論細(xì)節(jié)了。

但可以保證的是提到的技術(shù)棧都是我所用過的，優(yōu)缺點(diǎn)都會提到，主打一個真實(shí)體驗(yàn)。

操作系統(tǒng)

首先是操作系統(tǒng)，這里有別于以往我們傳統(tǒng)的操作系統(tǒng)(Linux/Windows Server/MacOS)，主要指的是云原生的操作系統(tǒng)，沒有太多可以選擇的余地，那就是 kubernetes。

不過怎么維護(hù)好 kubernetes 是一個難點(diǎn)問題，還記得去年下半年滴滴出過一次事故，網(wǎng)傳就是 kubernetes 升級出現(xiàn)的問題。

根據(jù)我們的經(jīng)驗(yàn)來看，對于小團(tuán)隊更建議直接托管給云廠商，維護(hù) kubernetes 是一個非常復(fù)雜的工作，小團(tuán)隊通常都是一職多能，自己維護(hù)更容易出問題。

當(dāng)然大團(tuán)隊有專人維護(hù)最好，即便是出問題也能快速響應(yīng)，前提是自己能 cover 住這個風(fēng)險。

因?yàn)槲覀兪切F(tuán)隊，所以考慮到成本和穩(wěn)定性，我們也只使用了云廠商的 kubernetes 能力，其余的部分可控組件由我們自己維護(hù)（具體的后文會講到）

多云的優(yōu)勢與好處

既然都用了云廠商的容器服務(wù)，那也要考慮到云廠商故障可能帶來的問題；比如去年的阿里云故障。

所以現(xiàn)在一些中大廠也會選擇多云方案，將同一份代碼部署再多個云服務(wù)商，一旦其中一個出現(xiàn)問題可以快速切換。

但具體的實(shí)施過程中也有許多挑戰(zhàn)，比如最棘手也是最關(guān)鍵的數(shù)據(jù)一致性如何保證？

當(dāng)然我們可以采用一些支持分布式部署的數(shù)據(jù)庫或中間件，他們本身是支持?jǐn)?shù)據(jù)同步的；比如消息隊列中的 Pulsar，它就可以跨級群部署以及消息同步。

同時多云部署對應(yīng)的成本也會提升，在這個“降本增效”的大背景下也得慎重考慮；所以對此還有一個折中方案：

我們的技術(shù)架構(gòu)需要具備快速遷移到其他云服務(wù)的能力，比如我們內(nèi)部有一些工具可以定期備份資源，比如 MySQL 的 binlog，一些中間件的元數(shù)據(jù)，同時可以基于這些元數(shù)據(jù)快速恢復(fù)業(yè)務(wù)。

一般遇到需要切換云服務(wù)時都是一些極端情況，所以允許部分運(yùn)行時的數(shù)據(jù)丟失也是能接受的，我們只要保證最核心的數(shù)據(jù)不會丟失從而不影響業(yè)務(wù)即可。

這個說起來簡單，但也需要我們花時間進(jìn)行模擬演練；具體是否實(shí)施就得看公司是否接受云服務(wù)宕機(jī)帶來的損失以及演練所花的成本了。

我們是具備恢復(fù)元數(shù)據(jù)能力的，但會丟失部分運(yùn)行時的數(shù)據(jù)。

DevOps

既然我們已經(jīng)選擇 kubernetes 作為我們云原生的操作系統(tǒng)，那我們的持續(xù)集成與發(fā)布也得圍繞著 kubernetes 來做。

上圖是一張使用 Git 配合 gitlab+ArgoCD 的流程圖，我們使用 gitlab 來管理源碼，同時也可以利用他的 Pipline 幫我們做持續(xù)集成，最終使用 Argo 幫我們打通 kubernetes 的流程。

也就是我們常說的 GitOps。

同時我們的回滾歷史版本，擴(kuò)縮容都由 kubernetes 提供能力，我們的 DevOps 平臺只需要調(diào)用 kubernetes 的 API 即可。

當(dāng)然還有現(xiàn)在流行 FinOps，我的理解主要是做云成本的管理和優(yōu)化，對應(yīng)到我的工作就是回收一些不用的資源，在不影響業(yè)務(wù)的情況下適當(dāng)?shù)慕档鸵恍┡渲??。

Service Mesh

接下來便是我認(rèn)為最重要的 Service Mesh 環(huán)節(jié)了，這個的背景故事就多了，本質(zhì)上我覺得這都是由 RPC(Remote Process Call) 引起的也是分布式所帶來的。

由最開始的單機(jī)的本地函數(shù)調(diào)用開始：

local+------>remote +------> micro-service+----->service-mesh
               +                  |                    +
               v                  v                    v
           +---+----+       +-----+------+        +----+----+
           | motan  |       | SpringCloud|        | Istio   |
           | dubbo  |       | Dubbo3.0   |        | Linkerd |
           | gRPC   |       | SOFA       |        |         |
           +--------+       +------------+        +---------+

主要經(jīng)歷了以上三個重要的階段，分別是 RPC 框架到微服務(wù)再到現(xiàn)在的服務(wù)網(wǎng)格。

• RPC 框架主要幫我們簡化了分布式通信，只專注于業(yè)務(wù)本身。
• 微服務(wù)框架的出現(xiàn)可以更好的幫我們治理大批量的服務(wù)，比如一些限流、路由、降級等功能，讓我們分布式應(yīng)用更加健壯。
• 而如今的服務(wù)網(wǎng)格讓我們的應(yīng)用程序更加適配云原生，專注于業(yè)務(wù)研發(fā)而不再需要去維護(hù)微服務(wù)框架；將這些基礎(chǔ)功能全部下沉到我們的基礎(chǔ)層，同時也帶來了不弱于微服務(wù)框架的功能性。

但使用 Istio 也有著不低的技術(shù)門檻，我覺得如果滿足以下條件更推薦使用 Istio：

• 應(yīng)用已經(jīng)接入 kubernetes 平臺
• 應(yīng)用之間采用的是 gRPC 通訊框架
• API 網(wǎng)關(guān)也遷移到 Istio Gateway
• 公司至少預(yù)備一個專人維護(hù) Istio（這里的維護(hù)不一定是對代碼的了解，但一定要對 Istio 本身的功能和文檔足夠了解）

除此之外使用 SpringCloud、Dubbo、kratos、go-zero之類的微服務(wù)框架也未嘗不可。

可觀測性

現(xiàn)如今可觀測系統(tǒng)也變得越來越重要，個人覺得評價一個技術(shù)團(tuán)隊重要指標(biāo)就是他們的可觀測系統(tǒng)做的如何。

一個優(yōu)秀的可觀測系統(tǒng)可以清晰得知系統(tǒng)的運(yùn)行狀態(tài)、高效的排查問題、還有及時的故障告警。

要實(shí)現(xiàn)上述標(biāo)準(zhǔn)就需要我們可觀測系統(tǒng)的三個核心指標(biāo)了：

• Metrics，借助它我們可以在 Grafana 中繪制出各種直觀的面板，可以更加全面的了解我們系統(tǒng)的運(yùn)行狀態(tài)。

• Trace則是可以幫助我們構(gòu)建出系統(tǒng)調(diào)用的全貌，通過一個 trace 就可以知道一個請求經(jīng)歷了哪些系統(tǒng)，在哪個環(huán)節(jié)出了問題。
• Logs 就比較好理解了，就是我們自己在應(yīng)用里打印的一些日志；只是和以往的開發(fā)模式略有不同的是：在云原生體系中更推薦直接輸出到標(biāo)準(zhǔn)輸出和標(biāo)準(zhǔn)錯誤流中，一些第三方采集組件可以更方便的進(jìn)行采集。

我們自己的可觀測系統(tǒng)經(jīng)歷過一次迭代，以往的技術(shù)棧是：

• Metrics 使用 VictoriaMetrics：這是一個完全兼容 Prometheus 的時序數(shù)據(jù)庫，但相對 Prometheus 來說更加的節(jié)省資源。
• Trace 選擇的是 SkyWalking，這也是 Java trace 領(lǐng)域比較流行的技術(shù)方案。
• Logs：使用 filebeat 采集日志然后輸出到 ElasticSearch 中，這也是比較經(jīng)典的方案。

去年底我們做了一次比較大的改造，主要就是將 SkyWalking 換為了 OpenTelemetry，這是一個更加開放的社區(qū)，也逐漸成為云原生可觀測的標(biāo)準(zhǔn)了。

使用它我們的靈活性更高，不用與某些具體的技術(shù)棧進(jìn)行綁定；目前 logs 還沒有切換，社區(qū)也還在 beta 測試中，后續(xù)成熟后也可以直接用 OpenTelemetry 來收集日志。

消息隊列

這里單獨(dú)把消息隊列拎出來是因?yàn)槲夷壳爸饕窃诰S護(hù)公司內(nèi)部的消息隊列，同時業(yè)務(wù)體量大了之后消息隊列變得非常重要了，通常會充當(dāng)各個業(yè)務(wù)線對接的橋梁，或者是數(shù)據(jù)庫同步 MySQL 的渠道，總之用處非常廣泛。

這里還是推薦更貼合云原生的消息隊列 Pulsar，由于它存算分離的架構(gòu)特性，配合kubernetes 的特性可以實(shí)現(xiàn)快速的擴(kuò)縮容，相比 kafka 來說更易維護(hù)；同時社區(qū)活躍度也非常高，在 Bug 修復(fù)和支持新特性方面比較積極。

Pulsar官方支持的客戶端也比較全面：

還有一個問題是：如何部署我們的 Pulsar 集群，是私有化部署還是購買云服務(wù)（目前 Pulsar的商業(yè)公司 streamnative 和國內(nèi)的騰訊云都有類似的服務(wù)）

我們之前有咨詢過價格，相對來說還是自己部署性價比最高；和前文講的一樣，只使用云廠商的 kubernetes 服務(wù)，在這基礎(chǔ)上部署我們的自己的服務(wù)。

因?yàn)榈靡嬗?Pulsar 社區(qū)的活躍，即便是自己維護(hù)出現(xiàn)問題也可以及時得到反饋；同時自己平時踩的坑也可以反哺社區(qū)。

業(yè)務(wù)框架

最后是業(yè)務(wù)框架的選擇，決定這個的前提是我們先要確定選擇哪個語言作為主力業(yè)務(wù)語言。

雖然這點(diǎn)對于 kubernetes 來說無關(guān)緊要，下面以我比較熟悉的 Java 和 Golang 進(jìn)行介紹。

Java

Java 可選的技術(shù)方案就比較多了，如果我們只是上了 kubernetes 但沒有使用服務(wù)網(wǎng)格；那完全可以只使用 springboot 開發(fā) http 接口，就和開發(fā)一個單體應(yīng)用一樣簡單。

只是這樣會缺少一些服務(wù)治理的能力，更適用于中小型團(tuán)隊。

如果團(tuán)隊人員較多，也沒使用服務(wù)網(wǎng)格時；那就推薦使用前文介紹的微服務(wù)框架：比如 Dubbo、SpringCloud 等。

當(dāng)有專門的云原生團(tuán)隊時，則更推薦使用服務(wù)網(wǎng)格的方案，這樣我們就能綜合以上兩種方案的優(yōu)點(diǎn)：

• 代碼簡潔，只是需要將 http 換為 gRPC。
• 同時利用 Istio 也包含了微服務(wù)框架的能力。

Golang

Golang 其實(shí)也與 Java 類似，中小團(tuán)隊時我們完全可以只使用 Gin 這類 http 框架進(jìn)行開發(fā)。

而中大型團(tuán)隊在 Golang 生態(tài)中也有對標(biāo) Dubbo 和 SpringCloud 的框架，比如 kratos和 go-zero 等。

得益于 Golang 的簡潔特性，我覺得比使用 Java 開發(fā)業(yè)務(wù)更加簡單和“無腦”。

同樣的后續(xù)也可以切換到服務(wù)網(wǎng)格，直接采用 gRPC 和 Golang 也非常適配，此時團(tuán)隊?wèi)?yīng)該也比較成熟了，完全可以自己基于 gRPC 做一個開發(fā)腳手架，或者也可以使用 Kratos 或者是 go-zero 去掉他們的服務(wù)調(diào)用模塊即可。

總結(jié)

以上就是個人對目前流行的技術(shù)方案的理解，也分別對不同團(tuán)隊規(guī)模進(jìn)行了推薦；確實(shí)沒有完美的技術(shù)方案，只有最合適的，也不要跟風(fēng)選擇一些自己不能把控的技術(shù)棧，最終吃虧的可能就是自己。

參考鏈接：

• https://levelup.gitconnected.com/gitops-in-kubernetes-with-gitlab-ci-and-argocd-9e20b5d3b55b
• https://grpc.io/