背景

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

現在 CS 專業的新同學估計都沒聽說過 SSM??

恰好從我剛開始工作時的移動互聯網熱潮到電商->共享經濟->toB 大熱->如今我都經歷了一遍，技術棧也有由最開始的單體應用+物理機發展到現在的 kubernetes 云原生架構。

當然中途也經歷了幾個大的階段：SOA服務化-> 微服務-> 云原生-> 服務網格-> 無服務等幾個階段。

最近一份工作又主要是在做基礎架構，我認為了解的還算是比較全面的，所以本文我就以我的視角分享下我們在 2024 年應當使用哪些云原生技術棧，因為涉及到的技術組件比較多，就不過多討論細節了。

但可以保證的是提到的技術棧都是我所用過的，優缺點都會提到，主打一個真實體驗。

操作系統

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

不過怎么維護好 kubernetes 是一個難點問題，還記得去年下半年滴滴出過一次事故，網傳就是 kubernetes 升級出現的問題。

根據我們的經驗來看，對于小團隊更建議直接托管給云廠商，維護 kubernetes 是一個非常復雜的工作，小團隊通常都是一職多能，自己維護更容易出問題。

當然大團隊有專人維護最好，即便是出問題也能快速響應，前提是自己能 cover 住這個風險。

因為我們是小團隊，所以考慮到成本和穩定性，我們也只使用了云廠商的 kubernetes 能力，其余的部分可控組件由我們自己維護（具體的后文會講到）

多云的優勢與好處

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

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

但具體的實施過程中也有許多挑戰，比如最棘手也是最關鍵的數據一致性如何保證？

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

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

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

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

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

我們是具備恢復元數據能力的，但會丟失部分運行時的數據。

DevOps

既然我們已經選擇 kubernetes 作為我們云原生的操作系統，那我們的持續集成與發布也得圍繞著 kubernetes 來做。

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

也就是我們常說的 GitOps。

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

當然還有現在流行 FinOps，我的理解主要是做云成本的管理和優化，對應到我的工作就是回收一些不用的資源，在不影響業務的情況下適當的降低一些配置??。

Service Mesh

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

由最開始的單機的本地函數調用開始：

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

主要經歷了以上三個重要的階段，分別是 RPC 框架到微服務再到現在的服務網格。

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

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

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

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

可觀測性

現如今可觀測系統也變得越來越重要，個人覺得評價一個技術團隊重要指標就是他們的可觀測系統做的如何。

一個優秀的可觀測系統可以清晰得知系統的運行狀態、高效的排查問題、還有及時的故障告警。

要實現上述標準就需要我們可觀測系統的三個核心指標了：

• Metrics，借助它我們可以在 Grafana 中繪制出各種直觀的面板，可以更加全面的了解我們系統的運行狀態。

• Trace則是可以幫助我們構建出系統調用的全貌，通過一個 trace 就可以知道一個請求經歷了哪些系統，在哪個環節出了問題。
• Logs 就比較好理解了，就是我們自己在應用里打印的一些日志；只是和以往的開發模式略有不同的是：在云原生體系中更推薦直接輸出到標準輸出和標準錯誤流中，一些第三方采集組件可以更方便的進行采集。

我們自己的可觀測系統經歷過一次迭代，以往的技術棧是：

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

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

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

消息隊列

這里單獨把消息隊列拎出來是因為我目前主要是在維護公司內部的消息隊列，同時業務體量大了之后消息隊列變得非常重要了，通常會充當各個業務線對接的橋梁，或者是數據庫同步 MySQL 的渠道，總之用處非常廣泛。

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

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

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

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

因為得益于 Pulsar 社區的活躍，即便是自己維護出現問題也可以及時得到反饋；同時自己平時踩的坑也可以反哺社區。

業務框架

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

雖然這點對于 kubernetes 來說無關緊要，下面以我比較熟悉的 Java 和 Golang 進行介紹。

Java

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

只是這樣會缺少一些服務治理的能力，更適用于中小型團隊。

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

當有專門的云原生團隊時，則更推薦使用服務網格的方案，這樣我們就能綜合以上兩種方案的優點：

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

Golang

Golang 其實也與 Java 類似，中小團隊時我們完全可以只使用 Gin 這類 http 框架進行開發。

而中大型團隊在 Golang 生態中也有對標 Dubbo 和 SpringCloud 的框架，比如 kratos和 go-zero 等。

得益于 Golang 的簡潔特性，我覺得比使用 Java 開發業務更加簡單和“無腦”。

同樣的后續也可以切換到服務網格，直接采用 gRPC 和 Golang 也非常適配，此時團隊應該也比較成熟了，完全可以自己基于 gRPC 做一個開發腳手架，或者也可以使用 Kratos 或者是 go-zero 去掉他們的服務調用模塊即可。

總結

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

參考鏈接：

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