背景
時間過得很快啊，一轉眼已經到了 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之類的微服務框架也未嘗不可。
我之前有寫過兩篇關於 Istio 的 文章，也可以用做參考：
可觀測性
現如今可觀測系統也變得越來越重要，個人覺得評價一個技術團隊重要指標就是他們的可觀測系統做的如何。
一個優秀的可觀測系統可以清晰得知系統的運行狀態、高效的排查問題、還有及時的故障告警。
要實現上述標準就需要我們可觀測系統的三個核心指標了：
- Metrics，藉助它我們可以在 Grafana 中繪製出各種直觀的面板，可以更加全面的瞭解我們系統的運行狀態
- Trace則是可以幫助我們構建出系統調用的全貌，通過一個 trace 就可以知道一個請求經歷了哪些系統，在哪個環節出了問題。
- Logs 就比較好理解了，就是我們自己在應用裏打印的一些日誌；只是和以往的開發模式略有不同的是：在雲原生體系中更推薦直接輸出到標準輸出和標準錯誤流中，一些第三方採集組件可以更方便的進行採集。
我們自己的可觀測系統經歷過一次迭代，以往的技術棧是：
Metrics使用VictoriaMetrics：這是一個完全兼容Prometheus的時序數據庫，但相對Prometheus來說更加的節省資源。- Trace 選擇的是
SkyWalking，這也是 Java trace 領域比較流行的技術方案。 - Logs：使用 filebeat 採集日誌然後輸出到 ElasticSearch 中，這也是比較經典的方案。
去年底我們做了一次比較大的改造，主要就是將 SkyWalking 換爲了 OpenTelemetry，這是一個更加開放的社區，也逐漸成爲雲原生可觀測的標準了。
使用它我們的靈活性更高，不用與某些具體的技術棧進行綁定；目前 logs 還沒有切換，社區也還在 beta 測試中，後續成熟後也可以直接用 OpenTelemetry 來收集日誌。
我也寫的有一篇 SW 遷移到 OpenTelemetry 的文章，感興趣的朋友可以參考：
消息隊列
這裏單獨把消息隊列拎出來是因爲我目前主要是在維護公司內部的消息隊列，同時業務體量大了之後消息隊列變得非常重要了，通常會充當各個業務線對接的橋樑，或者是數據庫同步 MySQL 的渠道，總之用處非常廣泛。
這裏還是推薦更貼合雲原生的消息隊列 Pulsar，由於它存算分離的架構特性，配合kubernetes 的特性可以實現快速的擴縮容，相比 kafka 來說更易維護；同時社區活躍度也非常高，在 Bug 修復和支持新特性方面比較積極。
Pulsar官方支持的客戶端也比較全面：
| Language | Documentation | Release note | Code repo |
|---|---|---|---|
| Java | User doc <br> API doc | Standalone | Bundled |
| C++ | User doc <br> API doc | Standalone | Standalone |
| Python | User doc <br> API doc | Standalone | Standalone |
| Go client | User doc <br> API doc | Standalone | Standalone |
| Node.js | User doc <br> API doc | Standalone | Standalone |
| C#/DotPulsar | User doc | Standalone | Standalone |
還有一個問題是：如何部署我們的 Pulsar 集羣，是私有化部署還是購買雲服務（目前 Pulsar的商業公司 streamnative 和國內的騰訊雲都有類似的服務）
我們之前有諮詢過價格，相對來說還是自己部署性價比最高；和前文講的一樣，只使用雲廠商的 kubernetes 服務，在這基礎上部署我們的自己的服務。
因爲得益於 Pulsar 社區的活躍，即便是自己維護出現問題也可以及時得到反饋；同時自己平時踩的坑也可以反哺社區。
之前也寫過一些關於 Pulsar 的系列文章，感興趣的可以查閱：
- 在 kubernetes 環境下如何優雅擴縮容 Pulsar
- Pulsar3.0新功能介紹
- Pulsar負載均衡原理及優化
- 白話 Pulsar Bookkeeper 的存儲模型
- 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 去掉他們的服務調用模塊即可。
總結
以上就是個人對目前流行的技術方案的理解，也分別對不同團隊規模進行了推薦；確實沒有完美的技術方案，只有最合適的，也不要跟風選擇一些自己不能把控的技術棧，最終喫虧的可能就是自己。
參考鏈接：